8 Replies Latest reply on Apr 15, 2005 4:48 AM by Ole Matzura

    how handle multithreaded web app client?

    Ole Matzura Novice

      Hi all!

      Need some expert advice here: we have a standard struts/spring web app with struts actions accessing a web service (via a spring bean) as described in the wiki for web component clients.

      When calling our struts actions from multiple client/threads the invoked sei repeatedly returns null or throws an exception, which leads us to believe that the sei is not thread safe.. is this the case? If so.. what is the recommended way of handling this? Do we need to create a pool of seis that client threads can use? (synchronization of actions is not an option)..

      thanks for any help!

      regards,

      /Ole

        • 1. Re: how handle multithreaded web app client?
          Jason Greene Master

          Yes, in jbossws, a JSE follows the servlet model. This is actually outlined in the jaxrpc 1.1 spec. It is up to the implementation of the jax-rpc provider to choose the thread model, so you have to assume that your JSE endpoint can be resused between threads. If you have code that is not threadsafe then you need to pull that code into someother object tree, and dispath the requests to it from your SEI. If you want to do some kind of pooling you can use the ServletLifecycle interface and implement an init method.

          -Jason

          • 2. Re: how handle multithreaded web app client?
            Thomas Diesler Master

            If I understand you correctly, your struts action is a WS4EE client, calling a remote web service. In that case, this is not a concurrency issue of the endpoint.

            So the action is multi-threaded, that means it should create an individual Call object for every thread.

            Can you assume that the remote endpoint is able to handle concurrent requests?

            In case your Java Service Endpoint (JSE) is deployed on jboss as well, it is thread safe. Not sure if Jason is right in saying that you should assume the oposite. With our current implementation you get the same behaviour with JSE as you would with SLSB as an endpoint. Minus the pooling of instances.

            • 3. Re: how handle multithreaded web app client?
              Ole Matzura Novice

              Hi!

              You are correct in assuming that the threading issue arises on the client side (in our struts action) which had created one instance of the sei which it shared between calling threads. The actual web-service endpoint is deployed as a stateless session-bean under jbossws on another machine and is thread-safe.

              We solved the problem by creating a dynamic proxy for the sei that in its InvocationHandler used commons-pool to hold a pool of sei:s which it used for dispatching the invocations. This solution had the advantage of not requiring any changes to the struts action (it uses the dynamic proxy instead) and seems to work just fine under multiple threads..

              Maybe there is a better/easier way?

              regards,

              /Ole

              • 4. Re: how handle multithreaded web app client?
                Thomas Diesler Master

                The javax.rpc.xml.Service that you look up from JNDI should be thread safe. The Call you create from it, is not.

                Every thread should simply create a new Call. Does that not work for you?

                • 5. Re: how handle multithreaded web app client?
                  Ole Matzura Novice

                  ok..

                  We are not creating Call objects but using the Stub returned by service.getPort( seiClass ) for our invocations.

                  Could we just create a new stub for each client/thread instead of looking up a new service instance?

                  /Ole

                  • 6. Re: how handle multithreaded web app client?
                    Thomas Diesler Master

                    Every call to service.getPort(seiClass) should give you a new instance of a dynamic proxy which internally should not reuse the stateful Call object.

                    Could you perhaps confirm this for me? If this is not the case, we are looking at a bug.

                    The Service you lookup from JNDI should be stateless, so you may cache it.

                    Well, this is at least how I intended it.

                    • 7. Re: how handle multithreaded web app client?
                      Jason Greene Master

                       

                      "thomas.diesler@jboss.com" wrote:
                      If I understand you correctly, your
                      In case your Java Service Endpoint (JSE) is deployed on jboss as well, it is thread safe. Not sure if Jason is right in saying that you should assume the oposite. With our current implementation you get the same behaviour with JSE as you would with SLSB as an endpoint. Minus the pooling of instances.


                      Just to clarify where I got this from, it is outlined in 10.1.2 of jaxrpc-1.1:

                      "The associated servlet typically takes the responsibility of handling transport specific
                      processing of an RPC request and for initiating dispatch to the target service endpoint
                      instance. Each Servlet.service method maps to a single remote method invocation on
                      the target service endpoint instance. The thread model (whether single threaded or
                      concurrent) for the remote method invocation on the service endpoint instance depends
                      on the runtime system specific servlet associated with the corresponding endpoint class."

                      Thanks,

                      -Jason

                      • 8. Re: how handle multithreaded web app client?
                        Ole Matzura Novice

                        Thomas,

                        We changed our pooling to only pool created stubs from a singe service instance and this seems to work just as well.. thanks for the tip!

                        /Ole