Lingo

Asynchronous call with remote parameter does not work

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.2.1
  • Fix Version/s: None
  • Labels:
    None
  • Environment:
    Linux, Java 5, Spring 2.0-rc2, ActiveMQ 4.0.2
  • Number of attachments :
    3

Description

I'm trying to implement an asynchronous method with a result listener just as in the examples:

public void asyncRequestResponse(String stock, ResultListener listener)

But when I call this method the server complains about a missing destination:

java.lang.UnsupportedOperationException: A destination must be specified.
at org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:448)
at org.logicblaze.lingo.jms.impl.OneWayRequestor.doSend(OneWayRequestor.java:196)

I have debugged the code and found out that the destination for the response message the server tries to send is null. And that's because the JMSReplyTo field of the request message is also null.

So I debugged the client side and found out that the remote message is classified as a oneway method by the metadata strategy because the method does have no return value. The invoke method of the JMSClientInterceptor checks this first and if it sees that the method is a OneWay method it just uses the send method of the Requestor which does not set a JMSReplyTo address. I think this is the problem.

I hope this was detailed enough to find the problem.

  1. Text File
    LINGO-29.txt
    26/Feb/07 6:19 PM
    1 kB
    Dan Allen
  2. File
    LINGO-29-lingo1.1.diff
    03/Nov/06 12:38 AM
    23 kB
    Jason Dillon
  3. File
    LINGO-29-lingo1.3.diff
    03/Nov/06 12:37 AM
    23 kB
    Jason Dillon

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Klaus Reimer added a comment -

Just to make this clear: The exception does not occur on the client side when sending the REQUEST. I definetly have set the correct destination in the spring configuration because otherwise the request would not reach the server. The exception occurs when the server tries to send the RESPONSE for the request. So when the server tries to set a property in the ResultListener object then the exception occurs because the ReplyTo field of the request is null.

Show
Klaus Reimer added a comment - Just to make this clear: The exception does not occur on the client side when sending the REQUEST. I definetly have set the correct destination in the spring configuration because otherwise the request would not reach the server. The exception occurs when the server tries to send the RESPONSE for the request. So when the server tries to set a property in the ResultListener object then the exception occurs because the ReplyTo field of the request is null.
Hide
Permalink
johan1 added a comment -

I'm having the exact same issue using Spring 2.0-rc3, Sun jre1.5.0_07, ActiveMQ 4.0.1. Following the instructions at http://lingo.codehaus.org/Async+Example and http://jroller.com/page/sjivan?entry=asynchronous_calls_and_callbacks_using doesn't seem to be sufficient. Any advices or working examples are more than welcome.

Show
johan1 added a comment - I'm having the exact same issue using Spring 2.0-rc3, Sun jre1.5.0_07, ActiveMQ 4.0.1. Following the instructions at http://lingo.codehaus.org/Async+Example and http://jroller.com/page/sjivan?entry=asynchronous_calls_and_callbacks_using doesn't seem to be sufficient. Any advices or working examples are more than welcome.
Hide
Permalink
johan1 added a comment -

I just tried it with Lingo 1.1 and it works.

Show
johan1 added a comment - I just tried it with Lingo 1.1 and it works.
Hide
Permalink
Jason Dillon added a comment -

Attached LINGO-29-lingo1.3.diff, which is patch to http://svn.codehaus.org/lingo/trunk/lingo/

This turns my pingpong example into a set of unit tests. Only one of the tests pass now, which is the AsyncPingResponderSyncPingPongTest. The others (SyncPingPongTest, PingPongTest) fail on the server side with exceptions, when they should pass.

Show
Jason Dillon added a comment - Attached LINGO-29 -lingo1.3.diff, which is patch to http://svn.codehaus.org/lingo/trunk/lingo/ This turns my pingpong example into a set of unit tests. Only one of the tests pass now, which is the AsyncPingResponderSyncPingPongTest. The others (SyncPingPongTest, PingPongTest) fail on the server side with exceptions, when they should pass.
Hide
Permalink
Jason Dillon added a comment -

Attached LINGO-29-lingo1.1.diff, which is patch to http://svn.codehaus.org/lingo/tags/LINGO_1_1/lingo/

This is the same set of tests in the 1.3 patch, only with altered spring configs to work with ActiveMQ 3.x

All of these tests pass.

