| Author |
Message
|
| angka |
 Posted: Mon Oct 29, 2007 1:58 am Post subject: Many or One Connection to qmgr? |
 |
|
Chevalier
Joined: 20 Sep 2005
Posts: 406
|
Hi,
I wrote a class with MQ API using c#.net. all the connect, open put get is in the class. I need to listen to 3 local queues. I decided to create a thread for listening to each queue. so do I have 3 queue manager connection or do I have 1? Any performance or resource issue?
Thank you. |
|
| Back to top |
|
 |
| Gaya3 |
| Posted: Mon Oct 29, 2007 2:03 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
Hi
Opening 3 diff connections to 1 Qmgr is not a good idea.
and holding it for long time is also not good.
Regards
Gayathri
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 29, 2007 2:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You need one connection for each simultaneous GET with wait... Each connection can only process one MQ API call at a time.
It's always a good idea to give an application all of the resources that it's business requirements call for.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| angka |
| Posted: Mon Oct 29, 2007 3:29 am Post subject: |
|
|
Chevalier
Joined: 20 Sep 2005
Posts: 406
|
Hi,
So put it simple, get and wait from one queue with one queue manager connection?
But why Gaya3 think otherwise? |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Mon Oct 29, 2007 3:43 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
| angka wrote: |
Hi,
So put it simple, get and wait from one queue with one queue manager connection?
But why Gaya3 think otherwise? |
1. How long you are going to wait thats the question here?
Wait for some interval of time thats good (decide how long), but you should not hold the queue for long time (This is not a good practice)
Regards
Gayathri
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| angka |
| Posted: Mon Oct 29, 2007 3:46 am Post subject: |
|
|
Chevalier
Joined: 20 Sep 2005
Posts: 406
|
Hi,
I intend to wait at the queue infinitely. But what the reason for not waiting infinitely? resource? I tried before and wait at the queue infinitely and left it over 2 days, the ram usage is the same.
Thanks |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Mon Oct 29, 2007 4:03 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi angka,
| angka wrote: |
| I intend to wait at the queue infinitely. But what the reason for not waiting infinitely? resource? I tried before and wait at the queue infinitely and left it over 2 days, the ram usage is the same. |
Instead trigger the queue to run the app...sounds more logical...
Regards. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 29, 2007 4:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It's better to do shorter waits when using a client connection.
It's better to use triggering when you expect long periods of time between message volume.
There's nothing inherently wrong with specifying a long wait time, as long as you specify FAIL_IF_QUIESCING.
You should design your program to meet the requirements, and include expected patterns of message traffic in those (if you know).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Oct 29, 2007 4:18 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Gaya3 wrote: |
| Wait for some interval of time thats good (decide how long), but you should not hold the queue for long time (This is not a good practice) |
Hi, what is the disadvantage with waiting in get-with-wait for a long time? Using get-with-wait is a good way to put the HConn in a zero-CPU state waiting for something to happen. |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Oct 29, 2007 4:20 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| elvis_gn wrote: |
| Instead trigger the queue to run the app...sounds more logical... |
Two points here:
o Triggering is a lot to learn and get working if all you want is a get-with-wait
o With triggering an app (this time the trigger monitor) still has to sit in get-with-wait |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Mon Oct 29, 2007 10:03 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 29, 2007 10:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Sure, but only if it's not sitting in a GET with WAIT.... Each connection can only process a single MQ API call at a time.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Mon Oct 29, 2007 10:58 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
I see. So all threads dependent on the same HCONN are effectively single threaded.
I'm sure this is out there somewhere...
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Oct 29, 2007 1:07 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| JosephGramig wrote: |
| I see. So all threads dependent on the same HCONN are effectively single threaded. |
Doesn't quite make sense to me when phrased this way. I would phrase it: when you have an HConn in use on one thread, the next thread who wants to use it must wait.
Behind the scenes, each HConn is served by a single thread in the queue manager. That means only one application thread can be expect to be served at any one time by that HConn. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 29, 2007 5:00 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| JosephGramig wrote: |
| I see. So all threads dependent on the same HCONN are effectively single threaded. |
No.
It means you need one HCONN for each GET/WAIT... and one HCONN for everything else.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
