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

[Ivan Velykorodnyy]

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"
                                        channel="inChannel"
                                        connection-factory="myCF"
                                        message-converter="myConverter"
                                        destination="jmsIn"/>

    <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"
                                  connection-factory="myCF"
                                  message-converter="myConverter"
                                  destination="jmsOut"/>

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 :\

[Gary Russell]

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?

[Ivan Velykorodnyy]

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