Lingo
  1. Lingo
  2. LINGO-29

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. LINGO-29.txt
        1 kB
        Dan Allen
      2. LINGO-29-lingo1.1.diff
        23 kB
        Jason Dillon
      3. LINGO-29-lingo1.3.diff
        23 kB
        Jason Dillon

        Activity

        Hide
        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
        Jason Dillon added a comment -

        Any update on this?

        Show
        Jason Dillon added a comment - Any update on this?
        Hide
        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
        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
        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
          • Votes:
            4 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated: