| Author |
Message
|
| rconn2 |
 Posted: Fri Mar 07, 2008 8:32 am Post subject: multiple or single MessageListeners on destination |
 |
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
Background:
I have a java app that sets a JMS MessageListener on a queue. In the java app, I use a lockfile technique to prevent multiple instances from running in the background. This is so there will only be one Listener for a queue.
However, in testing, the lockfile technique failed, and Listeners in two different app instances were started on the same queue.
Problem
The application log file seemed to show that both Listeners' OnMessage methods were sometimes getting called for the _same_ message. This caused the message handling code to fail.
Question: when multiple MessageListeners are set on a queue, does a message get passed to only one of the Listener's OnMessage methods? Or, as seems to be the case, can more than one Listener's OnMessage get called for the _same_ message?
Note that these are Listeners being run from different java application invocations -- not the same session.
Is there a way for a message to be assigned to only a single Listener (when there are multiple Listeners that aren't part of the same session)?
Or, is there a way to check if a queue already has an assigned Listener? This is what I'm trying to do w/ the java lockfile technique -- find out if there's another instance running... I'll work on this some more, but it'd be great if there was a way to just i.e. block a queue from having another Listener assigned or check for another Listener. |
|
| Back to top |
|
 |
| belchman |
| Posted: Fri Mar 07, 2008 9:00 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
To only have one listener on a particular queue, why dont you just have the queue set to OPEN INPUT EXCLUSIVE on you open?
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Mar 07, 2008 3:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
The application log file seemed to show that both Listeners' OnMessage methods were sometimes getting called for the _same_ message. This caused the message handling code to fail.
|
This seems very strange. Can you prove this assertion? If yes you should open a PMR.
Looks to me more like the message was picked up by one instance, had a problem , was rolled back and picked up by a different instance....
This does not mean that the message was processed successfully twice or that this caused the message handling to fail. I would say this happened BECAUSE the message could not be processed successfully.
LEARN: MQ seldom makes error. Look at your application program first!
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rconn2 |
| Posted: Sat Mar 08, 2008 6:31 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
ftb_saper - you're entirely correct and my assertion was wrong. There was a subtle app error. I tested more and could not find a msg ID being picked up by more than a single Listener instance.
belchman - thanks, I should have thought of that. Both Exclusive and NOSHARE prevented, in my testing, more than a single Listener to be set on a given queue.
So, I'll fix up my java lockfile code (using java.nio channels) to only have a single instance running; but even if more than one runs, it shouldn't cause a problem since messages are atomically assigned to a single Listener instance. And, I also have the option of setting the queue property to NOSHARE or Exclusive. Thanks for your help! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Mar 08, 2008 6:59 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm confused about why you're trying to intentionally design your app to be unscalable.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rconn2 |
| Posted: Sun Mar 09, 2008 6:53 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
The app consists of many servers making a client connection to their assigned queue manager server for getting messages from their own assigned (i.e. inbox) queues.
Each client server will have a listener listening to their assigned queue. Why not have multiple listeners? The messages will be large and infrequent, and not typically simultaneous.
It'll be important that these message listeners are kept running on each client server. So, we'll run the script that starts the java app in the background as part of a server start or somesuch. It'd also be good to be able to run that script for extra measure on occassion, and if a listener is already running, not start another one (and another and another etc.). This would be the purpose of the java.nio file channel lock technique, or mq exclusive or noshare. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sun Mar 09, 2008 7:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If the messages are not simultaneous, it doesn't matter how many listeners you have. Even if the messages are occasionally simultaneous... why does it cause a problem if two listeners process them simultaneously?
If the messages are infrequent, you should consider a trigger instead of a listener.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rconn2 |
| Posted: Sun Mar 09, 2008 10:26 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
It wouldn't cause a problem if two listeners simultaneously processed messages. It would be a waste of resources to have more than a single listener running.
These are file messages, that should be < 25mb, but could be up to maxmsgl of 100mb. The java jms listener app needs extra heap space to handle these size messages. So, running multiple such apps is not only unecessary but seemingly wasteful (I'm supposing). The servers these listeners will be running on, have other dedicated purposes and so the footprint of the listeners should be small.
As for a trigger... these servers are making client connections to a queue manager on a different server. There may be dozens of such client servers each listening to it's own dedicated "inbox" queue. I previously considered a client trigger (in a previous thread), but there'd need to be an initiation queue for each "inbox" queue -- doubling the number of queues. And the client trigger wouldn't provide any more functionality than the Listener app (which automatically saves the message as a file based on certain jms properties, and then calls an OS script during the OnMessage call). |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Mar 09, 2008 12:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Remember a few things as you go with a client design
- As you attach a MessageListener do not forget to use and ExceptionListener,
as there is nothing else to tell you your connection dropped.
- Make sure your QCF or CF has the property fail if quiesce set.
This is to allow for a qmgr shutdown while your app is running.
It would serve you well to have some retry logic
- Retry logic needs to be thought through, something like:
1st 5 mins every min
from 5 to 10 mins every 2 mins
from 10 to 20 mins every 5 mins
from 20 min to 60 mins every 10 mins
beyond 60 mins every hour...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rconn2 |
| Posted: Tue Mar 11, 2008 12:23 pm Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
| fjb_saper - thanks for the design suggestions... I'm going through them. |
|
| Back to top |
|
|
|
|
