-
1. Re: Socket invocator and long transactions
Here is what I found until now.
I'm using JBoss App Server 4.2.3 GA with it's original version of jboss remoting.
One specific change I did to the remoting configuration was to add idleTimeout parameter with value 120 seconds.
So from here start my problems.
Without this timeout all will be fine. When it is specified the IdleTimer will close sockets for all inactive ServerThread instances including those that current are busy processing some request. (In SocketServerInvoker.java the problem comes from calls like this: svrThread.unblock();)
When such socket is closed on the sever the client side sends another instance of the same request(invocation) and as result I get an exception for the second request (Application Error: no concurrent calls on stateful beans). In the initial thread I get exception that Transaction status is ABORTING.
All these findings are valid for all versions of JBoss Remoting 2.2.2.
For 2.4 I see that all calls to shutdown and unblock method are commented and replaced just with call to shutdown later in the code.
Regarding UserTransaction timeouts there is still problem.
At least I can't find anything in the code that will respect the value for user transaction timeout. They will work only if their timeout is less then the timeout value specified in jboss-service.xml.
Doychin -
2. Re: Socket invocator and long transactions
Hi Doychin,
Remoting, in its current form doesn't know about transactions. But the fact that SocketServerInvoker.IdleTimeoutTask is killing ServerThreads during invocations is bug, regardless of the presence of transactions.
I've created JBREM-1107 "SocketServerInvoker.IdleTimeoutTask interrupts ServerThreads during long invocation". In the meantime, the workaround would be, of course, to increase the value of the "idleTimeout" parameter."doychin" wrote:
For 2.4 I see that all calls to shutdown and unblock method are commented and replaced just with call to shutdown later in the code.
Yes, for Remoting 2.4 I reorganized somewhat the relationship between ServerThread and SocketServerInvoker.
-Ron -
3. Re: Socket invocator and long transactions
Hi Ron,
Are there any plans to make change in remoting so that it can talk with transactions code and respect user transaction timeout?
What are the possibilities for this?
Is this a problem that has to be solved from Application Server developers or it is a problem for Remoting guys? -
4. Re: Socket invocator and long transactions
Hi Doychin,
I'm not sure I understand. If I fix JBREM-1107 and "idleTimeout" is configured appropriately, wouldn't that solve the problem?
There was some discussion, if I remember correctly, about making Remoting 3 aware of transactions, though. I'm not sure about the current status of that idea. I'll ask David Lloyd. -
5. Re: Socket invocator and long transactions
Hi Ron,
As you know there is timeout parameter which is used to wait on the socket read/write operation. This timeout if is less then the user transaction timeout on the client side and for some reason execution at the server takes more time then this timeout it will crash execution again.
Client side will exit read and will try to send same command to the server. It will write some parts of invocation it and will start waiting again for second round on the timeout.
This data will stay in the socket and probably will create some problems when the server side tries to read data from socket later. -
6. Re: Socket invocator and long transactions
Hi Doychin,
"doychin" wrote:
This timeout if is less then the user transaction timeout on the client side and for some reason execution at the server takes more time then this timeout it will crash execution again.
Well, again, I think this is a configuration issue. Note that you can always set the timeout value to 0."doychin" wrote:
Client side will exit read and will try to send same command to the server. It will write some parts of invocation it and will start waiting again for second round on the timeout.
This data will stay in the socket and probably will create some problems when the server side tries to read data from socket later.
A second org.jboss.remoting.transport.socket.ServerThread should respond to the second attempt and read the second invocation. I don't think anything would be left in the socket's InputStream. Of course, you wouldn't want two instances of the same transaction running, which takes us back to getting the configuration right. -
7. Re: Socket invocator and long transactions
Though this isn't set in stone just yet, I'd like to have a better integration between transaction managers/resources and Remoting. Getting transaction timeouts to sync up is definitely part of this. But another key point with Remoting 3 is that the client-connection relationship is changed as well; you generally won't have a timeout associated with a connection anymore. The responsibility to time out a single request will be with the user code.
See these methods for more info on that:
http://docs.jboss.org/remoting/3.0.0.GA/api/org/jboss/remoting/Client.html#send(I)
whose return value has this method:
http://docs.jboss.org/xnio/1.2.0.GA/api/org/jboss/xnio/IoFuture.html#await(long,%20java.util.concurrent.TimeUnit) -
8. Re: Socket invocator and long transactions
All these new things in Remoting 3 are great but at least in my case it is all up to the integration code that is provided on top of remoting by Application server client library. I'm not sure how this is going to work with these asynchronous calls.
-
9. Re: Socket invocator and long transactions
For the record, I finished JBREM-1107 " SocketServerInvoker.IdleTimeoutTask interrupts ServerThreads during long invocation" for release 2.2.3.SP1. No fix is necessary in Remoting 2.4/2.5.