| Author |
Message
|
| rohiddev |
 Posted: Fri Dec 14, 2007 7:13 am Post subject: Error Handling in MQ PubSub |
 |
|
Newbie
Joined: 13 Dec 2007
Posts: 2
|
What would be the best way to handle error if one of the subscriber
had an error and needs the message delivered again for processing.
We are using native MQ pub/sub (not MQ Message Broker).
SCENARIO
Publisher publishes a message about a topic that has
3 subscribers (subscriber a, subscriber b and subscriber c).
Subscriber a and subscriber c process the message without any error.
If subscriber b has an error and puts the message on an error queue to be researched. Once the problem with subscriber b has been resolved, how do we republish the message and ensure that only subscriber b gets the message delivered again for processing.
MQ Version being used is 6.0.2.1
Any help is much appreciated |
|
| Back to top |
|
 |
| JosephGramig |
| Posted: Fri Dec 14, 2007 7:33 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Well, you could build a program for the researcher to use to put the message back on subscriber b's input Q. You can also use any one of a number of support packs to do this but that would usually take a WMQ Administrator to use the tool (as you probably don't want to give away that much access to everybody).
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| ashu |
| Posted: Mon Dec 17, 2007 1:17 am Post subject: |
|
|
Centurion
Joined: 11 Nov 2006
Posts: 132
|
I'm not sure but shouldn't this be an ideal situation for the use of transaction? Either all get the message and process it or none processes it
_________________
Ashu
"It is simple to be Happy but difficult to be Simple" |
|
| Back to top |
|
|
| ashu |
| Posted: Mon Dec 17, 2007 1:27 am Post subject: |
|
|
Centurion
Joined: 11 Nov 2006
Posts: 132
|
Of course i'am assuming that all the three subscribers are a part of same Application and they processing the message is going to affect the overall goal of the system some or the other time. 
_________________
Ashu
"It is simple to be Happy but difficult to be Simple" |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 17, 2007 4:52 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ashu wrote: |
I'm not sure but shouldn't this be an ideal situation for the use of transaction? Either all get the message and process it or none processes it
|
Hell no! This is pub / sub. Each subscriber is completely independent of each other, including transaction wise. The best thing would be to have each subscriber use a different queue. So you can see which one fails to consume.
For the error resolution process see Joseph's post...
Enjoy  
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rohiddev |
| Posted: Mon Dec 17, 2007 6:32 am Post subject: |
|
|
Newbie
Joined: 13 Dec 2007
Posts: 2
|
The 3 subscribers are MDB's listening to the same listener port. The listener port is setup with connection factory jndi name and destination jndi name referring topic connection factory and topic
How would I feed only Subscriber B the corrected message using the same input Queue?"
MDB
<ejb-jar id="ejb-jar_ID">
<display-name>Message</display-name>
<enterprise-beans>
<message-driven id="Message">
<ejb-name>Message</ejb-name>
<ejb-class>com.amfam.mdb.MessageBean</ejb-class>
<transaction-type>Container</transaction-type>
<message-driven-destination>
<destination-type>javax.jms.Topic</destination-type>
</message-driven-destination>
</message-driven>
</enterprise-beans>
</ejb-jar>
Regards,
Rohid |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Dec 17, 2007 7:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| rohiddev wrote: |
| How would I feed only Subscriber B the corrected message using the same input Queue?" |
Either the message is already marked in such a way that the individual subscriber will pick it up from the same queue, or it isn't.
If it isn't, you can't change that.
If it is, you don't need to change that.
You're substantially better off having each individual subscriber use it's own individual subscription queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rpetty |
| Posted: Mon Dec 17, 2007 8:26 am Post subject: |
|
|
Newbie
Joined: 17 Dec 2007
Posts: 2
|
| jefflowrey wrote: |
| rohiddev wrote: |
| How would I feed only Subscriber B the corrected message using the same input Queue?" |
Either the message is already marked in such a way that the individual subscriber will pick it up from the same queue, or it isn't.
If it isn't, you can't change that.
If it is, you don't need to change that.
You're substantially better off having each individual subscriber use it's own individual subscription queue. |
(I work with Rohid, so consider me part of the asking group)
A couple clarifications:
The receiving applications are all separate applications, deployed in different environments and required to act autononomously.
I thought the whole point of setting up a Pub/Sub capability was that you write the message to one queue, and all of the subscribers receive the message. The actual number of recievers is unknown to the sending application. How is each subscriber using it's own subscription queue different than straight P2P Messaging? That's why we're using PubSub in the first place.
Our emprical evidence has shown that what actually happens is slightly different:
You write the message to the subscription queue, and MQ replicates it for each of the subscribers. So if you have 3 subscribers, what you end up with is 3 messages on the queue.
Ideally, what we would need to do in the event of an error (in the example listed above...) is just republish the corrected message destined for the B listener on the same queue, and this time the listener would be able to successfully process it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 17, 2007 8:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rpetty wrote: |
| I thought the whole point of setting up a Pub/Sub capability was that you write the message to one queue, and all of the subscribers receive the message. |
No, the point of pub/sub is you publish the message once and a copy is sent to each of the subscribers. Using whatever queues were registered as part of the subscription.
| rpetty wrote: |
| The actual number of recievers is unknown to the sending application. |
Quite so
| rpetty wrote: |
| How is each subscriber using it's own subscription queue different than straight P2P Messaging? That's why we're using PubSub in the first place. |
Because with straight P2P you'd need to know how many subscribers there were and the queues they were listening on. In this model (as you correctly point out) the number and location of the subscribers is transperent to the publisher.
| rpetty wrote: |
| Ideally, what we would need to do in the event of an error (in the example listed above...) is just republish the corrected message destined for the B listener on the same queue, and this time the listener would be able to successfully process it. |
If it was me (and it clearly isn't) I'd have the subscribers on different queues. If one fails and two don't then they're clearly doing something different and I'd segrigate the processing onto different queues. You still gain the benefits of the pub/sub model and the problem you describe here solves itself because there's a specific queue the message can be replayed onto.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Dec 17, 2007 2:27 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Vitor wrote: |
| I'd have the subscribers on different queues. If one fails and two don't then they're clearly doing something different and I'd segrigate the processing onto different queues. You still gain the benefits of the pub/sub model and the problem you describe here solves itself because there's a specific queue the message can be replayed onto. |
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 17, 2007 8:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| fjb_saper wrote: |
| ashu wrote: |
I'm not sure but shouldn't this be an ideal situation for the use of transaction? Either all get the message and process it or none processes it
|
Hell no! This is pub / sub. Each subscriber is completely independent of each other, including transaction wise. The best thing would be to have each subscriber use a different queue. So you can see which one fails to consume.
For the error resolution process see Joseph's post...
Enjoy |
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Dec 18, 2007 1:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Hey guys, notice how, not matter how you ask the question, you're getting the same advice?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rpetty |
| Posted: Tue Dec 18, 2007 5:57 am Post subject: |
|
|
Newbie
Joined: 17 Dec 2007
Posts: 2
|
| Vitor wrote: |
| If it was me (and it clearly isn't) I'd have the subscribers on different queues. If one fails and two don't then they're clearly doing something different and I'd segrigate the processing onto different queues. You still gain the benefits of the pub/sub model and the problem you describe here solves itself because there's a specific queue the message can be replayed onto. |
Ok, well, I'm not an MQ administrator, so you will need to excuse my ignorance of how MQ is configured for Pub/Sub.
If what I'm reading here is correct, you set up separate queues for each planned subscriber, and configure MQ to replicate the message to separate queues, instead of to a single queue. This lets you publish to one topic and MQ handles the distribution to the receiving queues?
As far as the receiving application is concerned then, they subscribe to a topic, and MQ decides which queue to put them on, based on the queue they specify when they subscribe?
So this makes another administrative step that will need to happen, as each subscriber will need to notify the MQ administrators so they can set up a new queue.
| Quote: |
Hey guys, notice how, not matter how you ask the question, you're getting the same advice?
|
Yes, I see that. No one is rejecting the suggested solution, but instead trying to figure out how to make it happen. My understanding of how Pub/Sub works and is configured is obviously somewhat different than reality. So sorry to ask for clarification. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 18, 2007 6:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Depending on the nature of the subscriptions, subscribers can use dynamic queues, rather than permanent queues...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Dec 18, 2007 12:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rpetty wrote: |
So this makes another administrative step that will need to happen, as each subscriber will need to notify the MQ administrators so they can set up a new queue.
|
It's a cheap step. Local queues are easy & quick; in situations like this most sites have scripts run by the junior administrators. I have seen sites where a web site is available to define such queues to non-MQ people.
Or as my estemed associate has said, dynamic queues are another popular option.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
