| Author |
Message
|
| jeevan |
 Posted: Mon Mar 27, 2006 9:24 am Post subject: Unable to send with primary queue: |
 |
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
Applicaiton can not connect to the server and ended with this error message and error code 2053. I checked that error message and check queue deapth and MCA. There is not a condition to get that error message. What could you other reason> Can any one give some clue?
thanks |
|
| Back to top |
|
 |
| vennela |
| Posted: Mon Mar 27, 2006 9:26 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
What type of queue is it?
What all queues did you check |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Mar 27, 2006 9:32 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Uncommitted messages maybe? |
|
| Back to top |
|
|
| jeevan |
| Posted: Mon Mar 27, 2006 10:40 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
this is a local queue connecting through svrconn channel. I checked everything but I do not see any problem.
any suggestion?
a similar queue manager in another box is working fine
thanks |
|
| Back to top |
|
|
| jeevan |
| Posted: Mon Mar 27, 2006 10:52 am Post subject: Fixed it |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Mar 27, 2006 10:59 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What did you change?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jeevan |
| Posted: Mon Mar 27, 2006 1:28 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
When I check at the beginning, there were not message in the queue ( currdepth was 0).
but when I stopped and restared the queue manager, I saw the queue was full. The error message was also the same 2053 queue full. The only problem was it did not show at the beg. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Mar 27, 2006 1:32 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jeevan wrote: |
When I check at the beginning, there were not message in the queue ( currdepth was 0).
but when I stopped and restared the queue manager, I saw the queue was full. The error message was also the same 2053 queue full. The only problem was it did not show at the beg. |
| kevinf2349 wrote: |
| Uncommitted messages maybe? |
We have a winner!
The application that is supposed to GET messages from this queue is apparently doing it in syncpoint, and not committing that syncpoint.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jeevan |
| Posted: Tue Mar 28, 2006 7:03 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
could you please explain what you mean exactly.
thanks a lot |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 28, 2006 8:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay. Messages can be gotten (or put) inside a logical unit of work.
This is kind of like a browse, except more complicated. It allows for your program to get messages destructively, but remain assured that if your program crashes then the messages will remain on the queue until you try to get them again.
It's exactly like units of work with databases - transactional operations.
When a message is gotten under a unit of work - the message is marked as "not available" (basically) and can't be seen by anything other than the program that executed the GET. BUT, the message is still on the queue and so the queue depth does not go down. When the unit of work is committed, then the messages within that unit of work are actually removed from the queue and the queue depth decreases.
The symptoms you gave - that the queue depth was equal to the max depth but that no messages were visible - exactly fits the case of messages in a unit of work that have not been committed yet.
When you stopped the queue manager, you aborted the unit of work that the program had open. This caused the unit of work to rollback - which restored the messages back to the queue to be gotten again. So then you could see them again after the qmgr restarted.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jeevan |
| Posted: Tue Mar 28, 2006 9:35 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| Thank you very much for your detailed explanation. |
|
| Back to top |
|
|
| BBM |
| Posted: Wed Mar 29, 2006 12:09 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi,
Just wondering if there is any other way to abort the UOW without restarting the QM?
Thanks
BBM |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Mar 29, 2006 2:13 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Yes, kill the app. The UoW is backed out by the agent when it notices the app is no longer present.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Mar 29, 2006 4:06 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
and, one of the nice new features of MQ V6 is the ability to terminate a connection to an application via the Explorer or MQSC.
| Quote: |
| STOP CONN(connection-identifier) |
Thus, even if you can't "kill" the program (say, because you're not root), you can still terminate the connection.
_________________
-wayne |
|
| Back to top |
|
|
|
|
