Announcement Announcement Module
No announcement yet.
"no output-channel or replyChannel header available" in BridgeHandler Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • "no output-channel or replyChannel header available" in BridgeHandler

    Hi Team!

    Is the following behavior expected (SI 2.2.RELEASE)? When the pub-sub channel is reused for req/res via Gateway and uni-directional flows, the BridgeHandler (I suppose subscribed for the Gateway reply purposes) throws "no output-channel or replyChannel header available" exception. And that may prevent the other listeners (of pub-sub-channel) to perform their job in case of BridgeHandler is registered before them.

    Here's an example:

    public interface GatewayService {
    	@Gateway(requestChannel= "inChannel",
    			replyChannel= "gatewayReplyChannel")
             public Sth serve(Sth sth);
        <!-- flow1 starts/ends here -->
        <si:gateway id="gatewayService" service-interface="xxx.GatewayService"/>
        <!-- flow2 starts here -->
        <jms:message-driven-channel-adapter id="inAdapter"
        <si:publish-subscribe-channel id="inChannel" datatype="xxx.Sth"/>
        <!-- flow1 is subscribed FIRST -->
        <si:bridge input-channel="inChannel" output-channel="gatewayReplyChannel"/>
        <si:publish-subscribe-channel id="gatewayReplyChannel" datatype="xxx.Sth"/>
        <si:logging-channel-adapter channel="gatewayReplyChannel"/>
        <!-- jms outbound adapter is subscribed SECOND and supposed to be always sending messages -->
        <!-- flow2 ends here -->
        <jms:outbound-channel-adapter channel="inChannel"
    To reproduce, after initial startup
    1. submit message via flow2: into "jmsIn" all will succeed and the message will be published into "jmsOut"
    2. submit message via flow1: via gateway - it will succeed and you'll get reply
    3. submit message via flow2: into "jmsIn" and message processing will be break with "no output-channel or replyChannel header available"

    Shouldn't BridgeHandler be silent on the step 3 ?

    Workaround: change the order of subscribers, so the flow1 listener is the last one. The exception will still be thrown :\
    Last edited by Ivan Velykorodnyy; Feb 23rd, 2013, 08:00 AM.

  • #2
    I would expect messages via the jms inbound adapter to ALWAYS fail - because the bridge is trying to send the message to gatewayReplyChannel, and such messages didn't originate at the gateway, so the framework can't route it.

    You can set 'ignore=failures="true"' on 'inChannel' and the second subcriber will still get the message.

    However, it would probably be better to add a <filter /> (expression="headers.replyChannel != null") before the bridge so it doesn't receive messages that didn't originate at the gateway.

    Can you explain exactly what you are trying to achieve?


    • #3
      Ok, then it's expected behavior, it's not obvious and there's a trap I got into.

      I'm trying to direct different pub/sub and req/res flows into the shared sequence of endopoints and actually it works. I'll put a filter as you advised to avoid noisy errors in the log. Thanks