| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Using NPMCLASS(HIGH) for saving NP messages |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Sun Feb 01, 2015 12:16 pm Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
In one of my tests, I took a long lunch after putting messages, but before killing the qmgr. I presume that while I was away, buffer management software felt the moral imperative to write the contents of the buffesr to the file-system.
_________________
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 |
|
 |
| Andyh |
| Posted: Sun Feb 01, 2015 1:09 pm Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
NP messages in queue buffers may not be written to disk, even in a lazy fashion, for a fairly indeterminate, possibly prolonged, time. After a lazy write is accepted by the kernel the data is in kernel buffers and killing the process that scheduled the write shouldn't prevent the write from eventually hitting disk. Hence in the case mentioned by Tim it seems most likely that the data never made it out of the queue manager owned queue buffers.
An OS level failure on the other hand would result in the potential loss of lazy writes. |
|
| Back to top |
|
|
| tczielke |
| Posted: Sun Feb 01, 2015 1:39 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| Andyh wrote: |
NP messages in queue buffers may not be written to disk, even in a lazy fashion, for a fairly indeterminate, possibly prolonged, time. After a lazy write is accepted by the kernel the data is in kernel buffers and killing the process that scheduled the write shouldn't prevent the write from eventually hitting disk. Hence in the case mentioned by Tim it seems most likely that the data never made it out of the queue manager owned queue buffers.
An OS level failure on the other hand would result in the potential loss of lazy writes. |
Good point. I did have a misconception there. Thanks for the clarification. So more than likely, I was stopping the MQ queue manager process before it could initiate the lazy write in the first place. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Feb 01, 2015 1:50 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
... and by way of summary, I'm NOT specifically opposed to either non-persistent messages or NPMCLASS(HIGH), or both of 'em. The OP asked if they are recommended.
I'm averse to risk, especially to the needless kind of risk. Most of my clients are risk-averse, as well. The risk of loss, however slight, must be weighed against the cost of loss - in the usual cost-benefit analysis.
For the risk-averse among us, I'd agree that NPMCLASS(HIGH) is better than NPMCLASS(NORMAL). A well-designed app, one that is sensitive to loss or duplication of messages, is better than a fire-and-forget app. Similarly, persistent messages are probably a better choice for resiliency, until you start to discuss logs, log space, and logging delays.
In the triad of cost/quality/time, you/we only get to pick two of the three.
So, in answer to the OP: it depends.
_________________
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 |
|
|
| orman |
| Posted: Mon Feb 02, 2015 9:01 am Post subject: |
|
|
Apprentice
Joined: 08 Aug 2013
Posts: 40
|
Hi
Well, I realy enjoyed to see that the discussion was fruitful and most minds discussed.
bruce2359 - Thanks a lot for the summary, think it exhaustive and summarizes the the open issues in.
Of course, the decision to use the NPM feature depends on the situation and all kinds of other parameters.
Brainstorming helped me - and the decision firstly changing all the queues into a NPMCLASS(HIGH) in the integration environment and we shall see that there is no unnecessary problems - we will move around Production environment
Thank you all guys 
Last edited by orman on Mon Feb 02, 2015 9:32 am; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 02, 2015 9:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| orman wrote: |
Brainstorming helped me - and the decision my immediate proximity is changing all the lines into a NPMCLASS(HIGH) environment integration and we shall see that there is no unnecessary problems - move around Producation environment
Thank you all guys |
I'd strongly recommend that you get the blessings of management and auditors BEFORE you make such a change. Make sure that you explain exactly what NPMCLASS(HIGH) offers, and more importantly, what it does not. I'd include a printed copy of IBM's documentation of NPMCLASS.
_________________
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 |
|
|
| tczielke |
| Posted: Mon Feb 02, 2015 9:19 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| orman - Did you follow up on exerk's suggestion to check if the application is specifying default persistence, and then just change the DEFPSIST on the queue to YES? strmqtrc tracing or the Application Activity Trace (at 7.1 and higher) will tell you what the application is setting for persistence. |
|
| Back to top |
|
|
| orman |
| Posted: Mon Feb 02, 2015 9:39 am Post subject: |
|
|
Apprentice
Joined: 08 Aug 2013
Posts: 40
|
| bruce2359 wrote: |
I'd strongly recommend that you get the blessings of management and auditors BEFORE you make such a change. Make sure that you explain exactly what NPMCLASS(HIGH) offers, and more importantly, what it does not. I'd include a printed copy of IBM's documentation of NPMCLASS. |
Thanks for advises, I will do that .
| tczielke wrote: |
| orman - Did you follow up on exerk's suggestion to check if the application is specifying default persistence, and then just change the DEFPSIST on the queue to YES? strmqtrc tracing or the Application Activity Trace (at 7.1 and higher) will tell you what the application is setting for persistence. |
Yea, I will do it
But as I know today the MQ messages persistence configure is not known and that is why important message set to non-persistent
The next step is to change the DEFPSIST on the queue to YES as it was written here
Thanks again,
Or |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Feb 02, 2015 4:34 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| orman wrote: |
| The next step is to change the DEFPSIST on the queue to YES as it was written here |
This is a dynamic change. If the message producing app using the default MDMD Peristence = PERSISTENCE_AS_Q_DEF, the next message that it puts should be persistent.
My take on NPMCLASS(HIGH) is that it is just another Quality Of Service for MQ messages. Application designers should fully understand MQ QoS and use it appropriately.
The bottom line is that if you want MQ provide assured delivery, use Persistent messages.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 02, 2015 5:21 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Another thing to consider: it is the first object the producing application mqopens that sets persistence_as_q_def. Does the app open a QRemote def? A QAlias? In these cases it is NOT the resolved object that sets persistence.
_________________
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 |
|
|
| orman |
| Posted: Tue Feb 03, 2015 1:12 pm Post subject: |
|
|
Apprentice
Joined: 08 Aug 2013
Posts: 40
|
| bruce2359 wrote: |
| Another thing to consider: it is the first object the producing application mqopens that sets persistence_as_q_def. Does the app open a QRemote def? A QAlias? In these cases it is NOT the resolved object that sets persistence. |
I think the most of them use to put the message to a remote queue |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 03, 2015 1:19 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| orman wrote: |
| bruce2359 wrote: |
| Another thing to consider: it is the first object the producing application mqopens that sets persistence_as_q_def. Does the app open a QRemote def? A QAlias? In these cases it is NOT the resolved object that sets persistence. |
I think the most of them use to put the message to a remote queue |
Then the QRemote definition(s) that the app opens should be modified to DEFPSIST(YES).
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
