JMS Inbound Gateway (RC1) -- bug or config problem?

[kwbeam]

In RC1, I'm using the JMS inbound gateway to get messages from a JMS queue and place them onto a channel:

<jms:inbound-gateway request-channel="eebChannel" connection-factory="connectionFactory" destination="p1"/>

However, after receiving a message it blocks waiting for a reply, even though I don't have a reply-channel set. The desired behavior would be for it to receive the message from the JMS queue (p1) and place it onto the eebChannel and not wait for a reply.

Is this a configuration problem on my part or a bug?

I noticed in the JmsInboundGateway code, it does the following inside the message listener onMessage() method:

Message<?> replyMessage = JmsInboundGateway.this.sendAndReceiveMessage(objec t);

Shouldn't it do:

JmsInboundGateway.this.send(object);

if there is no reply-channel specified?

In the M6 release, the JmsGateway apparently did either a 'send' or a 'sendAndReceive' depending on whether a reply was expected:

listener.setDefaultListenerMethod(this.expectReply ? "sendAndReceive" : "send");

But obviously I don't know the code well enough to say for sure...

[kwbeam]

I should add that I'm attempting to use the jms:inbound-gateway since I want a message-driven listener, not a polling listener, on the inbound JMS queue.

Is this appropriate? Is there a better way to do this without using the jms:inbound-gateway or the jms:inbound-channel-adapter since it polls?

[Mark Fisher]

This is the main question for sure. We need to provide one or the other - a "one-way" option for inbound gateway or an "event-driven" option for inbound-channel-adapter".

I am leaning toward an event-driven inbound-channel-adapter, b/c the distinction we are trying to make between "channel-adapter" and "gateway" is that the former is one-way and the latter is for request/reply.

This would also be consistent with the inbound Mail support where we have a polling "inbound-channel-adapter" but also an "imap-idle-channel-adapter" that is event-driven.

What do you think?

[kwbeam]

I agree with you. An event-driven jms:inbound-channel-adapter seems like the right thing to do, and it would preserve the semantic difference you want to maintain between the channel-adapter and gateway.

Do you think this is something that can be provided in the 1.0 release?

[Mark Fisher]

Yes, I think we should include this in 1.0 if at all possible. Would you mind opening an issue in JIRA?

[kwbeam]

Sure, I'll do that shortly.

[kwbeam]

I've added this to JIRA: INT-477

(URL not included since I'm a newbie ).

[Mark Fisher]

Thank you.

For others who are interested in watching this issue, here is the link:
http://jira.springframework.org/browse/INT-477

[mirror303]

Added a vote in Jira, i have the exact same use-case.

[paulpach]

I have a similar use case, but jms:inbound-gateway is unsuitable for even more reasons:

* I am connecting to a pubsub instead of a queue, I don't see a way to configure the inbound gateway using the xml tag for connecting to pubsubs.

* I have some advanced options that I need to specify in DefaultMessageListenerContainer, specifically, I need to specify cacheLevel, exceptionListener, recoveryInterval, subscriptionDurable, pubSubDomain

* I have my own class derived from DefaultMessageListenerContainer that I use to override some behavior.

I think a simple solution would be to allow me to specify the MessageListenerContainer that I want to use.

So my request is, if you are going to add the capability to jms:inbound-channel-adapter to do event-driven messaging, go all the way and allow me to specify the MessageListenerContainer, for both jms:inbound-channel-adapter and jms:inbound-gateway

I opened INT-482 for this (can not post url ).