| Author |
Message
|
| Jeffrey P |
 Posted: Fri Oct 10, 2003 6:07 am Post subject: Dont flush my queue |
 |
|
Novice
Joined: 27 Aug 2003
Posts: 20
|
I've noticed that when restarting the MQSeries service that the queue gets flushed. I'm worried about this because servers do have to re-booted at times and if the queue empties each time, well, thats bad. Im thinking there has to be a setting somewhere but not sure. Any help would be appreciated. Thanks.
_________________
Jeff |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Oct 10, 2003 6:13 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The queue will only get "flushed" at server restart if all the messages in it are non persistant.
Note that it is possible to have non-persistant messages in a queue that is marked 'persistant', and vice-versa. The queue property is merely the 'default' value - overriden by whatever the application decides.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Jeffrey P |
| Posted: Fri Oct 10, 2003 6:26 am Post subject: |
|
|
Novice
Joined: 27 Aug 2003
Posts: 20
|
So this is just an option to set in the open options when creating the MQQueue?
_________________
Jeff |
|
| Back to top |
|
|
| Jeffrey P |
| Posted: Fri Oct 10, 2003 6:41 am Post subject: |
|
|
Novice
Joined: 27 Aug 2003
Posts: 20
|
Sorry to keep bugging.....I just keep finding new stuff to ask after the fact. If it is an open option on the queue, I couldnt find it in the options listed in the documentation. Also, if a queue is set to be persistant, will the messages be removed when they are read? Thanks again.
_________________
Jeff |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 10, 2003 6:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No. Not really. In JMS it's a property of the Queue object.
| Code: |
| myQ.setPersistance(DeliveryMode.PERSISTENT); |
In plain java it's a property of the MQMessage object
| Code: |
| myMsg.persistance = MQC.MQPER_PERSISTENT |
If you aren't setting it specifically in your applications right now, you can probably get away with it by changing your queue definitions (in MQSeries, not your app). This is because your apps are putting messages using the queue defaults.
The persistence of a message is independant of whether you do a destructive get from the queue or not. So yes, unless you open the queue for browsing, your persistant messages will get removed from the queue during reads.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Jeffrey P |
| Posted: Fri Oct 10, 2003 6:59 am Post subject: |
|
|
Novice
Joined: 27 Aug 2003
Posts: 20
|
Sounds great.....another question though. My application puts a message on the queue which I can set that property on. If another application puts a response on the queue, I take it that I can also set that option on the response message, thus averting the loss of the response if while waiting for it there are problems with the service or server. Is that correct? Thanks.
_________________
Jeff |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 10, 2003 7:24 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes.
Well. Yes and No.
It's up to the application that actually puts the message on the queue to set this property (either to what it wants or by ignoring it which sets it to the queue default value).
So, yes, the application creating the response can set the persistance of the response to ensure that the response doesn't get deleted if the queue manager gets restarted somehow.
But no, the application receiving the response can't change the persistance of the response message - unless it turns around and puts the response back on the queue (which doesn't make a lot of sense).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Jeffrey P |
| Posted: Fri Oct 10, 2003 7:31 am Post subject: |
|
|
Novice
Joined: 27 Aug 2003
Posts: 20
|
Thanks for the help. I appreciate it.
_________________
Jeff |
|
| Back to top |
|
|
|
|
