| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| How to change the Queue Persistence NO to YES |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Thu Aug 20, 2009 7:28 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
Non-persistent messages are subject to being discarded by the qmgr or MCA in certain circumstances that are beyond the control of management and sysadmins.
This is the message I tell my clients (people, not applications).
_________________
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 |
|
 |
| PeterPotkay |
| Posted: Thu Aug 20, 2009 7:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| Vitor wrote: |
| WMBDEV1 wrote: |
| I personally dont believe this to be true. |
I've personally seen this. One application team lead told me to my face, "all our messages are persistent because if they weren't important we wouldn't send them".
|
I actually don't have a problem with that line of thinking...not the persistent part, but the important part. I use it for the channel speed. I have mine set to normal everywhere so MQ doesn't toss non persistent messages due to network blips. Another MQ Admin said if they cared about their messages, they would make them persistent. I said, no, if they didn't care about their messages they wouldn't have sent them to begin with. They care. And if they sent a non persistent message and MQ gave them a 0 RC on their MQPUT(1), then MQ should not toss it. Channel speeds will be normal in my MQ infrastructure. Whether a message is persistent or not is determined by asking yourself does the message need to be able to survive a planned or unplanned QM restart, assuming channel speeds are normal and not fast.
I hate that persistence attribute on the queue. It causes so much confusion. Its useless. If its so great, where is the queue's default Expiry, and default Format, and default syncpoint, etc etc?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 20, 2009 7:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| I hate that persistence attribute on the queue. It causes so much confusion. Its useless. If its so great, where is the queue's default Expiry, and default Format, and default syncpoint, etc etc? |
Somthing for the "Things in the next version of WMQ" thread if it's not already there.
FWIW I've never used fast channel speed either, for much the reasons you give.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Thu Aug 20, 2009 7:43 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Vitor wrote: |
I've personally seen this. One application team lead told me to my face, "all our messages are persistent because if they weren't important we wouldn't send them".
|
Well they sound like muppets..... but dont tar everyone with the same brush!
| Quote: |
Who are these people? How many developers understand the context of their application never mind the data, and how many write the code according to the specification they're given within time & budget?
|
Cynical?
| WMBDEV1 wrote: |
| I expect this sort of stuff to be checked in system test with defects raised accordingly. |
Ok.... i'm often disappointed on this one but people should doing system test should understand this.
I knew I shouldnt have bitten  |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 20, 2009 7:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WMBDEV1 wrote: |
| Well they sound like muppets..... but dont tar everyone with the same brush! |
Most times people come pre-tarred....
You think?
But you must admit developers don't have the time or space they once did. The modern world of AGILE, time boxing and outsourcing all conspire to turn development into a production line.
| WMBDEV1 wrote: |
| Ok.... i'm often disappointed on this one but people should doing system test should understand this. |
Yes, they should, but system test often focuses on other issues.
| WMBDEV1 wrote: |
| I knew I shouldnt have bitten |
No, but I find your optimism refreshing.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 20, 2009 8:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| WMBDEV1 wrote: |
| Ok.... i'm often disappointed on this one but people should doing system test should understand this. |
Yes, they should, but system test often focuses on other issues. |
And development budget for changes at system test time often doesn't include reworking things at the infrastructure level, just the 'things that are being tested'.
| Vitor wrote: |
| WMBDEV1 wrote: |
| I knew I shouldnt have bitten |
No, but I find your optimism refreshing. |
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 20, 2009 8:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
System (application) tests only demonstrate whether the implementation meets the design, not whether the design meets any reality.
If you want persistent messages, code it in the application. If you want non-persistent messages, code that in the application. If you want whimsical or arbitrary persistence (based on mood or inexperience of sysadmin, for example), pick that third thing.
| Quote: |
| I hate that persistence attribute on the queue. It causes so much confusion. Its useless. If its so great, where is the queue's default Expiry, and default Format, and default syncpoint, etc etc? |
And, thus, my continuous whine about the term default, and the common misconception that there are defaults in MQ. There are initial values from the factory.
Yes, I know that this is a nit, but the queue attributes do not set defaults for lack of care by application coders. PERSISTENCE_AS_Q_DEF is not a default persistence. It is the coders directive that persistence should be taken from the queue definition.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Thu Aug 20, 2009 10:39 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| bruce2359 wrote: |
| Yes, I know that this is a nit, but the queue attributes do not set defaults for lack of care by application coders. PERSISTENCE_AS_Q_DEF is not a default persistence. It is the coders directive that persistence should be taken from the queue definition. |
Developers are not forced to pick Persistence Yes, No or PERSISTENCE_AS_Q_DEF. They can ignore that parameter completely. In that case they default to some value, which happens to be whatever the queue has set. Semantics I suppose.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 20, 2009 10:46 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
Not to disagree in any way... my point is best-practices dictate that application coders must set all those values in the MQMD to meet business requirements, just as they must set the fields in the business data.
Just because there appears to be a default (at the queue or in business data), it is un-best-practice-like to skip some fields and ASSume that the defaults will take care of bad (careless) coding.
_________________
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 |
|
|
| exerk |
| Posted: Thu Aug 20, 2009 1:59 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
| ...I have mine set to normal everywhere so MQ doesn't toss non persistent messages due to network blips. Another MQ Admin said if they cared about their messages, they would make them persistent. I said, no, if they didn't care about their messages they wouldn't have sent them to begin with. They care. And if they sent a non persistent message and MQ gave them a 0 RC on their MQPUT(1), then MQ should not toss it... |
Whereas I take a more brutal approach - if the message is non-persistent, they don't care that much, if at all. My general rule of thumb being that if that message is so unique it cannot in any way be reproduced, make it persistent, but if it can be reproduced, don't. If it gets 'tossed', well ,it's reproducible, and if not, bad decision on their part.
| PeterPotkay wrote: |
| ...I hate that persistence attribute on the queue. It causes so much confusion. Its useless. If its so great, where is the queue's default Expiry, and default Format, and default syncpoint, etc etc? |
Hallelujah brother! Too many times have I heard the misconception voiced that the messages being sent will be going to a 'persistent' queue, so will be persistent when they land.
| Vitor wrote: |
| ...But you must admit developers don't have the time or space they once did. The modern world of AGILE, time boxing and outsourcing all conspire to turn development into a production line... |
Which is why I believe it should be 'standard' practice for application programmers to externalise the decision in a configuration file, for the 'customer' to decide. Programmers should program, business lines should know their requirements, and decide accordingly.
| bruce2359 wrote: |
...System (application) tests only demonstrate whether the implementation meets the design, not whether the design meets any reality.
If you want persistent messages, code it in the application. If you want non-persistent messages, code that in the application. If you want whimsical or arbitrary persistence (based on mood or inexperience of sysadmin, for example), pick that third thing... |
The greatest flexibility can be achieved by the ability of an application to do all three, at the whim of the customer. And of course, it off-loads the responsibility from the MQ admin, notwihstanding that I'll safeguard their messages as far as I possibly can.
| WMBDEV1 wrote: |
| ...Well they sound like muppets... |
Unfair to Kermit et al to tar them with the same brush... 
_________________
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 |
|
|
| hopsala |
| Posted: Sat Aug 22, 2009 5:52 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| a few posts ago, exerk wrote: |
| (Hopsala, you out there?) |
Always.
| exerk wrote: |
| Whereas I take a more brutal approach - if the message is non-persistent, they don't care that much, if at all. My general rule of thumb being that if that message is so unique it cannot in any way be reproduced, make it persistent, but if it can be reproduced, don't. If it gets 'tossed', well ,it's reproducible, and if not, bad decision on their part. |
I'm more in line with Peter here. NPMs quite often mean "online request which user will re-send if problem occurs". In such cases, you don't want to lose messages on minor errors (slight temporary comm glitches), but only on proper malfuncs, such as QM restart. Besides, NPMSPEED is a performance parameter, and my rule of thumb goes "start with worst performance parameter values, tweak only if the need arises". Why not leave NPMs alone? Live and let live, I say.
| exerk wrote: |
| PeterPotkay wrote: |
| ...I hate that persistence attribute on the queue. It causes so much confusion. Its useless. If its so great, where is the queue's default Expiry, and default Format, and default syncpoint, etc etc? |
Hallelujah brother! Too many times have I heard the misconception voiced that the messages being sent will be going to a 'persistent' queue, so will be persistent when they land. |
Look, just because people misunderstand something doesn't mean it's stupid. I think that the DEFPSIST parm is a pretty good idea, especially considering that it let's you decide whether or not to use it. There really one and only one problem with the parameter, which is that IBM chose to label it "persistence" rather than "default persistence" in the MQExplorer interface. Now that's stupid.
To summarize: I hate it too 
| Vitor wrote: |
| ...But you must admit developers don't have the time or space they once did. The modern world of AGILE, time boxing and outsourcing all conspire to turn development into a production line... |
IMHO, it's not that they don't have the time and space, it's that they don't have the ability or the know-how. Programmers are just not up-to-par nowadays, especially in large orgranizations. The designer-developer division had become so extreme, that neither knows what the other is doing. The only proper programmers I've seen work in startup companies, where you have no choice but to learn to do everything by yourself. Last time I was at a large organization, I saw a GOTO statement in a .NET production code. I will never sleep peacefully again.
Show me a good MQ programmer and I'll show you a former adminstrator. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Aug 22, 2009 7:09 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Show me a good MQ programmer and I'll show you a former adminstrator |
.
Show me a good programmer and I'll show you someone from mainframe/iSeries, where there were standards and procedures enforced.
_________________
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 |
|
|
| Vitor |
| Posted: Sat Aug 22, 2009 2:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Quote: |
| Show me a good MQ programmer and I'll show you a former adminstrator |
.
Show me a good programmer and I'll show you someone from mainframe/iSeries, where there were standards and procedures enforced. |
I'd say that's a bit harsh and biased.
I also agree completely!!!!!   
 and proud of it
(Ah, those good old days.....)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Aug 22, 2009 6:15 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
And if I may say so I'd have to .
MF programming really forced you to get your stuff together before you ever ran a single line of code.
My experience with MF coding may be quite old (1990) but I truly must say I learned a lot with it. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Sun Aug 23, 2009 3:20 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
The lot of you!
Give me a *NIX platform anyday
ha ha |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
