Hi Patrick,
Oops, I have not mentioned about the deployment. To use Sandesha as a client
BUT inside a server (say inside a servlet container) we need to deploy
"RMService" as the asynchronous endpoint for acks and responses. The
deployment configuration is as follows.
----------------------------------------------------------
<service name="RMService" provider="Handler">
<requestFlow>
<handler
type="java:org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler"></hand
ler>
<handler
type="java:org.apache.axis.message.addressing.handler.AddressingHandler"></h
andler>
</requestFlow>
<parameter name="handlerClass"
value="org.apache.sandesha.ws.rm.providers.RMClientProvider"/>
<parameter name="className"
value="org.apache.sandesha.samples.interop.RMService"/>
<parameter name="allowedMethods" value="*"/>
<parameter name="scope" value="request"/>
</service>
----------------------------------------------------------
Thanks,
Jaliya
-----Original Message-----
From: Jaliya Ekanayake [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 31, 2005 11:45 AM
To: 'Patrick Collins'; '[email protected]'
Subject: RE: Sandesha: RMInvoker
Hi Patrick,
Yes, this leads to a deadlock.
We did the followings to correct the above.
It has been a requirement for Sandesha to use a thread pool to minimize the
deadlocks and also to manage the threads. So we use Axis's own thread pool
and let the RMInvoker and Sender utilize them.
I tested your scenario with the same configuration and it works fine with
this new modification. In order to do it correctly I did two minor
modifications to the SandeshaContext.
1. Added a constructor SandeshaContext(boolean insideServer){}
//This will inform the SandeshaContext not to start a separate Listener
2. Added a setter to set the source URL to the Call using the
SandeshaContext.
//With this, if a web service invoke another service then it can set the
"source URL" appropriately. (according to the URL of the web application)
Following code fragment is the one I used in MyServiceA. (This service will
call MyServiceB that is deployed in the same server and then send a response
to the client.
-------------------------------------------------------
String ret=null;
try {
Service service = new Service();
Call call = (Call) service.createCall();
//This will inform SandeshaContext not to start a separate Listener
SandeshaContext ctx = new SandeshaContext(true);
ctx.addNewSequeceContext(call, targetURL, "urn:test:process",
Constants.ClientProperties.IN_OUT);
//Using this we can set the source URL appropriately
ctx.setSourceUrl(call,"http://127.0.0.1:8080/axis/services/RMService";);
ctx.setSendOffer(call);
call.setOperationName(new QName("http://tempuri.org/";, "process"));
call.addParameter("arg1", XMLType.XSD_STRING, ParameterMode.IN);
call.setReturnType(org.apache.axis.encoding.XMLType.XSD_STRING);
ctx.setLastMessage(call);
ret = (String) call.invoke(new Object[]{str});
System.out.println("The Response for First Messsage is :" + ret);
ctx.endSequence(call);
} catch (Exception e) {
e.printStackTrace();
}
return ret;
}
------------------------------------------------------
Please take a fresh check out and test your application now.
We are really happy to see your contribution. There can be some changes to
the RMInvoker (since we are using thread pool). So If possible please submit
a patch so that we can use the same RMInvoker inside a J2EE container, may
be passing a thread pool or some worker threads.
Thanks,
Jaliya
-----Original Message-----
From: Patrick Collins [mailto:[EMAIL PROTECTED]
Sent: Friday, May 27, 2005 3:03 AM
To: [email protected]
Subject: Sandesha: RMInvoker
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
