| Author |
Message
|
| fordcam |
 Posted: Mon Oct 02, 2006 1:06 pm Post subject: DEFPSIST on SCTQ |
 |
|
Apprentice
Joined: 28 Mar 2002
Posts: 35
Location: MGIC
|
What would the implications be in changing SYSTEM.CLUSTER.TRANSMIT.QUEUE's default persistence?
Since we went to clustering, I've run into some problems with a couple of apps that send replies. We see messages on the DLQs with a 2048 (MQRC_PERSISTENT_NOT_ALLOWED) reason code. The DLH shows that the target queue was a temporary dynamic queue, and persistent messages are not allowed on a tempdyn queue.
I think the problem is that SCTQ has DEFPSIST(YES), while our regular transmit queues all had the default persistence set to NO. Our reply apps use ReplyToQ and ReplyToQMgr, and therefore directly opens the transmit queue. Most such apps "inherit" the reply persistence from the original request, but not all of them. And if they don't specify a persistence they will pick up the XMITQ default. That default is now YES, so if there's a tempdyn queue on the other end it won't work.
It will take a little time to identify and correct the code. In the meantime, it seems like I should be able to make SCTQ DEFPSIST(NO), right? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Oct 02, 2006 3:27 pm Post subject: |
|
|
Guest
|
DEFPSIST attribute of a queue only takes effect when the application that MQPUTs the message specifies PERSISTENCE_AS_Q_DEF. The programmer must specify (in the MQMD) one of three options (PERSISTENT, NON_PERSISTENT, or PERSISTENCE_AS_Q_DEF.
In any case, a PERSISTENT message can not be put into a temporary dynamic queue. The the application that created the reply-to-queue should have created a permanent dynamic queue to allow for persistent messages from the replying application. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Oct 03, 2006 12:29 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The DEFPSIST attribute of the cluster xmitq does not affect the persistence of msgs put to cluster queues; the msgs take their persistence from the DEFPSIST attribute of the target queue.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 03, 2006 2:35 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What of the following case?:
Reply to Q is not clustered but Replyto qmgr is in the cluster.
So where does the message take the default persistence from (as qdef)?
I believe in this case the defpsist attribute is taken from the qmgr alias or if it doesn't exist from the corresponding xmitq the message is being put to.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 03, 2006 6:52 am Post subject: |
|
|
Guest
|
Back to the original post: "We see messages on the DLQs with a 2048 (MQRC_PERSISTENT_NOT_ALLOWED) reason code. The DLH shows that the target queue was a temporary dynamic queue, and persistent messages are not allowed on a tempdyn queue."
This means that the replying application created a persistent (reply) message, and that the reply-to-queue (created by the requesting application) is a temporary-dynamic queue. This is working as designed. To allow persistent messages in a temporary queue would violate the assured message delivery rules.
The default persistence attribute of a queue will not change a persistent message to non-persistent. The DEFPSIST queue attribute is not really a 'default'. It should have been called 'IF_THE_PROGRAMMER_SPECIFIED_PERSISTENCE_AS_Q_DEF_THEN_TAKE_THE_DEFPSIST_QUEUE_ATTRIBUTE_FOR_THIS_MESSAGE'. But, this is too long...  |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Oct 03, 2006 7:02 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The persistence is BIND_ON_OPEN if no object can be found to take the persistence from.
The DEFPSIST attribute of the SCTQ is not used.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 03, 2006 7:34 am Post subject: |
|
|
Guest
|
"What would the implications be in changing SYSTEM.CLUSTER.TRANSMIT.QUEUE's default?"
A more general view: Be very cautious about changing attributes of system objects (SYSTEM.DEFAULT..., SYSTEM.CLUSTER...) or objects used by many applications (like xmit queues). While such a change may solve a specific problem for one application, it may adversely affect many/all others.
If you want a persistent message, have the application programmer specify that attribute when MQPUTting the message. If the replying application is sending a persistent reply message, then the reply-to-queue must be permanent-dynamic. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 03, 2006 2:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Nigelg wrote: |
The persistence is BIND_ON_OPEN if no object can be found to take the persistence from.
The DEFPSIST attribute of the SCTQ is not used. |
Sorry Nigel a little confusion occurred here. Bind_on_open is not a persistency attribute!
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Oct 04, 2006 12:12 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Sorry, I have been looking at too many cluster problems lately!
I have had another look, and I was wrong...
The persistence from the cluster xmitq is used if the destination queue is not found in the cluster.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
|
|
