CODEWITHSUNDEEP
jmsspring-integrationspring-integration-dsl
Shakirov Ramil
Shakirov Ramil

Reputation: 1543

Spring integration messages queue

I have jms message endpoint like:

@Bean
public JmsMessageDrivenEndpoint fsJmsMessageDrivenEndpoint(ConnectionFactory fsConnectionFactory,
                                                            Destination fsInboundDestination,
                                                            MessageConverter fsMessageConverter) {
    return Jms.messageDrivenChannelAdapter(fsConnectionFactory)
            .destination(fsInboundDestination)
            .jmsMessageConverter(fsMessageConverter)
            .outputChannel("fsChannelRouter.input")
            .errorChannel("fsErrorChannel.input")
            .get();
}

So, my questions is did I get next message before current message will be processed? If it will...Did it will get all messages in mq queue until it fills up all the memory? How to avoid it?

Upvotes: 0

Views: 218

Answers (1)

Artem Bilan
Artem Bilan

Reputation: 121177

The JmsMessageDrivenEndpoint is based on the JmsMessageListenerContainer, its threading model and MessageListener callback for pulled messages. As long as your MessageListener blocks, it doesn't go to the next message in the queue to pull. When we build an integration flow starting with JmsMessageDrivenEndpoint, it becomes as a MessageListener callback. As long as we process the message downstream in the same thread (DirectChannel by default in between endpoints), we don't pull the next message from JMS queue. If you place a QueueChannel or an ExecutorChannel in between, you shift a processing to a different thread. The current one (JMS listener) gets a control back and it is ready to pull the next message. And in this case your concern about the memory is correct. You can still use QueueChannel with limited size or your ExecutorChannel can be configured with limited thread pool.

In any way my recommendation do not do any thread shifting in the flow when you start from JMS listener container. It is better to block for the next message and let the current transaction to finish its job. So you won't lose a message when something crashes.

Upvotes: 1

Related Questions