1 Reply Latest reply on Apr 23, 2008 3:11 AM by Ron Sigal

    SocketClientInvoker Doesn't Catch/Throw Transaction Timeouts

    John Reynolds Newbie

      Please see discussion thread in JBoss Transactions forum, here.

      Essentially, the issue is this:
      We had a project where we converted from a Swing Client-Server App from WebLogic 8.1 (EJB2) to JBoss 4.2 and were advised by JBoss Consultants onsite that Socket connectors perform better than RMI and will handle failover better in moving away from a Clustered environment to multiple servers behind a Virtual IP (using ClientConnectAddress in jboss-service.xml to spoof clients). So we need to stick with Sockets, if possible, but...

      When we change our org.jboss.remoting.transport.Connector in our jboss-service.xml from transport=socket to transport=rmi, we actually get the behavior we'd hope to see under socket. (though lose some desired behavior that socket provides)

      Under RMI, when the transaction timesout, the client is immediately notified that the transaction was timedout/rolledback. Under Socket, the thread that is wrapped in the transaction actually finishes before anything is sent back to the client -- even after the transaction timed out and rolled back! So the user gets an IllegalStateException returned after waiting for the entire thread to complete.

      Not the best design, but we have always counted on the transaction timeout/rollback error to notify the client immediately. Imagine a user fires off a query to load a list of tasks and they accidentally enter in a date range much larger than they intended. (granted, we could control some more at the client level, but ideally we would make this conversion to jboss w/o having to change too much of this long-standing code) Under RMI, we can send a message back to the user after 5 or 10 minutes, so they can see that the transaction timed out and clean up the query or otherwise try something else.

      Under Socket, the behavior is far less desirable. Say the query runs for 12 minutes with a transaction timeout of 5 minutes. The transaction dies after 5 minutes but the end user on the client side doesn't receive a notification and instead is left to watch the status bar bounce for another 7 minutes... and at that time they don't even receive their result set, they get an IllegalStateException! (we could adjust our timeout, but that's not what the users are used to and we'd ultimately like to keep some consistency after the migration from weblogic to jboss)

      What can be done to get Socket transport behaving like RMI transport? (i.e. sending a transaction timeout/rollback exception back to the client)

      Thanks much, in advance, for any and all assistance!

      -John