| Author |
Message
|
| BBM |
 Posted: Mon Feb 15, 2010 7:18 pm Post subject: MDB Listener Internal Behaviour |
 |
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi,
I am quite new to WPS and have looked around for documentation on the following, but have found scant detail.
I'm trying to understand how the MDB listener actually detects the presence of a message on and MQ queue.
From what I can find it seems that the MDB is performing a GET with WAIT with an unlimited timeout interval.
As I understand it several MDB listeners can be monitoring the same queue using multiple sessions. If this is the case and I am correct in my assumption that the MDB is using a GET with WAIT then who would receive the message first? Would it consumed by the first MDB listener to connect to the queue or is it random?
Any help as always gratefully received.
Thanks
BBM |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Feb 15, 2010 7:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Random. As I discovered on this forum recently. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 15, 2010 7:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
My understanding is that with the MDB you have following behavior
- One monitoring thread that polls the queue and creates a browser
- x processing threads
- each processing thread gets a message from the browser and does a get by on the message passing it to the onMessage method of the MDB
Polling interval and number of processing threads are configurable on either the qcf or the MDB.
Hope it helps some 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| BBM |
| Posted: Mon Feb 15, 2010 8:55 pm Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Brilliant, thanks for the quick and informative replies!
We have WPS set up to use the MQ client, am I right in thinking it would open a separate client channel connection to the QM for every MDB session?
So potentially, number of MQ channels used would = total number of MDB sessions + one additional channel for monitoring thread? Or does the monitoring thread share an MQ connection with the first MDB session?
I guess I should go away and test this...
Thanks
BBM |
|
| Back to top |
|
|
| BBM |
| Posted: Thu Feb 18, 2010 7:07 pm Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi again!,
I've spent the last few days trying to produce meaningful tests to determine exactly what effect tweaking the various parameters for sessions, connections etc. will have on performance.
I've found that when using WID on my workstation, for some reason svrconn channels into my MQ 7.01 queue manager seem to be capped at 5 channels. This doesn't seem to change whichever settings or test I carry out. When I do the same test on the full product I get 50+ svrconn channels.
I've read the JMS topologies guide from IBM - unfortunately a lot of the links to further readin are now dead.
If anyone knows of any documentation that will enlighten me I would be very grateful.
Many thanks
BBM |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 18, 2010 9:25 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
As you have seen, on your development station, you may have limitations against the full product.
I would suggest you construct and deploy to the full product / performance environment for your testing. Also remember to tweek your MQ channels stanza to make sure you won't be running out of connections.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| BBM |
| Posted: Mon Mar 01, 2010 3:11 pm Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Thanks for the advice.
I'm still struggling to be honest to correlate SVRCONN channels with connection pool settings. I've deployed to one of our test environments and have been tweaking various settings but cannot seem to make sense of the results.
I've noticed for example that we have many SVRCONN channels held open for over 24 hours with no message being passed during that time, does WAS hold these connections indefinitely? The channel status is RUNNING.
I would *love* to find the definitive document on how the WAS/JMS components interact with MQ in terms of resource usage - if anyone knows of such a doc please let me know!
I guess the next step is to open a PMR, I've read a couple of IBM articles in the developerworks website that seem to contradict each other... so I am mucho confused... |
|
| Back to top |
|
|
| SAFraser |
| Posted: Tue Mar 02, 2010 12:45 pm Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
| This is a topic of great interest to me. Any additional information you acquire and wish to share will be greatly appreciated. Thanks so much! |
|
| Back to top |
|
|
| squidward |
| Posted: Thu Aug 26, 2010 6:51 am Post subject: |
|
|
Novice
Joined: 27 Mar 2009
Posts: 10
|
| Quote: |
1. One monitoring thread that polls the queue and creates a browser
2. x processing threads
3. each processing thread gets a message from the browser and does a get by on the message passing it to the onMessage method of the MDB
|
Is this kind of behavior described in any document anywhere? I believe this is accurate, but it would be nice to have an official description. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 26, 2010 7:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
| squidward wrote: |
| fjb_saper wrote: |
1. One monitoring thread that polls the queue and creates a browser
2. x processing threads
3. each processing thread gets a message from the browser and does a get by on the message passing it to the onMessage method of the MDB
|
Is this kind of behavior described in any document anywhere? I believe this is accurate, but it would be nice to have an official description. |
I don't believe I ever saw it described anywere. This is more from observation.
However you have to take into account that this behavior will be affected by the new V7 sharing conversation attribute of channels. I would suggest that you turn this attribute off for channels being used by MDBs.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
