| Author |
Message
|
| youn |
 Posted: Wed Jan 28, 2009 12:22 pm Post subject: How recuper persistant message |
 |
|
Newbie
Joined: 21 Jan 2009
Posts: 4
|
Hi,
I want to recuper persistant messages sent to the remote queue to reinject their in the local queue (with no errors).
I would like to know where the messages are saved in the local server and how can I reinject their to the local queue.
thanx
youn |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Jan 28, 2009 12:45 pm Post subject: Re: How recuper persistant message |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| youn wrote: |
I would like to know where the messages are saved in the local server and how can I reinject their to the local queue.
|
Persistent messages are both saved to the relevant queue files and also logged in the queue manager. In the event of failure, the queue manager will automatically recover them from one or both places. You can trust this process. The files are in an IBM-proprietory format and you should not mess with them.
If you want to recover messages which have been read off a queue and deleted, you can't. You either need to take a copy of the message before it's read off, buy Request from Cressida or best of all use transactional control to ensure messages are not deleted before their processing is successful!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| youn |
| Posted: Wed Jan 28, 2009 1:00 pm Post subject: |
|
|
Newbie
Joined: 21 Jan 2009
Posts: 4
|
I know that in event of failure, the queue manager will automatically recover them.
But, in my exemple, this is no failure.
I just want to know if the normal use (with no erreur), the persistant messages are saved, and if is it possible de reinject them. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 28, 2009 1:04 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| No, it is not normal practice to redeliver the same message, regardless of whether the message is persistent or not. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 28, 2009 1:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| youn wrote: |
| I just want to know if the normal use (with no erreur), the persistant messages are saved, and if is it possible de reinject them. |
If there's no error, why would you need to reinject them? 
In any event, persistent messages are deleted once the get is committed.
I don't know if the Cressida product can recover such messages; that's a question for their sales team!
I again ask what your requirement is here, given that the messages have been successfully processed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| youn |
| Posted: Wed Jan 28, 2009 1:19 pm Post subject: |
|
|
Newbie
Joined: 21 Jan 2009
Posts: 4
|
In fact,
we need to change the remote server.
We have a new server and we begin the tests with this server.
To validate the tests, we want to sent the message of the local server to the old and the news remote server to validate the changement.
Fist, I would like to use a ditribution list to send message to multiple queue but I think it's there is too much developpement for a test.
So, I would like to use this method to test the new server.
Do you understand my problem? I'm not expert with MQ.... |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 28, 2009 1:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| youn wrote: |
| To validate the tests, we want to sent the message of the local server to the old and the news remote server to validate the changement. |
So what you need to do is:
1. Make a backup of whatever triggers the local server.
2. Run the process on the local server, sending the messages to the old server.
3. Record the results.
4. Change the WMQ configuration to the new remote server
5. Restore or otherwise re-run the local server, the messages now going to the new server
6. Record the results
7. Compare steps 3 and 6
Of course, a lot depends on what you think is going to go wrong. In your position I'd change the configuration and monitor the new server. If messages are flowing to it it's working, job done!
But that's just me.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Cressida |
| Posted: Thu Jan 29, 2009 8:18 am Post subject: |
|
|
Disciple
Joined: 13 Jul 2007
Posts: 157
|
|
| Back to top |
|
|
|
|
