| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| ConnectionConsumer producing wrong backout counts? |
« View previous topic :: View next topic » |
| Author |
Message
|
| griffel |
 Posted: Thu Apr 28, 2005 6:04 am Post subject: ConnectionConsumer producing wrong backout counts? |
 |
|
Novice
Joined: 22 Mar 2005
Posts: 23
|
Our configuration:
WebSphere MQ 5.3 CSD9 for Windows (here 2000) as a Java JMS client to connect to a queue manager running as WebSphere MQ 5.3.1 on z/OS 1.6 via SSLed SVRCONN-channels.
Our problem:
Stopping an instance of IBM's ASF ConnectionConsumer implementation leaves poisoned messages in the queue it listens to. Poisoning is given by rather arbitrarily set backout-count numbers. The queue itself has BOTHRESH(1), a defined backout queue, and is HARDENBO.
The problem occurs very rarely. In each case, there seems to have been a MQGET running for quite a long time (minutes, up to hours due to errorneously processing in the code called by the consumers' listener "onMessage"). Most of the time, it works like designed.
Our question:
Can anyone tell about the secret when, i.e. under which exact circumstances, the consumer gets in trouble with backout-counting and misses to backout the currently processed message to the provided backout queue?
As always, any help is very much appreciated. |
|
| Back to top |
|
 |
| griffel |
| Posted: Thu Apr 28, 2005 10:32 am Post subject: |
|
|
Novice
Joined: 22 Mar 2005
Posts: 23
|
Some more details, since we now have built a standalone test
(former observations came from our production systems directly):
The test instantiates a ConnectionConsumer listening on a queue
configured as described above. The consumer has a SessionPool
with 20 sessions available for use.
Since a ConnectionConsumer.stop() will stop the SessionPool which,
in turn, will stop the Sessions, we included a delay of 10 seconds before
each Session.close() is actually called within our SessionPool-implementation. This is for giving the "onMessage"-activities running in parallel some chance to end up with their work in a normal way, even though the consumer is in stopping mode. (BTW, has anyone recommendations for what's the best design pattern to avoid duplicate message processing with a JMS ConnectionConsumer?)
Now, the test code puts a message into the queue. Then it calls stop() on the consumer. This results in still ("again") having the message in the
queue with its backout-counter set to 1. Everything fine up to this point.
Then the test code starts a new consumer listening on the queue again.
Now, things get wired: On correctly behaving systems the consumer
recognizes the backout-count already set to 1, compares it to the queue's
defined threshold, and correctly puts the message into the intended backout queue.
On broken systems, the message reappears in the queue with a backout
counter set to values like 3, 5, 27, 33 and the like.
We've run this test against all our MQ installations, here's the result:
- WebSphere MQ for Windows 530.9 (CSD9) on Windows 2000: OK
- WebSphere MQ for Solaris 530.9 (CSD9) on Solaris 9: OK
- WebSphere MQ for z/OS 531 on z/OS 1.4: FAILED
- WebSphere MQ for z/OS 531 on z/OS 1.6: FAILED
BUT: We have 9 Queue-Managers running distributed over 2 hosts and
4 LPARs. One of these QMs does its job OK! (this one runs under zOS 1.6,
but some of the others do as well).
I think this definitly is a bug inside MQ dependent on its system environment. From a programmers' and sysadmins' point of view
all MQ installations / configuration seems to be completely the same.
I don't know if there might be other stuff around on the hosts which
might interfere with MQ. My last hope for this is PTF UK01818 which we
haven't applied yet. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 28, 2005 11:20 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| (BTW, has anyone recommendations for what's the best design pattern to avoid duplicate message processing with a JMS ConnectionConsumer?) |
Should never happen. JMS Consumer is designed in such a way that if the message is being consumed there is no problem.
Now you may run into problems with poison messages. Assuming your queue is serviced by multiple consumers indiscriminately (first come first serve) what you may get is:
1st attemp consumer n -- rollback
2nd attempt consumer x -- rollback
3rd attempt consumer y -- rollback
and so on until the backout threshold is used and the app is doing something about it.
Enjoy  |
|
| Back to top |
|
|
| bower5932 |
| Posted: Thu Apr 28, 2005 1:19 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| Quote: |
| On broken systems, the message reappears in the queue with a backout counter set to values like 3, 5, 27, 33 and the like. |
When I've seen this, it is usually because a backout threshold is supplied but there is no backout queue. You can also get this if you have both the threshold and queue and nothing to actually move the message. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 28, 2005 7:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Also I would not use ConnectionConsumer.stop() to stop delivering the message.
To stop delivering the message use Connection.stop().
Then you can close the Consumer, close the Session and finally close the Connection....
Enjoy  |
|
| Back to top |
|
|
| griffel |
| Posted: Fri Apr 29, 2005 12:20 am Post subject: |
|
|
Novice
Joined: 22 Mar 2005
Posts: 23
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Apr 29, 2005 10:31 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
|
| Back to top |
|
|
| griffel |
| Posted: Fri Apr 29, 2005 8:37 pm Post subject: |
|
|
Novice
Joined: 22 Mar 2005
Posts: 23
|
Might be a bit too early today for me to grasp some clear thought, but:
I understood that you suggested to avoid further message delivery by calling Connection.stop() first (instead of ConnectionConsumer.stop()).
And that's exactly my original code sequence shown in the quoted mail thread. But thnx for giving me a chance to discuss this, anyway.
Live long and prosper. |
|
| 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
|
|
|
|
