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

Code:

---

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

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?

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