Suggestions on improving performance with Spring JMS

2
votes

I am using Spring JMS Listener to read messages from AMQP queue. Using transacted session to handle the failure if a message fails in processing. On failure redirecting the message to another queue.

Tried to used the concurrency option but can't use it as my message processing need to pick messages in order.

To process around 5000 messages in queue its taking around 30mins.. Reading the message from queue and saving in DB.

Configuration:

<jms:listener-container container-type="default" connection-factory="connectionFactory"    acknowledge="transacted">  

<jms:listener destination="queueName" ref="processQueueMessage" method="onMessage" />

</jms:listener-container>

Looking for another alternative ways of processing the messages or any suggestion on improving existing process.

1
jmsspring-jms
Spring JMS listener container is a real pain in the #ss. I'd suggest to use apache camel with it's great sjms or amqp components. - Konstantin V. Salikhov
I guess you meant ActiveMQ. Do you have concrete facts that indicate Spring JMS is slowing this down? Talking about performance, you should try to design your system in such a way that messages can be consumed in parallel. After all, all this is asynchronous so you should not have to care about the order. Right now, your 5k messages are processed in a single thread: that's the first thing to fix. - Stephane Nicoll
Hi Stephane, You are right abt ActiveMQ. As I mentioned earlier I can't use the concurrency option for processing. This is an existing design and trying ways to improve the process. Looking at alternatives instead of complete redesign. Spring JMS processes messages one at a time right. Checking to see if I can retrieve all the messages and process them as needed? - user3597268
What would that change? You're going to serialize the processing anyway and you're probably going to end up with the same processing time. I am still confused as why you think Spring JMS needs an optimization until you can isolate the slowest component. There are tuning options we can apply with highly concurrent environment but that's not your case here. Again, your mono-thread processing is most probably the culprit here. - Stephane Nicoll

1 Answers

0
votes

Updates: Did some analysis on message consumption alone. So removed the persistence portion of processing as suggested by Stephane. Wrote a test case to test message consumption. Result: To consume 5000 messages it took around 30-35 secs.

Next Steps: Looking into DB persistence to see if I can find the bottleneck.