| Author |
Message
|
| david.hargreaves |
 Posted: Tue Nov 07, 2006 11:46 am Post subject: Need info on "fairness" attribute |
 |
|
Newbie
Joined: 07 Nov 2006
Posts: 3
Location: San Rafael, CA
|
During some MQ research a few months ago, I was sure I had come across references to a "fairness" attribute that could be turned on that would cause the MQ Manager to give a message to the process whose MQGET had been waiting the longest when there were multiple non-browse GETs active.
However, I can no longer find any reference to such a beast. My problem lies in a dataflow testing tool that is attempting to browse a queue and get copies of all messages passing through it before the draining application can remove them from the queue.
In all cases where we've applied the tool, we've been successful in consistently getting copies of all messages except with one application in particular. Something in the way this particular application drains the queue is causing our tool to fail to get 1 or 2 messages in a stream of 50, even though we've engineered the tool to be able to use N threads each performing independent MQGETs (running a sufficient number of threads increased our "hit" ratio from 50% to the 96-98% described above).
I'm trying to get my ducks in a row before approaching the vendor of this application to see if there are any "tweaks" they could make to the application to improve it's "test-ability". My working theory so far is that the app is setting the fairness attribute to true, and this is affecting our browse GETs' ability to get copies of every message, but without documentation to back me up I'm hesitant to advance the theory...
Any thoughts, suggestions, pointers, hints, etc., would be greatly appreciated! Sorry for the verbose post! |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Nov 07, 2006 12:11 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There's nothing you can set on a particular GET to ensure that it will get a message before another GET that is eligible to get the same message.
That is if you have two GETs that identically match a particular message, there isn't anything you can set to control which GET will receive the message.
As far as I know.
In general, you should use an API exit to monitor messages in the way you are trying to use BROWSE to do it.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Nov 07, 2006 1:08 pm Post subject: Re: Need info on "fairness" attribute |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| david.hargreaves wrote: |
| give a message to the process whose MQGET had been waiting the longest when there were multiple non-browse GETs active. |
If all the MQGETs are running in copies of the same app, I don't see why it's desirable to pay any attention to which copy of the app gets the message.
If, on the other hand, the apps are not all identical copies, then I'd suggest using more than one queue so that each queue can be serviced only by identical apps. |
|
| Back to top |
|
|
| david.hargreaves |
| Posted: Tue Nov 07, 2006 1:17 pm Post subject: |
|
|
Newbie
Joined: 07 Nov 2006
Posts: 3
Location: San Rafael, CA
|
You are right relative to good enterprise application design...however, our tool is attempting to be an "observer" of the data flow, and is in essence competing with the "legitimate" application(s) designated to process those queues.
We are considerate competitors in that we only want a copy of each message  |
|
| Back to top |
|
|
| david.hargreaves |
| Posted: Tue Nov 07, 2006 1:22 pm Post subject: Regarding API Exit |
|
|
Newbie
Joined: 07 Nov 2006
Posts: 3
Location: San Rafael, CA
|
| In response to jefflowrey: An API exit would require installing code of some sort on the MQ host, yes? We're striving to maintain an "agent-less" status with the tool, but perhaps something of this nature could provide a one-off solution for this case. Thanks for the thought... |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Nov 07, 2006 1:27 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| david.hargreaves wrote: |
| we only want a copy of each message |
Fair enough. So I guess an MQPUT API exit is a good idea. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Nov 07, 2006 1:35 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The API crossing exit is pretty easy to configure and is the correct approach to use.
I believe that in general MQ will assign messages to waiting MQGETs in the order that the MQGETs were issued. However once a MQGET is given a message that thread would go the back of the "queue" for the next MQGET.
However unless it says this in the manual you should not reply upon it - that's why IBM makes the effort (unlike some vendors I could name) to provide documented exit points. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Nov 07, 2006 2:40 pm Post subject: Re: Regarding API Exit |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| david.hargreaves wrote: |
| In response to jefflowrey: An API exit would require installing code of some sort on the MQ host, yes? We're striving to maintain an "agent-less" status with the tool, but perhaps something of this nature could provide a one-off solution for this case. Thanks for the thought... |
There are limits to an agentless approach.
One big limit is in monitoring message data. You simply can't do it without an exit of some kind or another, or without having an interceptor program that sits between every application and copies messages.
Another big limit is starting and stopping programs. You can't do this over the MQ API without an agent process of some kind.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Nov 07, 2006 3:05 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| zpat wrote: |
| I believe that in general MQ will assign messages to waiting MQGETs in the order that the MQGETs were issued. However once a MQGET is given a message that thread would go the back of the "queue" for the next MQGET. |
It would not be wise to rely on this. There is potentially more value in doing the opposite: ie. scheduling the most recent MQGET, since this is least likely to be paged out.
| Quote: |
| However unless it says this in the manual you should not reply upon it |
Nor rely on it  sorry. |
|
| Back to top |
|
|
|
|
