| Author |
Message
|
| sebastia |
 Posted: Wed Feb 14, 2007 4:51 am Post subject: Alias Q and Local Q - one of them Persistent |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
We are having a discussion here, and need to clarify one item.
If we have an alias queue QA1 that has DEFPSIST=YES
and points to QL1 using TARGQ("QL1"),
and that local queue QL1 that has DEFPSIST=NO ...
will the messages survive the queue manager Restart ?
And the inverse situation ?
( QA1 has "DEFPSIST=NO" and QL1 has "DEFPSIST=YES" )
Thanks ! |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Feb 14, 2007 5:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Non-persistant messages do not survive a queue manager restart unless the queue has NPMCLASS set to allow for it.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Feb 14, 2007 5:28 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Messages are persistent, NOT queues.
The "persistence from queue default" value will be taken from the queue that is referenced on the MQPUT (the alias queue value if that is the one opened will be used rather than the base queue). |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Feb 14, 2007 5:34 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
As jeoff mentions, its messages that have persistence, not queues.
The DEFPSIST option indicates what the persistence will be for messages that are put with the MQPER_PERSISTENCE_AS_Q_DEF.
Thus if you use MQPER_PERSISTENT or MQPER_NOT_PERSISTENT on your MQPUT, the messages will be/not be persistent regardless of the QALIAS/QLOCAL's DEFPSIST setting.
If your MQPUT uses MQPER_PERSISTENCE_AS_Q_DEF, then if you MQOPEN the QALIAS, the message gets the persistent of the QALIAS's DEFPSIST option regardless of the QLOCAL's setting. If you MQOPEN the QLOCAL directly, your message gets the persistence from the QLOCAL's DEFPSIST option regardless of the QALIAS's setting.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| sebastia |
| Posted: Wed Feb 14, 2007 5:52 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
thanks to all pointing to the truth that Messages are persistent, not queues
we knew that - thanks anyway.
and yes, I fogot to specify we are talking about a MQPUT()
with "MQPER_PERSISTENCE_AS_Q_DEF", so it is taken from the queue.
I'd say this is the usual envir I find : the application programmers dont
want to know about the consequences of those bits, so we rely on the
definition of queues, here.
Well - then, as Scott says, the Persistence is taken from the queue
we do MQOPEN() to. Or, in fact, it is the queue we do a MQPUT() into ...
Fantastic. That was a great answer. Thanks to all.
Is it too demanding
to ask for a pointer to any documentation explaining this point ?
( I always ask for such strange things, I never get an answer ... )
( ) |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 14, 2007 6:02 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Again, though, if the actual qlocal has the right value for NPMCLASS, then non-persistant messages will survive restart.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Wed Feb 14, 2007 7:07 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| jefflowrey wrote: |
| Again, though, if the actual qlocal has the right value for NPMCLASS, then non-persistant messages will survive restart. |
But only for "normal" restarts . If the QMgr crashes or the processes have been killed, the message will be lost.
I Think, the question of sebastia should be:
| Quote: |
| When an application uses "MQPER_PERSISTENCE_AS_Q_DEF", what will be the persistence of the messages? |
This question could be answered as follows:
Scenario 1: QA1 has DEFPSIST=YES, QL1 has DEFPSIST=NO:
- If the application puts (opens) to QA1 -> message is persistent
- If the application puts (opens) to QL1 -> message is non-persistent
Scenario 2: QA1 has DEFPSIST=NO, QL1 has DEFPSIST=YES:
- If the application puts (opens) to QA1 -> message is non-persistent
- If the application puts (opens) to QL1 -> message is persistent
If messages survive a "normal" QMgr restart or not is defined by the persistence of the message and (for non-persistent messages only) by the value of "NPMCLASS".
_________________
Regards
Hubert |
|
| Back to top |
|
|
| sebastia |
| Posted: Wed Feb 14, 2007 8:03 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Jeff : the "normal" qm restarts are not to be considered,
as it is with the "unusual" restarts when you will loose the messages.
So, lets forget about NPMCLASS.
Hubert - thanks for your clear "resume".
And thanks to you all for making my living easier.
S. |
|
| Back to top |
|
|
| tleichen |
| Posted: Wed Feb 14, 2007 8:20 am Post subject: Re: Alias Q and Local Q - one of them Persistent |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| sebastia wrote: |
...we have an alias queue QA1 that has DEFPSIST=YES
and points to QL1 using TARGQ("QL1"),
and that local queue QL1 that has DEFPSIST=NO ...
|
My first question would be.... WHY? If you're going to control message persistence with the queue attributes, why would you make an alias queue with an inconsistent attribute from the corresponding local queue? 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 14, 2007 8:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Because you do want to control the attributes at the queue level, and want to provide different attributes for different applications to send messages to the same receiving application.
App1->QA1 (persistant) -> QL1 -> receiver1
App2->QA2(NP) -> QL1 -> receiver1
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Thu Feb 15, 2007 12:31 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| jefflowrey wrote: |
Because you do want to control the attributes at the queue level, and want to provide different attributes for different applications to send messages to the same receiving application.
App1->QA1 (persistant) -> QL1 -> receiver1
App2->QA2(NP) -> QL1 -> receiver1 |
Another solution could be
App1->QA1 with GET(ENABLED), PUT(DISABLED) -> QL1
App2->QA2 with GET(DISABLED), PUT(ENABLED) -> QL1
But I would suggest, to define the persistency NOT via q attributes, but the application should use "MQPER_PERSISTENT" or "MQPER_NOT_PERSISTENT" instead.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| sebastia |
| Posted: Thu Feb 15, 2007 2:26 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
This time Jeff has got EXACTLY our environment !!!
a) Applications developers do NOT want to know about Persistency.
b) one application messages ARE important, so they have to survive
c) another application messages are NOT (so) important, so can be allowed to be lost in extreme cases
d) both [b] and [c] have to use the same LOCAL queue
... so, the right place to IMPLEMENT or SPECIFY our requirements
is in the ALIAS parameters.
Thanks to all of you to help us see it more clear !
S. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Thu Feb 15, 2007 2:36 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| sebastia wrote: |
This time Jeff has got EXACTLY our environment !!!
a) Applications developers do NOT want to know about Persistency.
b) one application messages ARE important, so they have to survive
c) another application messages are NOT (so) important, so can be allowed to be lost in extreme cases
d) both [ b ] and [ c ] have to use the same LOCAL queue
... so, the right place to IMPLEMENT or SPECIFY our requirements
is in the ALIAS parameters.
Thanks to all of you to help us see it more clear !
S. |
Sorry, but this is stupid!
Only the application is available, to decide, whether a message is important or not, because it depends on the application's context!
As MQ administrator you cannot know, which messages are put to the Queue!
And you definitely cannot guarantee the persistence of a message!
_________________
Regards
Hubert |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Feb 15, 2007 4:02 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| sebastia wrote: |
This time Jeff has got EXACTLY our environment !!!
a) Applications developers do NOT want to know about Persistency.
b) one application messages ARE important, so they have to survive
c) another application messages are NOT (so) important, so can be allowed to be lost in extreme cases
d) both [b] and [c] have to use the same LOCAL queue
... so, the right place to IMPLEMENT or SPECIFY our requirements
is in the ALIAS parameters.
Thanks to all of you to help us see it more clear !
S. |
I agree with HubertKleinmanns - consider the implications of an administrator changing the QA attribute to NON-PERSISTENT, suddenly important messages may go missing.
If the application considers the message to be so important it cannot be lost - GET THE APPLICATION TO SET PERSISTENCE!
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Feb 15, 2007 6:00 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
a) Applications developers do NOT want to know about Persistency.
|
What do you mean? Do you mean that that they don't want to know about what it is and why in is vital to the busines to get it correct. Or do you mean they don't want to have to consider the persistency of the messages going from one environment to the other (development to production)?
Either way IMHO Persistency of the business data is a vital consideration when designing business applications you simply can't ignore it.
Someone once suggested to me that 'persistence was always a given in a production environment'....needless to say they got shot down on that one. |
|
| Back to top |
|
|
|
|
