| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| message loss |
« View previous topic :: View next topic » |
| Author |
Message
|
| sayleep |
 Posted: Tue Sep 25, 2012 11:08 pm Post subject: message loss |
 |
|
Newbie
Joined: 21 Sep 2012
Posts: 8
|
Could there be a message loss of the default persistence property (DEFPSIST) IS set to YES??
On our server, we have a queue A, which bifurcates and sends messages to two other queues A1 and A2 alternatively. Now A and A1 have DEFPSIST as YES, but in A2's case it is NO.
Could there be a message loss because of the fact that A2 default persistence property is non-persistent?
I have read at a few places that the persistence (or non-persistence) is determined by the message. We can set this property in the message header. If that is the case, then which one takes precedence, the one defined at the queue or that defined on the message header? |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Sep 25, 2012 11:53 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The 'default' persistence of a queue is just a way for lazy developers to avoid explicitly setting message persistence and in no way alters the MQMD setting of an already persistent or non-persistent message. If your application that puts to queue A explicitly sets a message non-persistent for example, that setting will over-ride any setting on the queue. If, however, the application sets persistence as per queue definition, provided the DEFPSIST attribute remains at YES then the messages put to queue A2 will be persistent unless you are using an application to read messages from queue A and put copies of those messages to queue A1 and queue A2 (they'll be unique copies of the original), and that application also relies on the DEFPSIST attribute of the target queue; the problem with relying on the DEFPSIST attribute is that "today's" persistent messages become "tomorrow's" non-persistent messages if the attribute gets changed.
Out of curiosity, just how are you managing the 'bifurcation'?
_________________
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 |
|
|
| Vitor |
| Posted: Wed Sep 26, 2012 4:53 am Post subject: Re: message loss |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sayleep wrote: |
| Could there be a message loss of the default persistence property (DEFPSIST) IS set to YES?? |
Following from this I imagine?
| sayleep wrote: |
| Could there be a message loss because of the fact that A2 default persistence property is non-persistent? |
Yes - if the application is using the queue default setting.
| sayleep wrote: |
| I have read at a few places that the persistence (or non-persistence) is determined by the message. |
It is
| sayleep wrote: |
| We can set this property in the message header. |
No, it's always set in the message header and nowhere else. It's always set by the putting application and nothing else.
| sayleep wrote: |
| If that is the case, then which one takes precedence, the one defined at the queue or that defined on the message header? |
The one defined on the queue has no relevance to the message's persistence. The putting application has the only say in what the persistence of a message is, and has 3 options:
- make the message persistent
- make the message non-persistent
- make the message's persistence whatever the queue's attribute says.
The application cannot abrogate this responsibility.
One more general point. Non-persistent messages are not lost, nor do they go "missing", any more than persistent ones do in a normally operatiing WMQ estate. If it's all working normally, channels, queue managers, all that, messages flow irrespective of their persistence. It's onyl when a failure occurs that non-persistent messages are not certain to survive; depending on the class of failure they may well make it through.
So in the scenario where 1 message went missing one day, and then a few days later another message went missing, and in neither case was there an MQ level problem then the finiger of suspicion still points squarely at the application. You should have noticed a failure, had to fix it and had buckets of messages go missing.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
