| Author |
Message
|
| EricL |
 Posted: Tue Mar 21, 2017 4:27 pm Post subject: Msg in Topic Subscription Queue Not Removed after Process |
 |
|
Centurion
Joined: 10 Oct 2014
Posts: 102
|
Hi there,
Noticed a weird thing happened:
1. An application is listening to a topic through subscription queue
2. Normally when a new message come in (come to subscription queue), the message would be processed by application and the message would be moved out of the subscription queue
3. But these days we noticed that even after application processed the message, the message still stuck in subscription queue, so the messages are piling up there.
Strangely, looks like new message still able to come in and the application still able to process new messages, but the subscription queue depth is keep on increasing.
Any advice is welcome.
Thanks
EricL |
|
| Back to top |
|
 |
| hughson |
| Posted: Tue Mar 21, 2017 5:52 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
If the application has processed the message does that imply it does a browse to start with and then later goes back to destructively get the message? Is it possible that the latter step didn't get run?
Also worth checking that the messages are no pt uncommitted? DIS QS UNCOM
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| EricL |
| Posted: Wed Mar 22, 2017 9:56 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2014
Posts: 102
|
Thanks Hughson,
DIS QS() UNCOM shows:
AMQ8450: Display queue status details.
QUEUE(SYSTEM.XXX.YYY.QUEUE)
TYPE(QUEUE) CURDEPTH(2627)
UNCOM(NO)
Looks like there was no uncommitted messages.
Not very sure what do you mean by "If the application has processed the message does that imply it does a browse to start with and then later goes back to destructively get the message?"
How to check and confirm above?
Thanks |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 22, 2017 10:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Maybe the subscription is too narrow for all the messages showing up in the queue - like subscribing to messages with a particular property, and the messages that are piling up don't have a matching property.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Mar 22, 2017 10:18 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| EricL wrote: |
Not very sure what do you mean by "If the application has processed the message does that imply it does a browse to start with and then later goes back to destructively get the message?"
How to check and confirm above? |
You'll need to talk to the application developer. To ask my question another way, how can the message still be on the queue if you know (as you stated earlier) that the application has processed it?
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| EricL |
| Posted: Thu Mar 23, 2017 10:53 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2014
Posts: 102
|
The way to verify the message still in subscription q after process is:
1. A specific message found out in subscription q
2. The same message also found out in a queue used for logging, e.g. all processed messages will be put into that queue for auditing purpose |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 23, 2017 11:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| EricL wrote: |
The way to verify the message still in subscription q after process is:
1. A specific message found out in subscription q
2. The same message also found out in a queue used for logging, e.g. all processed messages will be put into that queue for auditing purpose |
Perhaps pedantically, that doesn't disprove the scenario my worthy associate outlined. If the application browsed the message off, processed it, logged it and then abended trying to destructively get it, you'd see the situation you have here.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| EricL |
| Posted: Tue Mar 28, 2017 10:20 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2014
Posts: 102
|
Thanks Vitor.
is there anyway to prove your assumption?
Which MQ log should to check? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 28, 2017 10:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| EricL wrote: |
| is there anyway to prove your assumption? |
Reproduce the problem in test.
| EricL wrote: |
| Which MQ log should to check? |
MQ doesn't log application problems. Look in the application log.
Having first verified the application actually logs the kind of error I'm describing above. A distressing number of applications I've encountered over the years take an "oh well, never mind" view of MQ errors.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
