| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Msg grouping with JMS pub/sub |
« View previous topic :: View next topic » |
| Author |
Message
|
| JohnRodey |
 Posted: Mon Apr 28, 2008 8:40 am Post subject: Msg grouping with JMS pub/sub |
 |
|
Centurion
Joined: 13 Apr 2005
Posts: 103
|
Running v6.0 on Linux.
I am trying to preserve the order that messages get distributed to subscribers by using grouping. I need every message delivered to my system to be broadcast back out in the exact same order across all topics. This includes multiple publishers. So if Pub1 sends MsgA to Topic1, then Pub2 sends MsgB to Topic2, they must be received in that order.
My questions are as follows:
1) Can MQ Pub/Sub JMS even work with message grouping? I read the following in the Pub/Sub manual for 6.0.
| Quote: |
| Group messages are not supported by WebSphere MQ Publish/Subscribe. If a group message is sent to the broker, it does not cause an error, but the group message flags in the message descriptor are not forwarded by the broker. |
2) If that's possible, how do I make the queue manager assign the group sequence number instead of my application? I want every publisher to increment the count of the sequence number indefinitely, so that order will be preserved across all publishers.
3) Also my subscribers will each listen for a different subset of those messages. So, for example, one subscriber may only get messages 1, 4, 8, etc... of the sequence. Is that functionality ok? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Apr 28, 2008 8:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Wow, you're in for a world of hurt.
JMS doesn't support message grouping, as far as I know.
Pub/Sub doesn't support message affinity - particularly across topics in general.
It doesn't make any sense what you are trying to do - to have an enterprise wide global sequence number for your entire messaging infrastructure.
It's also not clear what kind of practical value this adds over simply using a timestamp.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JohnRodey |
| Posted: Mon Apr 28, 2008 8:55 am Post subject: |
|
|
Centurion
Joined: 13 Apr 2005
Posts: 103
|
| Quote: |
| It's also not clear what kind of practical value this adds over simply using a timestamp. |
How would simply using a timestamp help us. It may be the case that one topic is backed up. When receiving one message how would we know that previous messages have all been received? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Apr 28, 2008 9:01 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| JohnRodey wrote: |
| Quote: |
| It's also not clear what kind of practical value this adds over simply using a timestamp. |
How would simply using a timestamp help us. It may be the case that one topic is backed up. When receiving one message how would we know that previous messages have all been received? |
It means you need to check the timestamp of the message that you are receiving against the last timestamp in the DB before acting on it. (discard older messages that are received late...) to alleviate message affinity...Anyways you need to redesign... Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 28, 2008 9:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I really wonder how it is fundamentally different to have messages produced with a globally incrementing counter, versus being produced with a timestamp (which is, after all, a globally incrementing counter...  ).
In either case, if a given topic is backed up, your consumer won't know that until it tries to process "the next" message, and it won't know it without some idea of "the previous" message.
The difference between a message that shows up with counter 8 after a message with counter 12 has been processed, and a message that shows up with a 12:00 pm timestamp after a message with a 5:00 pm timestamp has been processed... is not at all apparent to me.
But the code for the second is a lot easier to write and maintain than the code for the first. 
Message affinity is bad. Message affinity across multiple applications is worse. Message affinity across the enterprise is ... a very complicated problem that requires a lot of analysis, a lot of very in depth design, and a very high degree of governance across several disciplines and through the entire design/implement/test/monitor process.
It's not clear why you are trying to use pub/sub here, when in particular pub/sub means that many consumers will get the same messages. Pub/Sub is a one-to-many scenario. It doesn't make sense for messages on a given topic to be delayed until "all previous messages across all topics" are processed by at least one consumer.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JohnRodey |
| Posted: Mon Apr 28, 2008 11:14 am Post subject: |
|
|
Centurion
Joined: 13 Apr 2005
Posts: 103
|
I see what you are saying but I think your understanding of our problem is a little more complicated than our actual problem. A lot of our functionality that we depend on was given to us by using a non-JMS approach initially. We are trying to find a JMS solution for the time being without causing rearchitecture. But let's not get too much into that...
The reason why we don't want timestamps is because we would have to manage a solution to make sure things are not got out of order. We are looking for a totally vendor implemented way of providing this. Which some vendors, believe it or not, do.
So far looks like grouping won't work for me here. Thanks for your help. |
|
| 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
|
|
|
|
