Hi, I have come across an issue testing Sandesha with both the client and server deployed on the same axis instance.
My scenario is this: Application Client --> WSRM Invoke --> Web Service 1 --> WSRM Invoke --> WebService 2. In this case, Web Service 1 will be accessed via the RMInvoker after all of the normal WSRM "handshaking" has taken place between the Application Client and the Service 1 WSRM provider. The RMInvoker runs in its own thread, polling the queue for the next message to process. In my case, it gets the message and invokes Web Service 1. So far so good. Web Service 1 then attempts to invoke Web Service 2 with WSRM enabled. The problem is that eventually, the request message (from WS1 to WS2) is queued and waits for the RMInvoker to pick it up. This creates a deadlock condition. The RMInvoker thread is still processing the invoke to WS1 and will never pick up the invoke to WS2 (eventually, the original request times out and processing continues - but it's too late at that point). I have attached a development fix (which gets me through my test cases, however I am still working on understanding all of the interactions that take place at the queue level) for the RMInvoker. My suggestion for implementing a more robust fix would be to expose an interface (accessed via a factory) for the RMInvoker layer. The impl could be specified in sandesha.properties (or perhaps use the Commons Configuration). This would hide all of the thread code (which is a requirement for me, as our app runs in various J2EE containers where direct thread creation and file system access are restricted) and provide a pluggable approach for configuring the invoker. I would be more than happy to contribute at your request. Regards, Patrick
RMInvokeScheduler.java
Description: Binary data
RMInvoker.java
Description: Binary data
RMInvokerDelegate.java
Description: Binary data
