Re: Re: async call issue

>I think I found the cause for this behavior. Basically Lingo creates
>only
>one JMS session for the "server" /consumer which is exported via
>org.logicblaze.lingo.jms.JmsServiceExporter and a JMS Session
>essentially is
>required to (per jms spec) serialize execution of consumer message
>listeners.
>
>This behaviour does not map well to the semantics of asynchronous calls
>which Lingo provides as the remoting provider. (alteast based on my
>interpretation of expected behavior).
>
>There are a couple of possible solutions that I can think of right now
>:
>
>The single consumer on the server side should simply add requests to a
>thread pool for execution.. This would effectively translate to a JMS
>Session which does not serialize execution of registered listeners.
>Webmethods has a flag which allows you to change the behavior from
>serialized to pooled execution. This behaviour translates better to a
>remote
>method invocation protocol.
>
>The other options is that Lingo creates a separate session-destination
>for
>each method in the exported service. This way each method call on the
>service API (potentailly from different clients) does not block for
>other
>method calls to complete. This option is not as good as the first one
>as the
>same method call from different clients will be serialized.
>
>Let me know your thoughts.
>
>Sanjiv
>
>On 5/13/06, Sanjiv Jivan wrote:
>>
>>I decided to upgrade to the latest Lingo/Active MQ CVS versions and
>>see
>>if that helps resolve this issue. I noticed that in the test case
>>
>>\src\test\org\logicblaze\lingo\example\ExampleTest.java
>>
>>the asynchronous test case "testAsyncRequestResponse" has been
>>disabled.
>>
>>public void TODO_testAsyncRequestResponse() throws Exception {
>>..
>>}
>>
>>Was there any reason for doing this? Are they any known issues with
>>asynchronous calls?
>>
>>The issue I've encountered is a show stopper for us. The asynchronous
>>call
>>returns control to the client but not further calls to the server are
>>not
>>possible while the previous method call is still executing on the
>>server.
>>I'm trying to debug this issue myself but would appreciate some
>>comments/investigation from the Lingo team as well.
>>
>>Thanks,
>>Sanjiv
>>
>>
>>
>>---------- Forwarded message ----------
>>From: Sanjiv Jivan < sanjiv.jivan@...>
>>Date: May 9, 2006 2:49 PM
>>Subject: Re: async call issue
>>To: user@...
>>
>>
>>I should mention that I ran the test under a debugger but wasn't able
>>to
>>pin point the issue. The source of the issue seems to be with the
>>temporary
>>queues created/shared in MultiplexingRequestor.
>>
>>
>>On 5/9/06, Sanjiv Jivan wrote:
>>>
>>>Hi,
>>>I created an issue for this but figured I'd post my question incase
>>>anyone else had encountered a similar issue.
>>>
>>>Making an async call to a service prevents subsequent calls to the
>>>service from being made prior to when the async method on the server
>>>completes execution.
>>>
>>>Consider the Lingo test case
>>>org.logicblaze.lingo.example.ExampleTest#testClient
>>>
>>>Change the delay in ExampleServiceImpl.asyncRequestResponse(String
>>>stock, ResultListener listener) to 35 seconds.
>>>
>>>public void testClient() throws Exception {
>>>// START SNIPPET: simple
>>>
>>>// lets lookup the client in Spring
>>>// (we could be using DI here instead)
>>>ExampleService service = (ExampleService) getBean("client");
>>>
>>>// regular synchronous request-response
>>>int i = service.regularRPC("Foo");
>>>System.out.println("Found result: " + i);
>>>
>>>// async request-response
>>>TestResultListener listener = new TestResultListener();
>>>service.asyncRequestResponse("IBM", listener);
>>>
>>>//------------> sanjiv : new test code
>>>int ret = service.regularRPC("foo");
>>>System.out.println("return value is " + ret);
>>>//------------> sanjiv : end new test code
>>>
>>>// the server side will now invoke the listener
>>>// objects's methods asynchronously
>>>// END SNIPPET: simple
>>>
>>>listener.waitForAsyncResponses(2);
>>>
>>>System.out.println("Found results: " + listener.getResults());
>>>}
>>>
>>>In the example above, the async call is made (which runs for 35
>>>seconds
>>>on the "server"). However when the next call of "ret =
>>>service.regularRPC("foo");" is made on the client, it blocks and
>>>eventually times out.
>>>
>>>If we call an asynchronous call instead of service.regularRPC, that
>>>message is never received by the server.
>>>This is the same behaviour when the destination is a Queue or a
>>>Topic.
>>>
>>>Thanks,
>>>Sanjiv
>>>
>>
>>