-
1. Re: how handle multithreaded web app client?
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?
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?
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?
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?
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?
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?
"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?
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