Develop Reference

Receive JMS messages only on node they in which they were produced

I am using Spring's DefaultMessageListenerContainer to receive messages from an ActiveMQ queue. This application is the sole producer of messages to this queue. The application is clustered so in the case that I have two instances (instance1, instance2) how can I ensure that messages produced and sent to the queue from instance1 are received by the message listener on instance1 and messages produced and sent to the queue from instance2 are received by the message listener on instance2? My initial though was to set the messageSelector property of the DefaultMessageListenerContainer, but I'd like each application to have the same configuration.

You can't do that; you either need a separate queue for each instance or use a message selector.

How to Prevent Spring AMQP from Blocking on Unacked Messages?

I have a #RabbitListener annotated method for which Spring AMQP blocks after returning from the method. The underlying SimpleRabbitListenerContainerFactory uses AcknowledgeMode.MANUAL. I don’t want to acknowledge the message in the listener method, yet.
Is there any way to not have Spring AMQP block in such a scenario?
In more detail
I use a listener like this:
#RabbitListener(queues = "#{ #myQueue }")
void recordRequestsFromMyMessages(
#Payload MyMessage myMessagePayload,
#Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag,
Channel channel) {
// record relevant parts of the given message and combine them with
// parts from previous/future messages
// DON'T acknowledge the consumed message, yet; instead only keep a
// record of the channel and the delivery tag
}
Since I batch/combine multiple messages before I actually process them (asynchronously) later, I don’t want to acknowledge the consumed message right away. Instead, I only want to do this once the messages have been successfully processed later.
With my current approach, Spring AMQP blocks after returning from calling the recordRequestsFromMyMessages method above and no further messages are consumed from the same queue anymore.
This SO answer suggests that batch processing should work, however, I’m not sure how.

It's not the container that's "blocking".
You need to increase the prefetchCount on the container (default 1) - the broker only allows that number of unacked messages to be outstanding.

Spring integration dynamic message selector

I have an application with two queues, the first queue has control messages and the other has data messages. Based on the JMSCorrelationID of the message from the control queue i need to read only messages with that JMSCorrelationID from the data queue.
I am able to selectively read messages from the data queue using a selector defined as below.
<int-jms:message-driven-channel-adapter id="messageDrivenInboundAdapter"
channel="inboundChannel" destination-name="inboundMQ"
selector="JMSCorrelationID = 'JMSCORELIS1234'"
connection-factory="connectionFactory" extract-payload="false"/>
I need to dynamically update value for the JMSCorrelationID for the selector based on messages received on a different channel.
Is it possible to do that? Is there a different way to implement this solution in spring integration?

It's not possible with the message-driven adapter; the selector is baked into the message listener container constructed during initialization.
You can change the message selector of a polled <inbound-channel-adapter/>; the change will take effect on the next poll.
You can get a handle to the JmsDestinationPollingSource with auto wiring, or via the bean name (adapterId.source).

JMS Inbound Gateway - error handling when reply destination queue send is not possible

We have an EIP flow which uses annotation-based spring:4.2.x APIs, spring-integration:4.2.x APIs and spring-integration-java-dsl:1.1.0 APIs to receive messages from a Websphere MQ Queue, do some processing and finally return responses to another Websphere MQ Queue. For this flow, we are using a JMS Inbound Gateway to synchronously receive messages from one queue, process them and send the responses back to another queue.
The JMS Inbound Gateway is configured with an errorChannel so that RuntimeExceptions are routed to it (this works fine). However during tests, when we purposely apply a PUT_INHIBIT on the flow's response Websphere MQ queue (i.e. to cause the flow to be unable to send responses back to the reply queue), the spring logs show the following WARNING log message:
WARN ... - Execution of JMS message listener failed, and no ErrorHandler has been set.
javax.jms.JMSException: MQJMS2007: failed to send message to MQ queue.
We know we can remove that WARNING log by configuring an ErrorHandler on the MLC itself but, the reason this is causing us problems is that when we route a response back, we actually route using a .routeToRecipients() call with .setIgnoreFailures(false) and two recipients - the first recipient routing to the JMS Inbound Gateway's replyChannel and the second routing to a post-send flow so that we can do DB updates, etc. The idea here being that if the first recipient send fails (i.e. when the response queue is not available), the post-send flow doesn't execute but instead an error handling flow executes instead (e.g. errorChannel flow). But in the described error scenario, we see the warning log, and the flow's post-send flow still executes instead of the errorChannel's flow...
It is as though, at this point, the JMS Inbound Gateway's errorChannel no longer applies. Is this correct? And is this intended behaviour? And if it is, does this mean that we should use Inbound/Outbound Adapters instead of an Inbound Gateway for our response post-send intent?
JMS MLC Configuration:
#Bean( destroyMethod = "shutdown")
public DefaultMessageListenerContainer serviceMLC() throws Exception {
DefaultMessageListenerContainer mlc = new DefaultMessageListenerContainer();
mlc.setAutoStartup(false);
mlc.setConnectionFactory(serviceCCF);
mlc.setDestination(requestMqQueue);
mlc.setAcceptMessagesWhileStopping(false);
return mlc;
}
JMS Inbound Gateway Configuration:
#Bean
public IntegrationFlow serviceFlow() {
return IntegrationFlows
.from(Jms
.inboundGateway(serviceMLC)
.autoStartup(true)
.defaultReplyDestination(responseMqQueue)
.replyChannel(responseOutCh)
.replyTimeout(180000)
.correlationKey("JMSCorrelationID")
.errorChannel(serviceErrorCh)
)
.channel(serviceInCh)
.get();
}

Yes; the gateway doesn't work that way.
When you send the reply to the gateway, it is queued in the gateway until the thread returns to the gateway; at which time, the reply is picked up and sent. So, the failure to send does not occur until later (after your second recipient flow is invoked).
Yes, to do what you want, you should use channel adapters instead because the failure will run directly on the calling thread.

What is the difference between a MessageListener and a Consumer in JMS?

I am new to JMS. As far as I understood Consumers are capable of picking messages from queue/topic. So why do you need a MessageListener because Consumers will know when they have picked up messages? What is the practical use of such a MessageListener?
Edit:From the Javadoc of MessageListener:
A MessageListener object is used to receive asynchronously delivered
messages.
Each session must insure that it passes messages serially to the
listener. This means that a listener assigned to one or more consumers
of the same session can assume that the onMessage method is not called
with the next message until the session has completed the last call.
So I am confused between the usage of the terms asynchronously and serially together. How do these two terms relate in describing the feature of MessageListener?

The difference is that MessageConsumer is used to receive messages synchronously:
MessageConsumer mc = s.createConsumer(queue);
Message msg = mc.receive();
For asynchronous delivery, we can register a MessageListener object with a message consumer:
mc.setMessageListener(new MessageListener() {
public void onMessage(Message msg) {
...
}
});

from the docs:
For synchronous receipt, a client can request the next message from a message consumer using one of its receive methods.
For asynchronous delivery, a client can register a MessageListener object with a message consumer.

One major difference as per my knowledge not stated in others answers is that MessageConsumer can make use of MessageSelectors and hence has capability to consume messages that it's interested in, where as MessageListener will listen to all messages.
From the J2EE tutorial doc http://docs.oracle.com/javaee/5/tutorial/doc/bnceh.html
JMS Message Selectors
If your messaging application needs to filter the messages it receives, you can use a JMS API message selector, which allows a message consumer to specify the messages it is interested in. Message selectors assign the work of filtering messages to the JMS provider rather than to the application.