| Author |
Message
|
| jpcampot |
 Posted: Wed Dec 22, 2004 8:56 am Post subject: Using prefix in messageID |
 |
|
Novice
Joined: 15 Dec 2004
Posts: 10
|
Hi, I am using MQ 5.3 and MQ Classes for Java as my client. I have an application that get requests from one queue and put results to another queue. Several different applications put and gets messages from that queues. I need to identify the messages so that one application only gets the messages that it puts and not the messages put by another application.
I was thinking that every application should insert their messages with a messageId containing some kind of prefix. And then they should get messages that contain that prefix in it`s messageID.
Is this possible?
Thanks in advance |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Dec 22, 2004 9:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Possible (yes) would I recommend it (NO).
Create a generic triage application that can receive the message and dispatch it to its specific handlers depending on whatever criteria you need...
Or create one queue per message type.
Enjoy  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Dec 22, 2004 9:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Please don't share queues between applications.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jpcampot |
| Posted: Wed Dec 22, 2004 9:42 am Post subject: |
|
|
Novice
Joined: 15 Dec 2004
Posts: 10
|
The problem is that the application that does the processing is a legacy application that cannot be touched. It is implemented in C and is running on Linux. Every application that need to calculate some data, must send a message to the queue where the legacy application is listening and wait for the reply on the results queue. I cant have one queue for each client application.
That’s why I was thinking of using a prefix but I don’t know how to get messages from the result queue based on that prefix. |
|
| Back to top |
|
|
| clindsey |
| Posted: Wed Dec 22, 2004 10:21 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
A prefix is not really necessary. WMQ will create a unique messageid when you generate the request message. You just need to save this messageid and use it for matching to messageid or correlationid when you retrieve the reply.
Do you know what the legacy app does with the requester's messageid. Does it return it as the messageid or copy it to the correlationid? You will need to know to determine how to match on your particular request
Charlie |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Dec 22, 2004 10:43 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can still put a filter program between the results queue and each client application.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jpcampot |
| Posted: Wed Dec 22, 2004 11:01 am Post subject: |
|
|
Novice
Joined: 15 Dec 2004
Posts: 10
|
| The legacy application copies the messageid to the correlation id. The reason why I need some kind of prefix is that the thread that gets the results must process all the request that were put by my application. I mean, my application sends a request and doesn’t do anything more. There is a deamon that runs every few minutes that must get all the replies of the messages that were put only by my application. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Dec 22, 2004 11:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Is this daemon already written, and no changes can be made?
Does this daemon put messages to other queues, or just call your application with message data?
How does your original program know that the response has been generated? How does it get the response? What does it do with the response?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 22, 2004 12:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
1) Have one reply to queue per application.
2) Have a default route from the server to the reply to qmgr(intercom. manual)
3) Put the reply to queue and reply to qmgr on the message
4) Send the message
5) Have your application process whatever is in its reply to queue.
Now feel free to match or not by correlation Id.
As you specify the replyto queue on the message, you will not mix the replies from different applications.
Enjoy |
|
| Back to top |
|
|
| jpcampot |
| Posted: Thu Dec 23, 2004 5:41 am Post subject: |
|
|
Novice
Joined: 15 Dec 2004
Posts: 10
|
My original idea was implementing something like it was posted on the topic : Urgent..Sending and Receiving Msg in Group (http://www.mqseries.net/phpBB2/viewtopic.php?t=1683&highlight=groupid) where bduncan suggested something like this:
“If you are simply trying to differentiate between messages destined for application A and B, then you need to do matching when application A and B do their MQGETs. There are only three attributes you can match against: msgId, correlId, or groupId. While any of these can be made to solve your issue, I would recommend using correlId. If your applications are already using correlIds (for request/reply constructs) then you need to append a watermark to your correlIds. If you are not currently using the correlId attribute, then you simply need to set it to some distinguishing value. In other words, if you are using CorrelIds already, some of your messages on the queue might look like:
CorrelId: 365263423544824236APPA
CorrelId: 542356472342342311APPB
CorrelId: 235235423426567321APPA
Where 'APPA' and 'APPB' are watermarks distinguishing between messages destined for application A versus B.
On the other hand, if you aren't using CorrelIds, you can simply set them to:
CorrelId: APPA
CorrelId: APPB
CorrelId: APPA
etc... where each application does an MQGET matching correlID against either 'APPA' or 'APPB'.
There is no need to use the groupId attribute unless you are actually dealing with mulitiple messages that are logically related. And there's no need to massage the msgId attribute since any watermark scheme you come up with might cause msgIds to no longer be unique, plus, you can't depend on the queue manager to automatically generate them for you anymore...”
The problem is that I don’t know how to tell MQ to get messages that contain some watermark I their correlationID. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Dec 23, 2004 6:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
According to this
| jpcampot wrote: |
| Every application that need to calculate some data, must send a message to the queue where the legacy application is listening and wait for the reply on the results queue. |
you have a very basic request/reply scenario. Each application does the following - Creates a request message
- PUTs the message on the request queue, instructing MQ to create a new Message ID
- Saves the new message ID, which is returned from the PUT
- Creates a blank message.
- Populates the Correlation ID of the blank message with the saved Message ID
- Issues an MQGet, instructing MQ to match the correlation ID of the blank message
- processes the reply message
HOWEVER, according to this
| jpcampot wrote: |
| I mean, my application sends a request and doesn’t do anything more. There is a deamon that runs every few minutes that must get all the replies of the messages that were put only by my application. |
You have something OTHER than a standard request/reply scenario. And you haven't explained that otehr scenario very well.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jpcampot |
| Posted: Thu Dec 23, 2004 6:52 am Post subject: |
|
|
Novice
Joined: 15 Dec 2004
Posts: 10
|
I apologise for the confusion, It was my mistake. I will try to explain the situation:
The legacy application gets request from one queue and put the result in another queue. The correlationId of the response is the same as the messageId of the request.
There are plenty of client application that uses this queues. One of them is the one I am trying to implement that consists of two parts:
1)The Servlet that puts the requests to the queue and do nothing else
2)The deamon that get the results from the results every 5 minutes.
The thing is that the deamon must only get the results of the messages put by the servlet and not the ones put by the other applications. I cant use the message id entirely to specify that the message comes from the servlet because I need to store some other information in it. That’s why I thought of using some kind of prefix or watermark inside it.
I hope the situation is clearer now. |
|
| Back to top |
|
|
| clindsey |
| Posted: Thu Dec 23, 2004 6:54 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
| Quote: |
The problem is that I don’t know how to tell MQ to get messages that contain some watermark I their correlationID
|
MessageID and CorrelationID are byte arrays of length 24.
There are numerous ways to populate the bytes of the messageID with your watermark. It is a good idea to completely fill all 24 bytes. In other words pad with spaces as needed. Fill the bytes in the messageId of your request message. Then set the correlationId of your reply messages equal to these 24 bytes. Also on your reply message, you need to set MQGetMessageOptions.matchOptions to MQC.MQMO_MATCH_CORREL_ID
Charlie |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 23, 2004 11:21 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I still believe the easier design would be for each application to specify it's own reply to queue/ reply to qmgr.
If the server app was written in the correct spirit it would then automatically split the messages by application. No more comingling of the responses onto 1 queue.
This means that each application needs to have its response queue defined
The server app qmgr needs to have a default path to the requester qmgr.
You could also just implement the separation for your new app.
The typical request reponse modell is:
a) request being sent to server
b) server processes the request and builds response message
c) server sets correlationID on response message
d) server reads replyto destination from request message
e) server puts the response message to the destination acquired in d
As the queue/qmgr are not defined on the server qmgr you will need an alias for the requester qmgr. This alias will allow default communication to the requester qmgr.
HOW do you determine which queue the server app is putting its response to ?
Enjoy |
|
| Back to top |
|
|
| jpcampot |
| Posted: Fri Dec 24, 2004 4:45 am Post subject: |
|
|
Novice
Joined: 15 Dec 2004
Posts: 10
|
Thanks to your help, I will try to convince the legacy application´s responsible to use one result queue per application using the reply to queue/ reply to qmgr functionalities.
This would be the cleaner and easier solution.
Thanks to everyone |
|
| Back to top |
|
|
|
|
