1 Aug 2012 21:25
Re: Curious issue with BO threshold
Thanks,
Ram Ramanathan
I can tell you that I have setup security that has PASSALL configured for this BO queue.On Wed, Aug 1, 2012 at 10:21 AM, Adrian Hadley <Adrian.Hadley <at> tnt.com> wrote:Neil,
Ah, not quite as simple as I thought then - I doff my cap to your superior wisdom. I live and learn, cheers!
From: Neil Casey <Neil_Casey <at> ACSLINK.NET.AU>
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Date: 01/08/2012 12:50Subject: Re: Curious issue with BO threshold
Hi Adrian,
my understanding of the situation makes me feel that your description is a mix of correct information, and some statements that are not quite right.
For MQI appiications (whether C, Java or whatever) the application is responsible for obtaining the BOQ and threshold information from MQ via MQINQ, and for checking the backout count against the threshold, and for putting the message to the BOQ if the threshold indicates a problem. MQ updates the back out threshold. It would be impossible for an application to do this itself.
For JMS however, the situation is different. The JMS specification does not deal with the issue. The MQ JMS provider could have implemented custom properties to enable poison message handling, but opted instead to simplify the programming model but dealing with it inside the JMS libraries instead.
JMS will perform the inquiry, checking and put of the message to the back out queue, without intervention from the application. The application is not advised that a message has been moved from the application queue to the back out queue. The app just receives the next message for it to process.
As has been pointed out previously in the thread, the PUT the JMS does to save the poison message uses PASSALL so that the MQMD information can be maintained. If the put fails, the message is put to the DLQ with a dead letter header instead.
MQ will generally not output a message for an application receiving 2035 (which is how MQ sees the situation where JMS performs the back out processing). JMS can't report it to the application, because it has not even told the application about the message in this unit of work. So JMS puts the message to the DLQ.
The permissions issue is critical, because the permissions required on the back out queue are quite different to those on the application input queue.
The application needs +get access (and +inq) on the input queue. But it needs +put +passall access on the back out queue. So a single setmqaut providing get and inquire access to the queue is going to lead to a situation where a poison message will end up on the DLQ.
Unless authorev(enabled) is set, this will not result in a visible notification, other than the backed out message itself.
Regards,
Neil Casey.
On 01/08/2012, at 5:59 PM, Adrian Hadley <Adrian.Hadley <at> TNT.COM> wrote:
Last time I looked into this (things may have changed, but I doubt it), it is the applications responsibility to handle message backout, incrementing of BO count, checking of BO count against the input queue's BOTHRESH and finally, when BO Count exceeds BOTHRESH, writing of the message to the BOQNAME associated with the input queue.
None of this happens automatically in MQ or the application. BOTHRESH and BOQNAME are just attributes of the queue, available for an application to enquire about, and then act on as appropriate, but coding is required to accomplish what you might think is nature.
Many application servers e.g. WAS handle this for you; completing this expected behaviour on behalf of the code they run.
My guess is that your application has partly implemented this behaviour, falling at the last hurdle of writing messages to the BOQNAME associated with the input queue, but instead writing (deliberately) to the DLQ?
From: Doug Clark <dcsquard <at> GMAIL.COM>
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Date: 31/07/2012 21:22
Subject: Re: Curious issue with BO threshold
Sent by: MQSeries List <MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT>> wrote:
I wish; No the only piece of information is in the DLQ says BO Threshold reached. However there is no activity in the actual BO queue. And the application is not logging why they are rejecting the message.
On Tue, Jul 31, 2012 at 2:54 PM, Barton, Linda <LINDA.BARTON <at> libertymutual.comAny hints in the dead letter header? Or the system.admin.qmgr.event queue?
Linda Barton
-----Original Message-----
From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Doug - Gmail
Sent: Tuesday, July 31, 2012 3:35 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Curious issue with BO threshold
Security is setup correctly.
The main queue 'APP01.QNAME.REQ' and 'APP01.QNAME.SUS' both are covered with setmqaut APP01.QNAME.** and messages arrive and are processed successfully on the APP01.QNAME.REQ - and there are no errors or logs indicating a 2035 security error sending to APP01.QNAME.SUS. Just the curious value that the BO Count Threshold has been exceeded on the message when it is in the DLQ.
-----Original Message-----
From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of DAVID AWERBUCH (BLOOMBERG/ 731 LEXIN)
Sent: Tuesday, July 31, 2012 1:48 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Curious issue with BO threshold
Hi Doug,
I would check the authorizations for the backout queue - make sure the application is able to PUT to it, including appropriate context settings.
Dave
----- Original Message -----
From: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
At: 7/31 14:43:11
I am seeing some strange behavior with queues being processed and sent to BO queues; This is a JMS application. But that is all I can tell you about the application side of things;
Message sent from remote system (mainframe) to local clustered queue running on AIX - MQSeries 7.0.1.6 - Qmgr1 and Qmgr2
Local cluster queue has a BO queue defined. however the message is not written on the BO queue but to the DLQ. Has anyone experience an issue like this before?
StrucId :'DLH '
Version :1
Reason :2362 (Backout threshold reached)
MQEncoding :0x'111'
CCSID :1208
Format :'MQHRF2 '
PutApplType :28 (Java)
PutApplName :'MQ JMS ConnectionConsumer '
Put Date :'20120731'
Put Time :'12085125'
[ 7346 bytes] Rules and Formatting (MQRFH2)
StrucId :'RFH '
Version :2
Struc Length :248
MQEncoding :0x'311'
CCSID :500
Format :' '
RFH Flags :00000000
NameVal CCSID:1208
Version: 7.0.1.6
CMVC level: p701-106-110725
* MO71 Export QM:MQMGR002 on Tue Jul 31 12:29:12 2012
*
DEFINE QLOCAL('APP01.QNAME.REQ') +
DESCR('XXXX YYYYYYYY - LP') +
CLUSTER('CLUSTER1') +
CLWLRANK(0) +
CLWLPRTY(0) +
CLWLUSEQ(QMGR) +
MAXDEPTH(100000) +
MAXMSGL(4194304) +
USAGE(NORMAL) +
DEFPRTY(0) +
DEFPSIST(NO) +
DEFPRESP(SYNC) +
DEFREADA(NO) +
DEFBIND(NOTFIXED) +
MSGDLVSQ(PRIORITY) +
PUT(ENABLED) +
GET(ENABLED) +
HARDENBO +
BOTHRESH(1) +
BOQNAME('APP01.QNAME.SUS') +
SHARE +
DEFSOPT(SHARED) +
RETINTVL(999999999) +
NOTRIGGER +
TRIGTYPE(FIRST) +
TRIGMPRI(0) +
TRIGDPTH(1) +
SCOPE(QMGR) +
QDEPTHHI(80) +
QDEPTHLO(20) +
QDPMAXEV(ENABLED) +
QDPHIEV(DISABLED) +
QDPLOEV(DISABLED) +
QSVCINT(999999999) +
QSVCIEV(NONE) +
DISTL(NO) +
STATQ(QMGR) +
ACCTQ(QMGR) +
MONQ(QMGR) +
PROPCTL(COMPAT) +
REPLACE
* MO71 Export QM:MQMGR002 on Tue Jul 31 12:41:57 2012
*
DEFINE QLOCAL('APP01.QNAME.SUS') +
DESCR('XXXX YYYYYYYY - LP') +
CLWLRANK(0) +
CLWLPRTY(0) +
CLWLUSEQ(QMGR) +
MAXDEPTH(10000) +
MAXMSGL(4194304) +
USAGE(NORMAL) +
DEFPRTY(0) +
DEFPSIST(NO) +
DEFPRESP(SYNC) +
DEFREADA(NO) +
DEFBIND(NOTFIXED) +
MSGDLVSQ(PRIORITY) +
PUT(ENABLED) +
GET(ENABLED) +
HARDENBO +
BOTHRESH(0) +
SHARE +
DEFSOPT(SHARED) +
RETINTVL(999999999) +
NOTRIGGER +
TRIGTYPE(FIRST) +
TRIGMPRI(0) +
TRIGDPTH(1) +
SCOPE(QMGR) +
QDEPTHHI(80) +
QDEPTHLO(20) +
QDPMAXEV(ENABLED) +
QDPHIEV(DISABLED) +
QDPLOEV(DISABLED) +
QSVCINT(999999999) +
QSVCIEV(NONE) +
DISTL(NO) +
STATQ(QMGR) +
ACCTQ(QMGR) +
MONQ(QMGR) +
PROPCTL(COMPAT) +
REPLACE
To unsubscribe, write to LISTSERV <at> LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
To unsubscribe, write to LISTSERV <at> LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
---------------------------------------------------------------------------------------------------------------
This message and any attachment are confidential and may be privileged or otherwise protected from disclosure.
If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system.
If you are not the intended recipient you must not copy this message or attachment or disclose the contents to any other person.Please consider the environmental impact before printing this document and its attachment(s).
Print black and white and double-sided where possible.----------------------------------------------------------------------------------
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - UnsubscribeInstructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
RSS Feed