| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| mqConnect and mqOpen for multithread Delphi |
« View previous topic :: View next topic » |
| Author |
Message
|
| sebastia |
 Posted: Mon Nov 07, 2011 5:37 am Post subject: mqConnect and mqOpen for multithread Delphi |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Good morning everybody.
We are trying to write a Delphi program to be a MQ message "consumer".
And to make it scalable, it shall be multithreaded.
If the usual sequence of calls is
1) mqConnect(qmgr)
2) mqOpen(queue)
3) mqGet(message)
4) mqClose(queue)
5) mqDisconnect(qmgr)
...
is it possible to do (1) and (2) only once,
this is in the "main" body, before all threads are created,
and to pass the handle to the qmgr (hConn)
and the handle to the queue (hObj)
to all the threads ?
In this way, the thread code loop shall be
mySimple_MQconsumer:
init_thread() ;
while ( not end_of_job )
msg = mqGet(hConn, hObj, cc, rc) ;
end; // while
end_thread() ;
Or every thread must do its own "mqOpen" to get its own handle to the queue object ? (hObj can not be shared between 2 threads)
Or, in the worst case, every thread must do its own "mqConnect" to get its own handle to the queue manager ? (hConn can not be shared between threads)
The "complete" thread code shall be similar to this :
myComplete_MQconsumer:
init_thread() ;
hConn := mqConnect(qmgrName, cc, rc) ;
hObj := mqOpen(hConn, queueName, cc, rc) ;
while ( not end_of_job )
msg = mqGet(hConn, hObj, cc, rc) ;
end; // while
mqClose(hConn, hObj, cc, rc) ;
hObj := 0 ;
mqDisconnect(hConn, cc, rc) ;
hConn := 0 ;
end_thread() ;
Thanks. Sebastian. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Nov 07, 2011 10:16 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You DO NOT want to do it this way.
Obviously apart from the thread blocking calls and the problems with thread sharing, I guess your aim is throughput and scalability...
Each thread should be using its own qmgr handle and connection handle...
You should as well look into pooling your connections.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Nov 07, 2011 10:43 pm Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Hi, mr Saper.
When you say "you do not want to do it this way",
I guess you mean you are telling me to abandon the first or short or "simple" consumer. (xcuse my english : it has "spanish" level)
The "complete" consumer is what you sugest ... OK.
But I am pretty sure that I can do only one mqConnect and pass the resulting handle to all the threads, which would access the same queue with diferent mqOpen handles without a problem.
Guess I can improve my question into
"what does a mqConnect() provide to a thread" ?
plus
"what does a mqOpen() provide to a thread" ?
The obvious answer is "it provides a handle", but ...
... what does a handle provide to a thread ?
*) access rights ?
*) access to the qmgr/queue semaphores ?
*) ???
I will take a look at the books ....
Thread blocking is directly the reason we use threads : if we use a single main loop, the mqReceive() operation stops it until a msg is received or a timeout.
Thread sharing : no problem with this - some semaphores handle the shared variables and queues/pipes.
"Pooling the connections" : what do you mean by that ?
To have few connections (to a qmgr + to a queue) established at the beginning of the day, and to use them on request ?
I agree : it is a good idea, to reduce the mqConnect() and mqOpen() time impact ...
Thanks. Sebastian. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Nov 08, 2011 2:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So you can use a single connection and a single open handle.
However, you can only send a single MQ API call through that connection at a time.
So if you issue an MQGet on one thread, with a wait, then the MQGet on another thread will not run until the first one is complete.
In general, you should plan on n+1 connections, where n==number of simultaneous GETs you wish to issue. The +1 is to issue all of the PUTs you might want.
You certainly can create all of these connections and issue the needed opens, in the main thread, and then pass a handle to the worker thread. You can even implement a connection pool of some kind such that each worker thread does not have a dedicated connection object, it just gets one from the available set each time it needs one. |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue Nov 08, 2011 2:53 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Thanks for your answer, Jeff.
So, what you are saying is that a mqConnect() handle provides access for concurrent API call(s) ?
Are you sure it is not enough to have a mqConnect() handle to do concurrent calls to mqGet() ?
Cheers. Sebastian. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Nov 08, 2011 2:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MQGET is a synchronous call - as is MQPUT. This means that the connection that the GET is issued across is locked until the call completes, and the same with PUT.
But PUT finishes much quicker than GET, especially if GET is waiting for a period of time until a message appears.
If you want to have multiple threads waiting for new messages at the same time, you need each thread to have it's own MQConnection and MQOpen. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Tue Nov 08, 2011 3:33 am Post subject: Re: mqConnect and mqOpen for multithread Delphi |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
The connection handle returned from MQCONN is valid only within the thread that issued the call. To share a connection between multiple threads, use MQCONNX.
When sharing a connection between multiple threads, WMQ still only allows one active MQI call per connection. If the connection is currently in use by an MQI call on one thread, then any other MQI calls by other threads will either wait until the current MQI call completes, or fail immediately, depending on the given MQCNO options.
Concurrent MQI calls require multiple connections. |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue Nov 08, 2011 3:45 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Thanks a lot for your answer, mr rekarm ... and Jeff !
I shall request as many mqConnect handles as threads I plan to have !
Cheers ! Sebastian.
Just in search of perfection ... I was reading "Application Programming" and here is what it says ...
"Within WebSphere MQ for iSeries, WebSphere MQ on UNIX systems, and WebSphere MQ for Windows, the scope of an MQCONN or MQCONNX call is usually the thread that issued it. That is, the connection handle returned from the call is valid only within the thread that issued the call. Only one call can be made at any one time using the handle. If it is used from a different thread, it is rejected as invalid. If you have multiple threads in your application and each wants to use WebSphere MQ calls, each one must issue MQCONN or MQCONNX."
"On WebSphere MQ platforms other than WebSphere MQ for z/OS, a connection made with MQCONN is available only to the thread that made the connection. Options on the MQCONNX call allow you to create a connection that can be shared by all the threads in a process."
Thanks for the "push", coleagues ! |
|
| 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
|
|
|
|
