| Author |
Message
|
| queuetip |
 Posted: Tue Jun 24, 2008 5:08 pm Post subject: Guaranteed Delivery Not A Fit For Pub & Sub Model? |
 |
|
Acolyte
Joined: 03 Feb 2005
Posts: 67
|
Hello,
Long-time WMQ developer/administrator researching WMQ capabilities for implementing a pub & sub solution for our application events. These events need to be guarateed delivered to all durable and non-durable subscribers once and only once.
I attended a seminar on WMQ V7 recently and learned WMQ radically changed it's pub & sub model - making the interface more JMS-like among other things.
However, I was told that P2P was actually a better solution than pub & sub when guaranteed delivery of events is required. I had trouble understanding the explaination of the scenario "how do you know who's last so that you can delete the event"? Could someone please explain this to me?
It is my understanding that when an event is published to a topic, the event is placed on a persistent data store (assume it's a queue), acknowledgement is sent to the producer and THEN WMQ will deliver the message to all the consuming, subscribed clients. If the client was not active, the message would be stored until the client came online and started a session to receive the events. I am assuming WMQ would keep track of which client received which events. So I don't see how P2P would help?
Looking for a little insight on when to use one model over the other in V7. I appreciate your response!
Thank you.  |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Jun 25, 2008 5:50 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20700
Location: LI,NY
|
The answer here is really it depends.
Looking at non durable subscribers and interested ONLY in the latest status (typical exemple is stock quotes) a retained publication would do the trick.
However for a durable subscription you need to understand that message affinity is never an option and if it exists you need to handle it on the receiving end. If you are likely to be the only subscriber a P2P model might be more adequate.
The advantage of the P2P model is speed. Publish and Subscribe operations on the part of the broker take time that is not needed in the P2P model.
(nothing comes for free)... The other advantage is less failure points. You need to send a request message to be notified when the publication fails, the same to be notified if your subscription was successful etc...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| queuetip |
| Posted: Wed Jun 25, 2008 11:23 am Post subject: |
|
|
Acolyte
Joined: 03 Feb 2005
Posts: 67
|
Thanks for your prompt response...
| Quote: |
However for a durable subscription you need to understand that message affinity is never an option and if it exists you need to handle it on the receiving end. If you are likely to be the only subscriber a P2P model might be more adequate.
|
Are you saying that behind the scenes, MQS internally does not remember who it delivered the messages to? For inactive durable subscriptions, I think it would have to remember. This is why I don't understand why pub and sub isn't recommended for guaranteed delivery.
And I understand message affinity is not an option; but I also would think if MQS pub sub ran out of space then it would simply reject any new publications. This another reason why I don't understand why pub and sub isn't recommended for guaranteed delivery.
BTW - all of the above is for MQS V7. We do have many subscribers and we deliver "near real time" so timing isn't a huge concern. Maybe I just need to understand how MQS does things under the covers to realize why pub and sub should not be used for guarateed delivery?
| Quote: |
| Looking at non durable subscribers and interested ONLY in the latest status (typical exemple is stock quotes) a retained publication would do the trick. |
Glad you brought this one up. We will eventually have stateful events like this. Does MQSeries V7 handle this differently than other events internally?
Thanks again! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jun 25, 2008 11:59 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Suppose you have three consumers for a publication.
Neither the publisher nor the "broker" will know when any of those consumers will GET the publication message. None of the consumers will know whether any other consumer has retrieved the message or not.
Who knows when all three consumers have processed the publication? Who knows if all three publication messages were delivered? Who knows if the broker failed after it accepted the publication but before it completed sending all three publication messages?
This is what I interpret the scenario to mean.
The simple fact is that MQ messages are as reliable or unreliable as you configure them to be. Whether you distribute them using pub/sub or not doesn't make a big difference here. What changes is how much information the sending application has about a message. But if one considers "the broker" to be "an intermediary MQ process", the picture is still the same. The sending application doesn't know anything about "the next process downstream", and it doesn't know if it succeeds or fails.
Depending on who SAID that "P2P was actually a better solution than pub & sub when guaranteed delivery of events is required.", they may have meant something much more subtle than you're thinking, or they may have meant something significantly more "guaranteed" than your requirements actually specify.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| queuetip |
| Posted: Wed Jun 25, 2008 12:52 pm Post subject: |
|
|
Acolyte
Joined: 03 Feb 2005
Posts: 67
|
| Quote: |
| Neither the publisher nor the "broker" will know when any of those consumers will GET the publication message. |
With the JMS interface, a durable subscription starts receiving messages via the OnMessage() method once it starts a JMS session in AUTO_ACKNOWLEDGE mode, so stored broker messages pushed from the JMS provider for that particular topic. When the consumer receives the message an acknowledgement is delivered to the broker. So the broker should know the consumer got it, right? (note - this is V7 not V6)
Also, I am assuming after the broker knows his topic subscriptions (durable and non-durable) so why wouldn't he be able to keep track of who needs it - and with the AUTO_ACKNOWLEDGE mode, he should know if it was delivered. Maybe MQSeries V7 doesn't implement this part of the JMS specification? 
| Quote: |
| Depending on who SAID that "P2P was actually a better solution than pub & sub when guaranteed delivery of events is required.", they may have meant something much more subtle than you're thinking, or they may have meant something significantly more "guaranteed" than your requirements actually specify. |
You may be right - the contact I discussed this with was a IBM Senior Technical Staff Member and the WMQ Lead Architect. I think I what I need to understand is how V7 handles JMS guaranteed delivery under the covers. Hoping this insight will shed the light on understanding the guaranteed delivery issue. Is there a white paper on any data on this? 
Thanks!
 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 25, 2008 1:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20700
Location: LI,NY
|
Look at the differences between P2P and PUB/SUB:
P2P => your put was successful and the message is persistent... you have guaranteed delivery
PUB/SUB
Your put was successful and the message is persistent you have ??
You needed to send a request message and look at the response to know the return code from the broker on the publish!!!
You don't know the status of the publish after the put to the stream queue.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| queuetip |
| Posted: Wed Jun 25, 2008 2:10 pm Post subject: |
|
|
Acolyte
Joined: 03 Feb 2005
Posts: 67
|
I appreciate your patience and promptness! 
-----------------------------------------------------
No problem understanding the P2P guaranteed delivery. That is clear.
For PUB/SUB, please correct me if I am wrong. I see 2 pieces of guarateed delivery:
(1) When the JMS producer receives a good return from the JMS provider after publishing a JMS message to a topic. "Guaranteed delivery" is accomplished from the JMS producer's perspective.
...at this point it is the JMS provider's responsibility to ensure the guaranteed delivery to the subscribers...
(2) The JMS provider selects the messages for JMS consumers subscribing to that particular topic and if they are active with AUTO_ACKNOWLEDGE mode, then the JMS provider sends the message to each active JMS consumer. The acknowledge allows the JMS provider to say the message was delivered - thus, guaranteed delivery is accomplished. If the JMS consumer had a durable subscription but was inactive, then the JMS provider would keep the message until the client re-connected and it would then operate just as an active subscription to accomplish guaranteed delivery.
-----------------------------------------------------
This is my understanding - please help me understand where I am wrong in this thinking?
Thanks. |
|
| Back to top |
|
|
|
|
