is there a configurable JMS Receiver bean?

[atanum]

Hi,

I am new to Spring JMS. I used DefaultMessageListenerContainer with the following configuration

<bean id="listenerContainer" class="org.springframework.jms.listener.DefaultMes sageListenerContainer" depends-on="messageListener">
<property name="connectionFactory" ref="usageListenConnectionFactory" />
<property name="concurrentConsumers" value="5" />
<property name="receiveTimeout" value="300000" />
<property name="destination" ref="usageListenQueue" />
<property name="messageListener" ref="messageListener" />
</bean>

However this does not meet our requirement. We want the Container to poll for messages every 5 minutes. The value of 300000 works like this only if there are no messages on the queue. But if there are messages on the queue, it keeps retrieving them. Is there a Listener implementation by Spring that will wake up every 5 mins (or some other confiugurable interval) ignoring the load on the queue ?

If there is no such implementation, I am thinking of writing piece of logic using Quartz that will wake up every 5 mins and receive any messages synchronously. So I think I am asking about a configurable JMS Receiver bean, if any available in Spring.

Many many thanks

- atanum

[vijaycr]

You can use the Timertaskexecutor and set a delay.

Then i think each consumer would only consume <maxMessagesPerTask> or 10 (default) number of messages per run, if you can set <maxMessagesPerTask> to reasonable value based on your load then it could work for you.

[vijaycr]

The value of 300000 works like this only if there are no messages on the queue. But if there are messages on the queue, it keeps retrieving them.

If I understand the above correctly, You want the listener to process only one message(that maked it 5 as you have 5 consumers) every 5 minutes? if that is the case then you can simply set the <maxMessagesPerTask> to 1 and use TimerTaskExecutor as per the previous post.

[atanum]

Thanks a lot for your response. Really appreciate that.

OK, let me explain the requirements because I was not very clear earlier. We use WebLogic and we want WebLogic to primarily focus on the serving HTTP requests. We found however that it is wasting a lot of CPU cycles on listening for messages and processing them. We don't want this when the load high. Message can wait. Ideally, we want it to process the JMS messages only when the load is low.

Using DefaultMessageListenerContainer (DMLC), the coding becomes simple because I implemented the onMessage() of the messageListener. DMLC by default also automatically removes the message from Queue. So these are the advantages. On the other hand, I do not want the real time message handling that DMLC offers out of the box. I want DMLC to wake up periodically and consume messages from queue. We will improve our logic later on to figure out the low load condition using some algorithm. But for now periodically wake-up (say 5 mins) will be good enough.

In your opinion, therefore, what should be the best option ? Should we continue with DMLC and research how to use it with TimerTaskExecutor ? I am not sure how to go about it because I am looking for some examples. If you can show an example, that will be really appreciated.

Or, should I take a completely different approach by abandoning DMLC ? In that case, a timer will fire every 5 mins and on that event I will do synchronous receive using JmsTemplate class. I personally do not like that approach because it would mean more changes to existing codebase. Also, I will have to write more code in this alternative.

Is there any other alternative ?

Thanks a lot once again.

[chudak]

The other thing you can do rather than trying to throttle message consumption is to:

1) Buy another weblogic license (or maybe you already have one) and stand up another WL server instance that hosts the JMS server and has the MDP's installed. That way JMS message processing has NO effect on your ability to handle HTTP traffic.

2) Stand up a Jboss server that does (1) above (no licensing costs).

Your problem is not that you need to throttle your JMS consumption, it's that you need to scale horizontally.

[atanum]

Thanks a lot once again for your reply. A management decision was made so that the asynchronous receive portion would be extracted out of this app and be converted to a mini app. This will run on a separate WL managed server. Also using some Solaris 10 "domain" technique, a couple of processors will be dedicated to run this managed server.

Thanks a lot, once again for your suggestions