Show
Jason Dillon added a comment - Attached LINGO-29 -lingo1.1.diff, which is patch to http://svn.codehaus.org/lingo/tags/LINGO_1_1/lingo/ This is the same set of tests in the 1.3 patch, only with altered spring configs to work with ActiveMQ 3.x All of these tests pass.
Hide
Permalink
Jason Dillon added a comment -

As the above comments note, I see the same problems with Lingo 1.3, 1.2 and 1.2.1... where no problems exist in 1.1.

I'd really appreciate it if someone could look into this and find a solution. I am not yet familiar enough with the Lingo codebase to determine what the proper fix is.

Show
Jason Dillon added a comment - As the above comments note, I see the same problems with Lingo 1.3, 1.2 and 1.2.1... where no problems exist in 1.1. I'd really appreciate it if someone could look into this and find a solution. I am not yet familiar enough with the Lingo codebase to determine what the proper fix is.
Hide
Permalink
Yibing Li added a comment -

Hi,

I have done a quick fix. It seems to be working now. I don't know how to access your full test suite so cannot fully test it. Can somebody from the dev team verify it please?

The fix follows:
--------------------

Modify the 'send(Destination destination, Message message)' method in the class OneWayRequestor as shown below:

public void send(Destination destination, Message message) throws JMSException

{ /*the line below is newly added. For OneWayRequestor, "populateHeaders(message)'' does nothing. But its subclasses all set its jmsReplyTo to a temp reply queue, so this should fix the problem. Of course, this fix assumes that all the method calls carryinig callback arguments will always be made by using SingleThreadedRequestor or MultiplexingRequestor (which is the case now). If you use OneWayRequestor directly for such calls, then a more complete solution needs to be worked out. The Requestor interface has to be changed to add methods which will differentiate the cases where one way request has no callback arguments and where it has at least one callback argument. I'm not sure if that's more desirable. */ populateHeaders(message); //added new line. send(destination, message, getTimeToLive()); }
Show
Yibing Li added a comment - Hi, I have done a quick fix. It seems to be working now. I don't know how to access your full test suite so cannot fully test it. Can somebody from the dev team verify it please? The fix follows: -------------------- Modify the 'send(Destination destination, Message message)' method in the class OneWayRequestor as shown below: public void send(Destination destination, Message message) throws JMSException { /*the line below is newly added. For OneWayRequestor, "populateHeaders(message)'' does nothing. But its subclasses all set its jmsReplyTo to a temp reply queue, so this should fix the problem. Of course, this fix assumes that all the method calls carryinig callback arguments will always be made by using SingleThreadedRequestor or MultiplexingRequestor (which is the case now). If you use OneWayRequestor directly for such calls, then a more complete solution needs to be worked out. The Requestor interface has to be changed to add methods which will differentiate the cases where one way request has no callback arguments and where it has at least one callback argument. I'm not sure if that's more desirable. */ populateHeaders(message); //added new line. send(destination, message, getTimeToLive()); }
Hide
Permalink
Jason Dillon added a comment -

Any update on this?

Show
Jason Dillon added a comment - Any update on this?
Hide
Permalink
Dan Allen added a comment -

Crap! I just spent half the day on this problem before I discovered this issue report! As it turns out, the proposed solution to add the call to populateHeaders(message) in the OneWayRequestor works perfectly. However, I propose that this call be added to the two doSend() methods instead, just after the call to validateDestination.

Show
Dan Allen added a comment - Crap! I just spent half the day on this problem before I discovered this issue report! As it turns out, the proposed solution to add the call to populateHeaders(message) in the OneWayRequestor works perfectly. However, I propose that this call be added to the two doSend() methods instead, just after the call to validateDestination.
Hide
Permalink
Dan Allen added a comment -

Patch to call the populateHeaders() method prior to sending so that the JMS replyTo property is set appropriately.

Show
Dan Allen added a comment - Patch to call the populateHeaders() method prior to sending so that the JMS replyTo property is set appropriately.
Hide
Permalink
Craig Baker added a comment -

Double crap, wasted a lot of time on this issue. Thanks Yibing your work around did the trick.

Looks like Lingo is dead. A year to fix a bug.

Show
Craig Baker added a comment - Double crap, wasted a lot of time on this issue. Thanks Yibing your work around did the trick. Looks like Lingo is dead. A year to fix a bug.

People

  • Assignee:
    Unassigned
    Reporter:
    Klaus Reimer
Vote (4)
Watch (5)

Dates

  • Created:
    Updated: