| Author |
Message
|
| HenriqueS |
 Posted: Wed Jan 30, 2008 10:30 am Post subject: Minimizing MQCONN and MQOPEN calls using UserExitArea |
 |
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Fellas,
I noticed my message exit is not releasing resources after it is invoked. Several connections with queues are mantained (a few MQPUTs are made inside the exit), what possibly degrades performance and pushes the limit on the 'max MQI connections' setting. Sure, I can solve this just calling MQDISC and MQCLOSE in the end of the exit....
BUT...since this exit will be invoked a few thousand times per minute and will be activated for each receiver channel (a few hundred receiver channels in our installation), I do not feel confortable on just opening and closing queues on every incoming message that flows thru the channels.
I though on maintaining the the connection handler between the exit and my MQ server as far as the channel is up. Or is this too much confusing code and maybe I shall sticking connecting and opening the file for every message?
See some pseudo code:
| Code: |
MyExit(...){
switch(ExitReason){
case MQXR_INIT:
if(exituserarea == 0){ /* cleared user exit area */
mqcon(handle,...);
mqopen(handle,...);
exituserarea = handle;
}else{
/* rare situation? user exit area not clear, give up */
ExitResponse = MQXCC_SUPPRESS_EXIT;
}
case MQXR_MSG:
/* first run dll always has exituser area this zeroed */
if(exituserarea !=0){ /* there is a connec handle kept here... */
// do not connect or open queue, we have a handle
handle = exituserarea
mqput(handle, ...)
}else{ //there is no handle available
mqconn(handle,...)
mqopen(handle,...)
exituserarea = handle
mqput(handle,...)
}
case MQXR_TERM:
if(exituserarea!=0){ // there is a handle, therefore a connection...
mqclose(handle, ...)
mqdisc (handle,...)
}
}
}
|
_________________
HenriqueS
Certified Websphere MQ 6.0 System Administrator |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Jan 30, 2008 3:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I'm confused. Why would you need an extra connection to the queue manager, you already have one!?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Wed Jan 30, 2008 3:49 pm Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Which extra connection? The code above runs as an Exit and afaik I need to get a new connection if I want to deal with any qmgr object.
Are you saying that I don´t need to do the mqconn() calls above?
| fjb_saper wrote: |
| I'm confused. Why would you need an extra connection to the queue manager, you already have one!? |
_________________
HenriqueS
Certified Websphere MQ 6.0 System Administrator |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jan 30, 2008 4:00 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Roger will give you better advice than I will ever be able to on user exits. It just seems strange to me that you would need to create a connection to a qmgr you are running in... and thus connected to by default. I would expect you only to have to do a put1 to the additional queue.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Jan 30, 2008 10:06 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The MQCONN is necessary to get the connection handle that the channel is using. The call returns MQRC_ALREADY_CONNECTED, but it also returns the Hcon to use in subsequent MQI calls.
The Hobj returned from the MQOPEN call should be saved in the exit user area and used next time the exit is called.
Close the objects by calling MQCLOSE when the exit is called for MQXR_TERM.
Note that issuing MQDISC or MQCMIT inside an exit is a bad idea, since the exit shares the Hcon and UoW of the MCA.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Fri Feb 01, 2008 10:02 am Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Thanks for the feedback, I made the changes according to Nigelg tips. I noticed now that less queue handlers are kept open. Pretty much I used the same skeleton code as above, but with a few improvements (there is some useless code there).
The basic idea is to save the Hobj got from the 1st time the queue is open into the Exituser area and check it subsequently to reuse it.
_________________
HenriqueS
Certified Websphere MQ 6.0 System Administrator |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sat Feb 02, 2008 12:12 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Be careful of your pointers because each time your exit is invoked they won't have the values you think they have.
Think parallelism. What happens when your exit is invoked multiple times at the same time?
This is where developers get in trouble with exits. They do single threaded testing on their PC or test server but when they put it into a multi-user system, it crashes.
By the way, what are you trying to create? i.e. What problem do you have that you are creating a solution for?
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Wed Feb 06, 2008 7:42 am Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
I am saving some COD/COA message values into a local queue when they are returned to the requester side.
_________________
HenriqueS
Certified Websphere MQ 6.0 System Administrator |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Feb 06, 2008 6:46 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| HenriqueS wrote: |
| I am saving some COD/COA message values into a local queue when they are returned to the requester side. |
Wow, thanks the hard way to retrieve and copy a COA or COD message to another queue. This code should be in the program that is sending the original message that has those options set.
Or build a "front-end" application to intercept COA/COD messages and allow / pass reply messages to the original requester.
I've built many applications that enable SLA functionality using COA / COD messaging with back-ending to a database. I've never thought to design it using an exit nor would I want too.
You should take 2 steps back and re-analyze if your approach is the best solution for the problem.
That's my 2 cents.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
