[JBoss Web Services Development] New message: "Re: Parallel invocations of JaxWS services and getPort"
by Andrew Dinn
JBoss development,
A new message was posted in the thread "Parallel invocations of JaxWS services and getPort":
http://community.jboss.org/message/526276#526276
Author : Andrew Dinn
Profile : http://community.jboss.org/people/adinn
Message:
--------------------------------------------------------------
richard.opalka(a)jboss.com wrote:>
> Hi Andrew,
>
> this is the problem of *broken by design JAX-WS specification*
>
> *Explanation:*
> One of the problems when reusing proxy concurently is JAX-WS specification allows you to set invocation related properties on the proxy using BindingProvider methods. Consider the following code:
>
> public void configureSession(EchoService serviceProxy, boolean keepSession)
> {
> BindingProvider bp = (BindingProvider)serviceProxy; bp.getRequestContext().put( BindingProvider.SESSION_MAINTAIN_PROPERTY, keepSession );
> }
>
> If you would call above method on one proxy instance in e.g. 2 threads concurrently and each thread will set different keepSession policy, how would you implement this properly for the following scenario?
>
> thread1.configureSession(proxy, true);
> thread2.configureSession(proxy, false);
> thread1.callService(proxy);
> thread2.callService(proxy);
> assertThereAreSessions(thread1);
> assertThereAreNoSession(thread2);
>
> Do you see what I mean?
Yes, I understand that is the problme. That was what I was trying tyo explain.
> mailto:richard.opalka@jboss.com wrote:
>
> *Suggestion:*
>
> Create/use service proxy per thread, not reuse it for multiple threads
>
Hm, I obviously did nto make myself clear. I am creating a new proxy for each thread. The problem is that they still interfere with each other. My code looks like this
> Service myService = getMyService(name, wsdl)
> final MyPort port1 = myService.getPort(endpointRef, MyPort.class, new AddressingFeature(true));
> final MyPort port2 = myService.getPort(endpointRef, MyPort.class, new AddressingFeature(true));
> configurePort(port1);
> cvonfigurePort(port2);
> Thread thread1 = new Thread() {
> port1.myMethod()
> }
> Thread thread2 = new Thread() {
> port2.myMethod()
> }
>
> thread1.start();
> thread2.start();
>
So, the problem appears to be happening even when I create a different port for each thread. Occasionally, the data associated with port 1 is overwritten and I end up with two calls on the server side both using the data from port 2. The data in question is set by a JaxWS handler on the calling side and read by a JaxWS handler on the server side. The client adds a header and the server removes it and uses it to set up the current transaction for the thread in a ThreadLocal.
I traced the code using Byteman to bytecode-inject print statements into the client just before the call to the proxy method and into the server as it enters the service method. Wen I run with 10 threads in parallel I occasionally see distinct values on the client side getting replaced with one value on the server side. If I switch on any other trace or inject more printouts the error does not normmally show because the timing of the threads changes.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/526276#526276
14 years, 4 months
[JCA Development] New message: "Re: JBJCA-272 - Standalone validator tool"
by Jesper Pedersen
JBoss development,
A new message was posted in the thread "JBJCA-272 - Standalone validator tool":
http://community.jboss.org/message/526115#526115
Author : Jesper Pedersen
Profile : http://community.jboss.org/people/jesper.pedersen
Message:
--------------------------------------------------------------
> validator/Main ra16inout.rar
Yes, but through shell scripts (validate.sh / validate.bat), which you meant
The rest looks good.
1. The unjar should happen to java.io.tmpdir, and of course cleaned up afterwards.
2. The validator tool should reference the JCA API and our public API JARs so those classes always are resolved
3. Yes, this is shared with the deployer - so it should be moved to .deployers.common
4. Same as 3)
5. Correct
6. Corect
7. Correct
8. The output should go into files (current directory or directory specified by -output) - and an error code should be set if there are errors (System.exit(1))
9. A short description should go to the console (maybe we can add a -quite flag - if the user don't want that)
This would make a good first revision of the tool IMHO.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/526115#526115
14 years, 4 months