| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Precedence of JMS Listeners |
« View previous topic :: View next topic » |
| Author |
Message
|
| yalmasri |
 Posted: Tue Oct 16, 2012 4:57 am Post subject: Precedence of JMS Listeners |
 |
|
Centurion
Joined: 18 Jun 2008
Posts: 110
|
| I have two listeners on two different machines. When a sender on a third one sends to the clustered queue on which those listeners are waiting, it's absolutely random on which will pick the first message. What I want is to guarantee that whichever connects first will get the first message first. Is there such thing? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Oct 16, 2012 5:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| What you want is to rewrite your application to have no notion of "the first" message. |
|
| Back to top |
|
|
| yalmasri |
| Posted: Tue Oct 16, 2012 5:08 am Post subject: |
|
|
Centurion
Joined: 18 Jun 2008
Posts: 110
|
| Sorry Jeff, but I'm not getting this |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 16, 2012 5:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I mean two things: - There's no good reason for doing what you want to do, and what you want to do is a bad idea
- it's almost certainly not possible in the way you have described
The notion of "the first message" is a very loose term, anyway.
Do you really mean "the first message a producer sends after it connects"? Well, what if it connects, sends a few messages, and then gets temporarily disconnected. The next message it sends is now "the first message" again, even though there could have been a very very small interval (nanoseconds) between one message and the next.
If you do not abandon this notion, and reexamine the requirement that is driving it, such that you properly treat each consumer as "the same" regardless of connection time, you will end up with a very complicated unsupportable solution. |
|
| Back to top |
|
|
| yalmasri |
| Posted: Tue Oct 16, 2012 6:15 am Post subject: |
|
|
Centurion
Joined: 18 Jun 2008
Posts: 110
|
| mqjeff wrote: |
- There's no good reason for doing what you want to do, and what you want to do is a bad idea
|
You're jumping to conclusions.
I'm trying to leverage our clustered MQ infrastructure to create a distributed cache. When a message is published, all my subscriber applications are picking the message and storing it in a memory map for later use. When one instance goes down, it loses that map and will have to announce upon restarting that it needs a fresh copy by sending over a clustered queue to all members. Now only one will pick this announcement, and will return the data back. If that picker happened to be likewise recovering after a restart, then it's suffering from the same issue and will have only empty map to return. This situation is the driver behind the need to have the older connector respond to such request.
| mqjeff wrote: |
Do you really mean "the first message a producer sends after it connects"? Well, what if it connects, sends a few messages, and then gets temporarily disconnected. The next message it sends is now "the first message" again, even though there could have been a very very small interval (nanoseconds) between one message and the next.
|
Not sure what scenario you built in your mind, but as per the description above, any disconnection will lead into a reconnection, and this requirement will apply again irrespectively. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 16, 2012 6:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Edit: sorry, backwards solution.
You'll need to use pub/sub to ensure that all members get the cache update request. There's no viable way to handle it, otherwise. |
|
| 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
|
|
|
|
