| Author |
Message
|
| sneh |
 Posted: Thu Feb 01, 2007 12:12 am Post subject: AMQ8143: WebSphere MQ queue not empty while xmit Q clear |
 |
|
Apprentice
Joined: 12 Aug 2006
Posts: 28
Location: Mumbai
|
Hi..
I am trying to clear a Xmit queue.
The channel between 2 queue managers is in RETRYING status and hence the messages are waiting in transmit queue.
We need to clear this queue as it has reached its threshold.
But the following error was shown on clear ql()
[b]AMQ8143: WebSphere MQ queue not empty.[/b]
can someone help us in this. |
|
| Back to top |
|
 |
| obriencm |
| Posted: Thu Feb 01, 2007 12:17 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
| Have you tried resolving the channel, to force a backout or commit of the message? |
|
| Back to top |
|
|
| sneh |
| Posted: Thu Feb 01, 2007 12:22 am Post subject: |
|
|
Apprentice
Joined: 12 Aug 2006
Posts: 28
Location: Mumbai
|
So there is no way to clear the queue directly?
If I change the channel property I would require to change it when receiver channel comes up.
Here the scenario is if receiver goes down n xmit queue reached threshold then clear queue else wait for receiver channel to come up. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 01, 2007 1:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
The better way is to fix the channel.
Assuming your architecture can stand the loss of the messages you'll still need to fix the channel (a full xmitq is not the cause of retrying status).
You might want to consider stopping the channel and destructively reading the messages with the q program or similar.
I'd still fix the channel as a preferred resolution.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Feb 01, 2007 5:46 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
Assuming your architecture can stand the loss of the messages you'll still need to fix the channel (a full xmitq is not the cause of retrying status).
|
I would say that was a safe assumption if he is clearing the messages so I am definately with you....fix the real problem not the symptoms. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 01, 2007 5:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kevinf2349 wrote: |
| I would say that was a safe assumption if he is clearing the messages so I am definately with you....fix the real problem not the symptoms. |
I have on occassions been asked to fix backed-up queues by "clearing out the extra messages" so I always ask.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 01, 2007 10:45 am Post subject: |
|
|
Guest
|
Clearing the messages means losing the data in the messages. Not a best practice.
If you know that the channel won't run, then put disable the remote definition that programs are MQOPENing. This will be detected by the application. Alternatively, put disable the xmit queue OR disable the application.
The long-term fix: Good application architecture calls for a xmit queue maxdepth to allow for instances where the channel can't enter RUNNING state for whatever reason. Mid-range platform default maxdepth is 5000. Alter yours to 50,000 or 100,000, or whatever you think will be enough to hold messages that accumulate in the xmitq while the channel is not running. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Fri Feb 02, 2007 12:08 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| bruce2359 wrote: |
| Clearing the messages means losing the data in the messages. Not a best practice... |
Resolving the channel may also lead to lost or duplicated messages!
_________________
Regards
Hubert |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Feb 02, 2007 9:18 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| HubertKleinmanns wrote: |
| Resolving the channel may also lead to lost or duplicated messages! |
Only if you fail to follow the documented procedures from the Intercommunication Guide.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| BBJ |
| Posted: Mon Feb 05, 2007 4:58 am Post subject: How I fixed this shit situation for MQ5.3 ; SunOS 5.10 |
|
|
Novice
Joined: 05 Feb 2007
Posts: 16
|
This has to do with a Unit_Of_Work (Transaction) somehow getting interrupted.
U will find that the 'uncom' attribute of the XMIT Queue is set to 'YES'.
It is not possible to change it with an 'alter' command :
display qstatus(Queue_Name)
AMQ8450: Display queue status details.
QUEUE(Queue_Name)
...
UNCOM(YES)
And, trying to fix this situation is like having a dose of Herpes !
Try - dspmqtrn & rsvmqtrn - as recommended in the manual supplied by that great company with the great management structure : IBM  .
Do a Google (enter AMQ8143). U will find some more information - especially, on this WebSite.
Then - when nothing else works, U can try the following :
1. Stop the (Retrying) SDR Channel (just for good measure)
2. Enable the 'GET' on the XMIT Queue
3. Since U don't need the messages, use the sample 'GET' program
(amqsget) to read all the messages out of the Queue. This will
set the CURDEPTH to ZERO - but, when trying to issue a 'clear'
(or delete) command on the XMIT Queue, MQ still thinks that there
are messages in the Queue (!!!) - and , it still doesn't work.
Not to worry. So ... on we go ...
4. End the Queue Manager ; check for and delete any processes
using MQ ; clean the IPCSs - ipcrm (just for good measure)
5. Go to the File System :
cd /var/mqm/qmgrs/ <QMgr_Name> /queues
Find the offending XMIT Queue Directory
Save it and its content ( file -> q ) in your Home Directory
( just in case you need to restore it later )
6. Delete (rm -rf) that Directory and its contents -> the offending 'q'
7. Start the QMgr again
8. Do a 'runmqsc' and issue a 'display' command on the offending
XMIT queue ; U will get a funny message ... forget it ...
9. Issue a 'delete' command on the offending XMIT queue ; this cleans up
any 'other' bits and pieces associated with the queue
10. Then, define the Queue again
11. Display it and, also run :
display qstatus(Queue_Name)
AMQ8450: Display queue status details.
QUEUE(Queue_Name)
...
UNCOM(NO) 
12. Start the SDR Channel again
13. It should now be possible to successfully issue normal MQ commands
to the XMIT Queue again
I hope the above works.
Otherwise, U can always restore the queue which U saved and try some other suggestion. |
|
| Back to top |
|
|
| sneh |
| Posted: Wed Feb 07, 2007 7:37 am Post subject: |
|
|
Apprentice
Joined: 12 Aug 2006
Posts: 28
Location: Mumbai
|
|
| Back to top |
|
|
| George Carey |
| Posted: Mon May 11, 2009 4:50 pm Post subject: BBJ response |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
I had to laugh ... at BBJ's response which I found after doing google search for similar error message: Websphere MQ Q not empty
Now there is post clearly written after some blood on the floor!!
After using the MS071 tool to copy some messages to a file. I tried to clear the queue and couldn't ... had the same problem which I still don't know why it had a transactional commit problem but from this email saw that there were 2 uncomm messages ... but at least I knew what the problem was !!
Fortunately mine was easier to clear than his !! 
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 12, 2009 8:58 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
BBJ's post is a little bit over the top. I would never advise to go into the file system and delete information even for a stopped qmgr...
We have dealt with a bad XA TM for some time now. Thank God we're off of it now.
We had to run dspmqtrn and rsvmqtrn on the qmgr and it has implications to the xmitq. Then there were still messages left (lookup my posts on ghost messages from about over a year ago...) Finally bouncing the qmgr provided a clean xmitq. Let the app back at it and it soon will have the same "dirty" state... However the retrying channel is a different problem and should be resolved according to manual... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sumit |
| Posted: Wed May 13, 2009 1:15 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| HubertKleinmanns wrote: |
| bruce2359 wrote: |
| Clearing the messages means losing the data in the messages. Not a best practice... |
Resolving the channel may also lead to lost or duplicated messages! |
I can understand about losing messages. But how can they be duplicated?
_________________
Regards
Sumit |
|
| Back to top |
|
|
| exerk |
| Posted: Wed May 13, 2009 1:37 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| sumit wrote: |
| ...I can understand about losing messages. But how can they be duplicated? |
Because if you resolve by rolling back, a message will be 're-sent'. The in-doubt is because the queue manager cannot be certain the other end has received and committed, and if the other end then receives that message 'again' it will in effect be a duplicate..
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
