| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| can I return a message to the input queue (after sync poin)? |
« View previous topic :: View next topic » |
| Author |
Message
|
| eddie |
 Posted: Fri Oct 17, 2003 12:39 pm Post subject: can I return a message to the input queue (after sync poin)? |
 |
|
Novice
Joined: 03 Jun 2002
Posts: 13
Location: Philadelphia
|
Hi all,
I have a multi-threaded java client (i.e. using the java client API code) that reads messages from a queue, processes them, and sends a response.
There is a receiver thread that connects and reads messages from the input queue. I've been performing the get (infinite wait) under syncpoint and calling commit as soon as I get the message (this was a work around to cater for the case if my program is killed and then restarted -- messages could otherwise get lost because of an mq agent hanging around from the program that was terminated).
Anyway, the receiver thread farms off the messages that were read to worker threads that go away and process the request. When processing is complete, the worker threads connect to the queue manager themselves and post a response on an output queue (setting the correlation_id to match the message_id of the request that was just processed).
I now want to cater for the case where the back-end system (that the worker threads use to process requests) becomes unavailable. Right now, if this happened, my program would simply respond to the operation request with an appropriate erorr message and the other system would have to look at the error and decide whether they want to try the operation again. I was wondering if there is an easy way for my program to return the input message to the input queue if it realises that the back end system has temporarily gone down. Any ideas??? I know, in many ways, that is the whole point of using the commit... but in my program (as is) the worker threads do not have the same reference to the Queue Manager object for them to be able to commit the transaction.
Thank you in advance for any suggestions.
Eddie |
|
| Back to top |
|
 |
| bduncan |
| Posted: Fri Oct 17, 2003 4:07 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Well, I would really think about re-architecting your system, because as it is, you are basically defeating all the advantages syncpoint provides.
I've never had a problem with MQ thinking the application was still running after it had died. With auto-rollback turned on, the messages always get put back on the queue in a timely manner.
However, if you must stick with the current architecture, then why not just have the worker threads put the message back on the original queue? As long as you put it with the exact same MQMD structure when you got the message, you'll effectively be putting the same message back on the queue.
Of course, if your worker thread dies, then in your current architecture you completely lose the message right?
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| eddie |
| Posted: Mon Oct 20, 2003 9:08 am Post subject: |
|
|
Novice
Joined: 03 Jun 2002
Posts: 13
Location: Philadelphia
|
Thanks for the reply.
I'll have to check into this 'auto rollback' feature... all I know is that during testing I found that if I killed the client program, it would completely miss the first message (or perhaps even more messages) that were put on the queue while the program was down.
As far as putting messages back on the queue... here is the scenario I have...
Messages come from an AS400 application and are put on a 'remote' queue defined on an AS400 Queue Manager. The AS400 Queue Manager passes the message on to a Unix Queue Manager (residing on the machine that I use the Java client classes to connect to).
To put the message back on the queue... do I
1) Try to put it on the 'local' queue (on the Unix Queue Manager) (the queue that I am usually only reading from). I'm not sure that the system will let me write a message to that queue.
or
2) Try to connect to the remote queue manager (the AS400 Queue Manager) and try and put the message on their outbound queue (their remote queue definition). Presumably this will require a Java Server Connection channel to be defined on that Queue Manager so that my Java client can connect to it -- is that right? Or do I have to persuade the MQSeries administrator to 'cluster' the queue managers?
Thanks for your help.
Eddie
P.S. You are right that with the current setup, if a worker thread went down, it would lose the message. It is expected for this to be a very slim occurence, and acceptable because we designed the AS400 application to notice if it doesn't receive a response message to any of it's messages. The AS400 application does have an inteface to be able to resend the orinial message if faced with this minority case. Although it may not be an ideal scenario, it was felt that it was one that we could live with (at least for the time being). What I'm looking for now though, is a way for my program to return the message to the queue in the case where my client is available but some of the other back end services are temporarily unavailable -- I'd rather return the message to the queue and try it again a bit later than simply report an error with a back-end server. |
|
| 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
|
|
|
|
