| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CorrelationID and general processing question |
« View previous topic :: View next topic » |
| Author |
Message
|
| mechilds |
 Posted: Fri Jan 25, 2008 10:45 am Post subject: CorrelationID and general processing question |
 |
|
Newbie
Joined: 25 Jan 2008
Posts: 3
|
Hi,
We are working with a partner who uses MQ. We will be sending and receiving messages using a set of their queues.
I am building a .net service that will be responsible for monitoring and using the queues. We need to store the correlation id in the database (SQL Server 2005)- as there may be some time between request and reply. Sounds like (from researching here) that I don't really want to convert these. My other choice is to store them in a varbinary field - which should let me read it in from the byte array and right back out when I need to do the match on the response messages. Does this sound like a reasonable approach or am I missing something easier?
Second is a general processing question. Initially I had a method that read the queue until it was empty - putting the messages in an array and then handing off that array for processing. However - it occurred to me that if I was in the middle of pulling off a bunch of messages and the server died - that all of the messages that I had pulled off and stored in the array - were now lost. I have since modified my logic to pull off a message and immediately send it off for processing before pulling the next one. Again - does this seem to be a reasonable approach?
Thanks,
Matt |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Jan 25, 2008 1:43 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Best practices say to process each message individually and fully, before getting the next one.
Best practices also say to process the queue until it's empty.
How long do you expect to have between request and reply? It's not clear that you should be sending another request before you've received a reply to the first one... Or that if you should be, that it's really a request/reply pattern... Request/reply is supposed to be "pseudo-synchronous". If there's a long delay expected between request and reply, then you really have two separate, but correlated, one-way messaging patterns.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mechilds |
| Posted: Mon Jan 28, 2008 11:15 am Post subject: |
|
|
Newbie
Joined: 25 Jan 2008
Posts: 3
|
Thanks Jeff,
I am definitely reading the queue until it is empty (reason code 2033).
Based on our requirements, we do need to continue to send through the messages prior receiving the responses. Each of these is an individual unrelated transaction - so I basically send a bunch of requests and wait for the responses - and we have been told by our partner that they may not be immediate.
One other thing. We have been asked for redundancy. On our side we have two app servers - each of which will be running a Windows service that is essentially a queue poller. My concern is what will happen if both pollers try to open the queue at the same time - can they both read from the queue - or is it essentially locked by the first process that gets there?
Thanks,
Matt |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 28, 2008 11:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Best practices is to have each requester use a separate queue for it's replies...
There's a lot of discussion around this.
In general it's possible for two apps to read messages from the same queue, and in general they don't conflict, and they won't be given the SAME message at the same time.
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
