| Author |
Message
|
| PeterPotkay |
 Posted: Mon Feb 02, 2015 6:52 am Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
See http://www.mqseries.net/phpBB2/viewtopic.php?p=387603#387603
| zpat wrote: |
Put in the mqm userid's .profile command script, along with any others you want. For example
| Code: |
export MQS_REPORT_NOAUTH=TRUE
export AMQ_DUMP_NO_PROPERTIES=TRUE
export AMQ_XA_ZOMBIE_EXPIRY=3600
export EXTSHM=ON
export GSK_STRICTCHECK_CBCPADBYTES=GSK_TRUE
|
|
I'd love to see a comprehensive list of all the options we have for settings like this, explaining what each one means, the valid values, and why you would want to use it.
I bet there are at least a couple of dozen.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| zpat |
| Posted: Mon Feb 02, 2015 7:52 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
So would I ...
http://www.mqseries.net/phpBB2/viewtopic.php?t=61412
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Inisah |
| Posted: Mon Feb 02, 2015 8:43 am Post subject: |
|
|
Apprentice
Joined: 21 Mar 2014
Posts: 44
|
Thanks everyone. Your inputs definitely helped me !!  |
|
| Back to top |
|
|
| tczielke |
| Posted: Mon Feb 02, 2015 9:28 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
You can build a makeshift list with something like the following:
strings /opt/mqm/lib64/*.so | grep AMQ_ | sort | uniq
Around 200 popped out just for variables that start with AMQ_.
Of course, what is more important is what they mean and do. I guess you could give the list (or a subset that you care about) and ask IBM with a PMR. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Feb 02, 2015 10:45 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
IMHO the problem is that some are for diagnostic purposes (i.e. under direction of IBM relating to a PMR). Just setting them willy-nilly could make your system unstable. (combinations of settings)
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| tczielke |
| Posted: Mon Feb 02, 2015 10:58 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| smdavies99 wrote: |
| IMHO the problem is that some are for diagnostic purposes (i.e. under direction of IBM relating to a PMR). Just setting them willy-nilly could make your system unstable. (combinations of settings) |
I agree that you should not use any of these environment variables, without first receiving direction from IBM on how to use them.
On a side note:
| Code: |
| export AMQ_XA_ZOMBIE_EXPIRY=3600 |
I guess along with some of the characters of the Walking Dead, MQ also struggles with zombie management . . . |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Feb 02, 2015 1:19 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Yes, that one was added due to an APAR resulting from one of my PMRs - we were just overrun by zombies!
Now the "walkers" just expire themselves (saves on ammo)...
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 02, 2015 5:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
export AMQ_XA_ZOMBIE_EXPIRY=3600
|
Also called "ghost" messages by the less aggressive of us... or may be just those who don't have any ammunition to burn through... 
But seriously, as much as I understand the problem, should you not be looking primarily at fixing the cause instead of just dealing with the aftermath??
As we were getting a little bit off topic, I went ahead and split the post... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 02, 2015 7:20 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
An episode of "The Simpsons" had zombies rising from the grave to attach Springfield. Someone screams "Zombies!," to which one of them responds "We're not zombies; we're living impaired."
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Feb 02, 2015 11:02 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
These particular zombies are not ghost messages as much as orphaned transactions in queue manager memory.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 03, 2015 5:46 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
| These particular zombies are not ghost messages as much as orphaned transactions in queue manager memory. |
So do they show on dspmqtrn -a ?
My reference to Ghost messages was about messages put in a transaction that never got the XA prepare to commit call and the connection got cut...
So unless the TM can recover and try to resolve the transaction (commit or backout) the messages are stranded on the qmgr in a state that prevents any access... hence ghost or zombies???
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Feb 03, 2015 6:01 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
http://www-01.ibm.com/support/docview.wss?uid=swg1IV21986
As I recall our problem was large memory use and slowdown. It occured when there was a logic error in the application (so not under normal circumstances).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Andyh |
| Posted: Tue Feb 03, 2015 9:44 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
The XA specification is a little loose, which gives rise to some differences in interpretation between different resource managers (RMs) and transaction managers (TMs). Most long lived zombie transactions seem to arise from these differences in the interpretation of the XA spec.
A zombie transaction is a transaction that has been rolled back, or committed, but where references to the transaction still exist.
Not all zombies are created equal, and most disappear very quickly without ever being visible.
Example 1: a transaction that was asynchronously rolled back to release log space would become a zombie that would be cleaned up when the corresponding hConn next tried to access the transaction. The hConn would receive an MQRC_BACKED_OUT response.
Example 2: an XA transaction where the transaction manager (TM) calls xa_end() with TMFAIL, but never issues an xa_rollback().
Example 3: a timing window where a transaction ends while it is being checkpointed.
Examples 1 and 2 should be visible to dspmqtrn as they have application visibility implications, while there are no external implications in example 3 and dspmqtrn has no need to display that transaction.
Once the zombie transaction is unreferenced it should be released from memory, the issue comes in example 2 where MQ would like to give the TM
an XA_RB style error when (if) the xa_rollback finally arrives, and if MQ deletes the zombie it will have to give XAER_NOTA. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 03, 2015 10:44 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
So what about if the message gets put under control of a TM and the connection to the TM gets cut before an XA_Prepare for commit, an XA_rollback, or XA_end gets ever sent?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Andyh |
| Posted: Tue Feb 03, 2015 11:11 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
If the connection is broken before xa_end() then the transaction will be backed out as part of tearing down the connection.
If the connection is broken after xa_perpare() then the transaction should be resolved following the next xa_recover().
The commonly problematic window is between xa_end() and xa_prepare(). |
|
| Back to top |
|
|
|
|
