9 Replies Latest reply on Sep 4, 2009 12:20 PM by Ron Sigal

    Socket invocator and long transactions

    Doychin Bondzhev Newbie

      Looks like there is some problem with long running transactions when used with socket invocation.

      I found that no matter what I will specify for transaction time out I get exception from server for trying to call statefull bean second time after 6 minutes. I'm sure there is no second call and that second call comes from the same thread that created the first call so it is not in my code but instead something internally in client side remoting code.

      From what I see it looks like jboss remoting client code does not respect the availability of UserTransaction and it's timeout.

      Is there a solution for this problem or and updated version of remoting that supports user transactions?

      Is the only solution is now to increase the timeout for invocation?

      If I increase it to much isn't that a source for more problems later?

      Doychin

        • 1. Re: Socket invocator and long transactions
          Doychin Bondzhev Newbie

          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
            Ron Sigal Master

            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
              Doychin Bondzhev Newbie

              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
                Ron Sigal Master

                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
                  Doychin Bondzhev Newbie

                  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
                    Ron Sigal Master

                    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
                      David Lloyd Master

                      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
                        Doychin Bondzhev Newbie

                        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
                          Ron Sigal Master

                          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.