| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Obtaining Mutiple MQ connections concurrently |
« View previous topic :: View next topic » |
| Author |
Message
|
| samird |
 Posted: Tue May 06, 2003 12:14 am Post subject: Obtaining Mutiple MQ connections concurrently |
 |
|
Novice
Joined: 10 Apr 2003
Posts: 11
Location: unspecified
|
I have a C program - am developing it using VC++ editor on windows 2000. The IBM MQ is also installed on my PC.
If my program does the following steps sequentially :
MQCONN
MQOPEN
MQGET
MQDISC
MQCLOSE
the program runs fine.
However if i create a pool of 2 connections and then call 2 child threads, by passing the respective connection handle, the MQGET fails with error code 2018
BY using a printf statement, i can see that the same connection handle is being obtained after both MQCONN calls.
Can the same program obtain more than one connection to the Q manger?
Does anybody know how to do it? |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Tue May 06, 2003 4:33 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
My question is why would you want more than one connection to one particular queue manager? All the Opens and Gets could be done under one connection handle.
You can connect to different qmgrs without any trouble. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue May 06, 2003 5:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Aside from Kevinf2349's comments about multiple connections to the same queue manager, you have to be very careful when trying to share an HCONN between threads.
It's not possible in older versions of MQSeries, and there are some restrictions when doing so in 5.3. In older versions you can only have one HCONN per thread. This is part of why you're seeing the same HCONN returned.
It should work, however, if you make your pool create a separate thread for each HCONN. |
|
| Back to top |
|
|
| samird |
| Posted: Tue May 06, 2003 10:24 pm Post subject: |
|
|
Novice
Joined: 10 Apr 2003
Posts: 11
Location: unspecified
|
My concern is more from a transaction management point of view. Unless i create multiple connections - one for each thread, how i can maintain the state - i.e deciding when to commit/when to rollback .
Some people have said that because MQGET is pretty fast, i should do the get part serially and then create multiple processes for processing the messages. I have doubts about this approach because I can this way not maintain a transaction per message.
any suggestions? |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed May 07, 2003 5:20 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
When trying to use threads you have to bear in mind that your app is utilizing the feature of multithreading and processess, but MQ isnt. Meaning. MQ process any message serially ONLY. And hence in this perspective i dont think there is of much consequence if you have 10 threads trying to do a get on the same queue or 1 thread doing the same. Nor is 10 apps doing get on the same queue any different in this scenario.
All of the above come to halt at one point and which is. MQ processes messages serially.
So, my suggestion would be to have multiple instances of the same app running concurrently rather than doing threading. Because as is, threading has its own concerns and takes quite a lot of time to actually get implemented. And since in your case, there seems no real advantage, why take the hassle.
As for counting the number of transactions. If you have only one app doing gets from this one queue, you could implement a transaction counter or something to get the count. At the end of the run, you can count the counters from all the instances of this app that you were running.
I am afraid, at this point i cant think of any other alternatives.
HOpe this helps.
Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| samird |
| Posted: Wed May 07, 2003 8:01 pm Post subject: |
|
|
Novice
Joined: 10 Apr 2003
Posts: 11
Location: unspecified
|
Thanks Kumar.
I need a few clarifications, though.
1) You said that because MQ processes messages serially, there is no point in 10 threads trying to do a GET because at the end, it will happen serially ONLY. You also said that 10 threads trying to read is the same as 10 applications doing GET on the same Queue.
2) However later in your reply u said its better to have multiple instances of the same application run concurrently. What is the difference betweeen the 10 instances of the same program, and 10 threads within the same program. Is it that if I've 10 instances, it will mean 10 connections and 10 sets of MQCONN, MQOPEN, MQGET and so on?. Can't I have a program with 10 running threads where I get each thread to do a connection, open and read.
3) For maintaining the state of a message(i.e. deciding whether to leave the message on the Q or remove it after processing has been done), what is difference between BROWSE with LOCK and MQGET. I know of one: using MQGET with syncpoint, I can maintain a RBACK count which tells me the number of times a message has failed.
Is there any other difference - either in terms of the time it takes to execute BROWSE vis-a-vis MQGET (with syncpoint) or in terms of available features/limitations.
Last edited by samird on Wed May 07, 2003 10:08 pm; edited 1 time in total |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu May 08, 2003 4:48 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Here are your clarifications....
1) Yes i did say that.
2) As i mentioned earlier there is no difference if you have one process with 10 threads or 10 processess with 1 thread each. Reason being, your app may be threaded, but MQ isnt. Hence MQ would always process messages one after the other and the rest of the threads would be just waiting. Doing a waited get most likely. The only reason i suggested you to have 1 app that is non-threaded and run it with multiple instances is because this way you would avoid the hassle of writing Threaded code. I know its not an easy job to do so. The time you spend to carefully get it right, you might as well fix no less than 10 problems... :)(Just a statement, dont take it literally...). And yes, that would mean 10 sets of mqconns etc... The only difference in processing by MQ when you have more than 1 app doing a waited get on a queue, is that it is faster as opposed to having just 1 app do this.
3) Browse with lock and MQget with syncpoint. Hmmmmm.... Locking means you would not allow any other app to access the queue until the lock is released which again leads us to having only 1 app that is non-threaded. So, i doubt that is what you are looking for. As for get with syncpoint and backing out. It allows you to have more than 1 app to process messages off the same queue. But again, it is not cheap. If you processed say 10000 messages(just a figure), in a transaction and want to back out. Imagine the workload you would thrust upon MQ.
The whole point of this discussion is to show that there is NO advantage what so ever having threaded app do a get off the same queue from MQ's performance perspective.
Hope this helps.
Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
