| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Manually retrieve and repost persistent messages |
« View previous topic :: View next topic » |
| Author |
Message
|
| chirayu |
 Posted: Wed May 11, 2011 7:43 am Post subject: |
 |
|
Apprentice
Joined: 04 May 2011
Posts: 30
|
does CSQUTIL work on Linux ??? or any other utility which works like CSQUTIL on Linux
I am searching on google parallely but if anyone has already done the RND maybe can pitch in.
Still thanks to everyone for contributing to the post!
Regards,
Chirayu |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed May 11, 2011 8:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
NO, CSQUTIL DOES NOT WORK ON LINUX.
NO, YOU CAN NOT DO ANYTHING TO READ MESSAGES FROM A STOPPED QUEUE MANAGER ON LINUX.
Full stop. Nothing you can do.
Except maybe buy ReQuest from Cressida. But that won't work in an automated situation, afaik.
YOU NEED TO CONFIGURE HA OR MI QUEUE MANAGERS. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 11, 2011 9:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
It is possible that if a qmgr terminates abnormally (think pulling the power cord from the server), any messages that were put to buffers might not have been written to disk.
Your scenario presumes that the disk and filesystem continue to function after the qmgr dies. If the disk fails, or the filesystem is corrupted, messages will likely be lost.
If continuous operation and high-availability are absolute and mandatory business requirements, your organization needs to look at WMQ in a z/OS Parallel Sysplex environment. Read this http://www.redbooks.ibm.com/abstracts/SG246864.html
_________________
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 |
|
|
| gbaddeley |
| Posted: Wed May 11, 2011 4:33 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| chirayu wrote: |
But unfortunately before the message was read by system A, QM1 went down and the msg 3 (Order Packed) is now stuck in QM1
Now to avoid outage I will start QM2; QM2 is started and XYZ will send msg 4 i.e. Order Dispatched.
But now system A is confused that before "Order Packed" msg it received "Order Dispatched".
Hence to avoid this I want that before QM2 starts processing any other msgs from XYZ I want that the msg 3 which is stuck in QM1 to be manually removed from QM1 (which is down) and posted on QM2 first before I start the traffic from XYZ to QM2.
This will help in maintaining the sequence of messages. |
As already stated, it is not possible to get the "marooned" messages out of QM1 when it is down.
The app must be designed to cope with situations of out of sequence or missing messages. A suggestion is to marshall the messages into an "incomplete order" table, assuming each order has a unique order number that can be used as a key. As the "missing" messages arrive they are added to the "incomplete order" table, and when a suitable sequence has been established, they can be processed in that order.
The app should be doing this anyway, because MQ does not guarantee the order of messages.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 11, 2011 5:50 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
Or, viewed another way, a single message could have five segments (mq segments or non-mq segments), with a segment reserved for each phase/step:
1. Order Placed
2. Order Created
3. Order Packed
4. Order Dispatched
Initially, the message would only have data indicating that the order was placed - 1. Then, as the order is created, the 2nd segment could be populated; then 3; then 4, and so on.
In this concept, the related, accumulated information is sent.
gbaddeley (prior post) is referring to so-called well-behaved applications. You might want to search this forum for 'well-behaved'.
WMQ's assured delivery paradigm means that WMQ will not lose or duplicate messages. This does not prevent applications from doing so.
In a well-behaved application design, both requesting and replying applications are coded to keep track (link in a DB), and to tolerate loss/duplication requests and replies.
Thus, requesting the application needs to keep track of request messages sent, and replies received. The replying application needs to keep track of request messages received, and replies returned.
The requesting app should re-send request messages for which replies were not returned. The replying app should not accept duplicate or missing requests (if sequencing is required).
I repeat, as I often do, that mq is a pipe through which messages flow. Mq is not responsible in any way for misbehaving applications that duplicate or lose messages.
_________________
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 |
|
|
| gbaddeley |
| Posted: Thu May 12, 2011 3:55 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| chirayu wrote: |
...But unfortunately before the message was read by system A, QM1 went down and the msg 3 (Order Packed) is now stuck in QM1
Now to avoid outage I will start QM2; QM2 is started and XYZ will send msg 4 i.e. Order Dispatched.
But now system A is confused that before "Order Packed" msg it received "Order Dispatched".
Hence to avoid this I want that before QM2 starts processing any other msgs from XYZ I want that the msg 3 which is stuck in QM1 to be manually removed from QM1 (which is down) and posted on QM2 first before I start the traffic from XYZ to QM2.... |
Hey Chirayu, we understand what you are saying! Please accept that msg 3 cannot be retrieved while QM1 is down, and move on to an app design that can cope with this situation.
Maybe you need a capability to resend messages, but this may result in duplicate messages eventually being processed.
You may also consider completely redesigning the MQ topology to use HA, Multi Instance QueueManagers, MQ Clusters etc so that this scenario is less likely to occur.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 12, 2011 4:31 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
Not sure whether you are an MQ admin or an application developer.
In either case, the application design, as you've described it, cannot tolerate a missing message and a message out of sequence. This is not a good design, although it is by far not the worst.
A message in a queue on a qmgr that is not currently running is stranded until the qmgr is next restarted.
And, it is not a WMQ problem. The same scenario would be a problem for a DB application, where the dbms was down, or a row representing a phase of a transaction was missing or out of sequence.
IBM documentation specifies that the WMQ product assures (not guarantees) message delivery. That assurance presumes that the qmgr is running, that channels between qmgrs can transmit, that the destination queue and queue manager exist, and so on. There are prerequisites that must be met in order for a message to be created and consumed.
We are sympathetic to your plight. Sysadmins are often tasked to fix WMQ to accommodate for badly designed and coded applications.
_________________
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
|
|
|
|
