| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| JMS message selector and z/OS CPU load for TCP stack |
« View previous topic :: View next topic » |
| Author |
Message
|
| griffel |
 Posted: Tue Oct 04, 2005 5:18 am Post subject: JMS message selector and z/OS CPU load for TCP stack |
 |
|
Novice
Joined: 22 Mar 2005
Posts: 23
|
Just because I'm kind of frustated - to avoid "displeased" - I like to grasp some opinions here - if anyone has some on the following issue:
Some time ago we believed using "industry standards" (at least at the interface level) is a nice idea. Thus, we decided to develop our MQ dependent Java applications based on JMS. The JMS feature "message selector" seemed easy to operate and allows simple and straightforward design - we used it, more specifically, IBM's implementation.
The problem: When messages accumulate on a queue for there is no matching selector at any of the active consumers, CPU load on the serving z/OS host rises terribly high. The reason seems to be that the Java client gets each message (that's putting it on the network wire), looks at it to possibly match the selector, and forgets about is since it doesn't match. This results in high network traffic and respective CPU cycles for the TCP stack / CHINIT. Even worse, when the client have browsed through all the accumulated messages it seems to start from scratch - scanning the queue again and again.
Questions:
How can one implement such a silly thing? Why is the "matching part" not implemented on the server (host) side, for example as a registrable mechanism at the MCA. Why not let that channel agent (or some other entity on the host) answer only get/browse requests when "new" messages arrive on the queue, avoiding this endless "scan loop"? I know any of such implementation might imply subtle difficulties and semantics, but with the current behavior message selectors seem to be useless, at least with IBM's implementation.
Any comments? (please not: "do not let them accumulate" - of couse, I talk about errorneous situations ...) |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Oct 04, 2005 5:30 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You have to be very carefull implementing JMS selectors.
a) you need really one queue per selection
b) you need a generic process that will distribute the messages according to the selection to the affore mentioned queues and remember to have one "junk" queue. Last and least if the response has attributes that are not needed, rather than leave the message on the queue, consume it.
c) if used in patterns like request response only use selector dealing with messageid or correlationid. With the MF have the queue indexed accordingly. Only use the native type selector MessageID="ID:xxxxxxxx" it is way faster and more efficient than anything else you may come up with and avoid reading every message on the queue.
d) With high volume of request response have each requestor create its own dynamic queue for the response. Send the reply to the JMSReplyTo destination...
And please remember MQ is a messaging system and not a DB. And it won't behave as such either...
Enjoy  |
|
| Back to top |
|
|
| griffel |
| Posted: Tue Oct 04, 2005 6:16 am Post subject: |
|
|
Novice
Joined: 22 Mar 2005
Posts: 23
|
Thanks for the bit of balm for my suffering soul.
At least, your suggestions approve our other design decisions (those aside from using JMS ...).
Nonetheless I'm afraid, delivering non-matching messages to a junk queue is unaesthetic when it comes to the "real" receivers going down (planned or unplanned). |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 04, 2005 1:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well if it went to the "junk queue" in the first place it is because you could not find a receiver / category to deliver it to.
Otherwise your little distributor would have redirected it to some specific queue from which the app would pick it up whenever it is running....
Now if it is something like registration(pub/sub) and / or request/response as long as the subscription is not durable you could have your own specific dynamic delivery queue. So if you get delivered something that you did not really want you do not want to clot your queue with it but just consume it...
Enjoy |
|
| 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
|
|
|
|
