| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Using MQBROWSE with message sequencing |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Fri Jul 16, 2010 7:10 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Did I miss something? |
Here's what I've understood from the OP:
1) Some number (unknown) of messages exist in a queue.
2) The messages arrived from a queue manager across a SDR/RCVR channel.
3) One or more concurrent or serial applications may have put them there.
4) One or more messages may belong to a single transaction.
5) Zero, one or more of the messages that were supposed to arrive in the queue may or may not have actually arrived.
6) I want to ensure that all messages comprising a transaction are consumed in the exact same order as the sending application put them (to the xmit queue).
7) And I want to accomplish this without changing anything, especially application code or object definitions.
8 ) And there is nothing in the message that identifies a message producer, message order, or number of messages needed to complete the transaction.
Now, did I miss something?
_________________
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 |
|
 |
| sumit |
| Posted: Fri Jul 16, 2010 8:37 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
Your post was much detailed 
| bruce2359 wrote: |
| 8 ) And there is nothing in the message that identifies a message producer, message order, or number of messages needed to complete the transaction. |
What I have seen in similar situation is, application do have some thing at the data level which specifies it's sequence and batch information instead of anything in mqmd. In other words, it's a batch for the app and may not be for MQ.
Let's wait and see if OP has implemented any solution and has got anything to cheer for.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Jul 18, 2010 3:54 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
My 2c,
MQ is primarily designed as a fast and reliable asynchronous messaging facility. Therefore it does not handle message affinity and sequencing very well. Message Groups may seem to help these requirements but it requires specific application coding.
Applications should not be designed to introduce affinity or sequencing into MQ messaging. In the case described, a solution is to get all incoming messages and temporarily store them in a database. A separate process performs data marshalling to reassemble sets of messages into the correct order and pass them on. This process should also have the intelligence to handles missing messages and wait for incomplete sets.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jul 18, 2010 4:48 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The "spearate process" sounds like a workable solution; but sounds like application coding to me.
What if this separate process finds itself missing a message? What then? How does it get the message originator to (re)create the missing message - without application changes?
_________________
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 |
|
|
| fjb_saper |
| Posted: Sun Jul 18, 2010 8:44 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bruce2359 wrote: |
The "spearate process" sounds like a workable solution; but sounds like application coding to me.
What if this separate process finds itself missing a message? What then? How does it get the message originator to (re)create the missing message - without application changes? |
This is why you need to take a small performance hit and deal with persistent messages. You have once only delivery but the timing is dependent on the different hops and usage of DLQ's.
This way you should not have any sets missing any member after all the potential errors and DLQ's have been worked...
A slight change in the app will need to be done to check that the last message in set arrived and the set contains the advertised # of messages as per last message in set. Then process the set. Does not matter whether the set / batch has 1 or 10,000,000 messages...
Of course it would be advantageous to be able to request any specific message again... but that means you need a DB at each end of the transmission, and application logic to identify and resend a message... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 19, 2010 5:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
This is a discussion of a well-behaved request/reply application.
Well-behaved means that both requesting- and replying-applications need to be sensitive to loss or duplication of messages - not by MQ, but by the applications themselves.
The requesting app needs to keep track (DB) of request messages it sent, and replies it received. It needs to recognize (and deal with) missing or duplicated replies.
The replying app needs to keep track (DB) of request messages it received, and replies it sent back. It needs to recognize (and deal with) duplicate AND mising requests.
I specifically used the term "missing" and not "lost," since MQ doesn't lose messages. One of a message-affinity set might end up on a DLQ. Missing here means that the application has not conformed to the WMQ spec for message affinity (order of retrieval) as documented in the APR and APG.
_________________
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: Mon Jul 19, 2010 3:51 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bruce2359 wrote: |
| What if this separate process finds itself missing a message? What then? How does it get the message originator to (re)create the missing message - without application changes? |
A possibility is to move the incomplete set of messages to a separate DB table for later assessment, manual or automatic. This is akin to MQ's DLQ concept.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 20, 2010 6:12 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
There are many ways to skin this cat; but each and every one requires application coding and/or DBs of one kind or another - not the solution that the OP was looking for.
(apologies to cat-lovers.)
_________________
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
|
|
|
|
