| Author |
Message
|
| EricL |
 Posted: Fri Oct 10, 2014 10:48 am Post subject: Queue Messages Auto Truncated |
 |
|
Centurion
Joined: 10 Oct 2014
Posts: 108
|
Hi Guys,
We have a queue, created on WebSphere MQ V6, and MQ installed on AIX.
This Q is used to log whatever messages processed by application in case there is need to retrieve the message in furure.
These days we noticed that the messages from the Q trancated daily without any reason, we don't have any script doing clean job, and we firstly found out that "/var/mqm/errors" was 100% in use, so we cleared logs under "/var/mqm/errors" and usage drop to 1%.
But the messages kept on losing, and the Q depth changed to 0 after 1 0r 2 days, can anyone from forum provide any advice on this ?
Thanks !
EricL |
|
| Back to top |
|
 |
| PaulClarke |
| Posted: Fri Oct 10, 2014 10:50 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
How do the messages get on the queue in the first place ? Is it possible that they are now being put with a finite expiry value ?
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| EricL |
| Posted: Fri Oct 10, 2014 11:03 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2014
Posts: 108
|
Thanks Paul for your prompt response.
Don't think finite expiry values was added, we have similiar env setting on testing/qa/prod, and messages gone only happens on testing |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Oct 10, 2014 11:12 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
- MQ V6 is EOS (long time ago), upgrade to MQ V7.5
- Did you separate your file systems in a meaningful way?
- /var/mqm -for everything but the Qmgr and logs
- /opt/mqm -for the install (might be /usr/mqm)
- For each Qmgr
- /var/mqm/qmgr/<QmgrName>
- /var/mqm/log/<QmgrName> -set your primary logs to fill this to 70%, secondary the rest of the way
You should only need to clear FDCs from /var/mqm/errors and that is after you have resolved whatever the problem was.
If you don't know how big the file systems should be, default to 4GB and adjust as needed. |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Oct 10, 2014 5:13 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 942
Location: Illinois, USA
|
Hi EricL,
Queue accounting and statistics could be helpful for tracking if an application is getting these messages from this Q. Also, if there are messages currently on this Q, have you used a tool like amqsbcg to confirm that the expiry is set to unlimited? |
|
| Back to top |
|
|
| sumit |
| Posted: Sat Oct 11, 2014 6:08 pm Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
Please also check if the messages are persistent. And if queue manager restart is removing the non-persistent messages.
What happen to the messages sitting in this queue? Any application which read them? Was that application started and read all the messages?
_________________
Regards
Sumit |
|
| Back to top |
|
|
| EricL |
| Posted: Tue Oct 14, 2014 8:11 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2014
Posts: 108
|
Thanks for all the response.
I'd like to provide more info here:
1. The file systems separated in meaningful way:
/var/mqm for qmgrs and log while /usr/mqm is for MQ installation
2. As I mentioned before, the Q is just used as a log for us to retrieve(manually) what messages have been received and processed by application, no applications use this Q.
3. The Q is persistent
Thanks |
|
| Back to top |
|
|
| tczielke |
| Posted: Tue Oct 14, 2014 8:31 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 942
Location: Illinois, USA
|
| Is it possible that there is some process/application that you are not aware of that is getting these messages from Q? If so, the queue accounting and statistics would help confirm/dispute that possibility. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 14, 2014 9:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| EricL wrote: |
| 3. The Q is persistent |
And once again, I'll repeat this old saw:
Just because the default on the queue is "persistent", that's no guarantee the messages are. Setting DEFPSIST(YES) on a queue does nothing to set the persistence of a given message. The persistence of a message is determined by the putting application, which may or may not decide to use the default supplied on the queue definition.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| EricL |
| Posted: Tue Oct 14, 2014 11:19 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2014
Posts: 108
|
Hi Guys,
Do understand what you guys mean to, the most interesting thing is we have Prod/QA/Testing environments installed and configured with same application and software, but messages auto gone only happen in testing env, super tricky things...
Thanks, |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 14, 2014 11:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| EricL wrote: |
| we have Prod/QA/Testing environments installed and configured with same application and software, but messages auto gone only happen in testing env |
Again with the old saws (equally obvious as the last one I posted):
- the same application in Prod/QA/Testing typically has 3 different configurations even if the code is identical; for instance different URLs for end points. Such configurations can be used to control (for example) message persistence and expiry values
- Prod/QA/Testing are seldom identical; for instance Testing often has fewer resources allocated to it and (for example) queue managers can be restarted on a whim rather than after a convoluted change control process
- Testing enviroments are often reset so that tests can start from a known base line. This can include (for example) clearing message queues and truncating database tables.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 14, 2014 11:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
As has been suggested further up this thread, if you want to know what's clearing these messages out enable the accounting and statistics. And if you're certain that the messages in the queue are persistent (as distinct from the queue having default persistence) and the expiry is unlimited then the next option is something is clearing them out, either by reading them or via an administrative command.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Oct 14, 2014 2:34 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
You could try get disabling the Q and see if anything fails.
_________________
Glenn |
|
| Back to top |
|
|
|
|
