Announcement Announcement Module
No announcement yet.
Bug in deducing the reply channel of a ServiceActivator Response message? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Bug in deducing the reply channel of a ServiceActivator Response message?

    Hi, I think that I have found a bug in 2.0.0.M6 (also in M5) in the AbstractReplyProducingMessageHandler class

    My situation is that my Service Activator returns a new Message<DeviceIdentificationDTO> with the 'REPLY_CHANNEL' message header set to a channel name in response to a received Message<DiscoverMessageDTO>

    The definition of the service activator is like this, e.g no 'output-channel' is set (bean reference omitted):

    The result here is the following stack trace:
    1445870 [task-scheduler-2] ERROR [] org.springframework.integration.handler.LoggingHan dler - org.springframework.integration.core.ChannelResolu tionException: unable to resolve reply channel for message: [[email protected] b69d75d][Headers={EVENT_TYPE=INBOUND_DISCOVER, $ip_hostname=localhost, ROUTING_TYPE=INBOUND_ROUTING, $ip_address=, $timestamp=1281451126710, $history=[udpReceicer], $id=f08d8ecf-a743-4474-a4b2-1b19ac28c07c, DIRECTION_TYPE=DIRECTION_RECEIVE}]

    It is fact that the reply message payload is an instance of a DeviceIdentificationDTO.

    Why does this happen:
    I think the reason is in org.springframework.integration.handler.AbstractReplyProducingMessageHandler#handleMessage Internal(...)
    in line 102 with the code:
    MessageChannel replyChannel = resolveReplyChannel(message, this.outputChannel);

    It tries to find the reply channel for the reply message from the received message, instead from the result (line 91). I think that it would work (in this case) if line 102 would be like this:
    MessageChannel replyChannel = resolveReplyChannel(result, this.outputChannel);

    Please have a look at it.
    Regards Markus

  • #2
    The "reply channel" is *supposed* to be determined from the request message.

    The idea is very common in messaging, and the same approach is used in JMS (and described as the "Return Address" pattern in EIP). A Producer needs to send a request Message and wait for a reply Message. Therefore, it adds a "replyTo" header to the *request* and sends it along. Then, it can wait for the reply Message to arrive on that channel it specified.

    Does that make sense?

    Perhaps you are actually trying to perform the role of a "Router"?



    • #3
      Hm, it makes sense what you write.. It is possible to solve my problem with a router, so I will do that. I will consult the 'Book' to read why it is not a good idea to define a reply channel in a message for further dispatching ( I guess I already know..)

      Thanks for your fast response
      Regards Markus


      • #4
        No problem. Feel free to post a follow-up here as you consider the Router-based approach. I think what you're facing is rather common... people tend to conflate service-activator and router (or filter, or transformer, etc), but once the "pipes-and-filters" aha! moment occurs, there's no turning back