| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Is there a way to chng attr of a publication within a mflow |
« View previous topic :: View next topic » |
| Author |
Message
|
| paribok |
 Posted: Tue Dec 31, 2013 7:26 pm Post subject: Is there a way to chng attr of a publication within a mflow |
 |
|
Novice
Joined: 05 Aug 2013
Posts: 13
|
Hi,
I'm not quite sure how to ask this to I'll just explain my use case. I have this topic which gets a pretty high volume publication. There are several subscribers to this topic. However, a few of these subscribers are non-critical in that if they do not receive some of their publication, they are fine with it. Some are critical though that they absolutely have to get their messages. Messages are published as persistent. Everything has been fine until these non-critical subscribers came along. Their subscriptions are being forwarded to a remote queue manager, which, occasionally breaks (runs out of space, or something happens in the middle of the day) that the XMITQ of our qmgr backs up and fills up because of msgs that cannot be delivered to the remote destination. When this happens, eventually msgs spill over to DLQ, and eventually causes some slow down to the msg flow, affecting the other subscribers. Thought of using the option in the channel to not use dlq and just discard msgs if they cannot be delivered but then realized that only applies to non persistent msgs - and these publications are persistent. Is there a way for me to segregate or re route messages, say to 2 routes, and one route change it to be non-persistent so that we can just have MQ discard undeliverable messages? but the other route stays the same persistent messages? ... or maybe is there a way in the msgflow to handle subscriptions that cannot be delivered ? ie instead of putting it to dlq, just discard it?
Maria |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Tue Dec 31, 2013 11:59 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
1) maybe is there a way in the msgflow to handle subscriptions that cannot be delivered
No (AFAIK)
The other part of your question is interesting.
Aside from the fact that the problems lie at the destination QM (and where it should get fixed properly) you are looking for some alternatives. Well done.
You can define two channels between QMGR's. Then you can select in the remote queue definition which XMIT Queue messages for that remote queue would use.
This is typically used to let higher priority messages skip over lower priority ones when moving between QMGRS. Your case is the same in that the Non persisten messages can go one way and the persistent ones go the other way.
If you are using a Publish Node then you can't implement my last suggestion but if you are 'doing it manually' then you might be able to.
This is to add an expiry time on the messages published. Then if they are not read in a certain time they will automatically get purges when their expiry time has been reached. This might have bad implications for your business so tread carefully here. It might solve the problem with the non-critical messages though.
finally,
It might be worth breaking the flow into critical and non critical parts. Then post the message (via pub sub) from the main critical part and let the second part pick up the message and process it accordingly. If there are only a few receivers of the non critical messages then you could use an MQOutput Node in DistributionList mode. Here you could set a message expiry.
Interesting post and a nice way to start the new year off.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| paribok |
| Posted: Wed Jan 01, 2014 3:42 pm Post subject: |
|
|
Novice
Joined: 05 Aug 2013
Posts: 13
|
Thank you for all these alternatives smdavies! (and at 1 minute before the year turned too! - well, at least from where I am).
Yes, those destination remote qmgrs need to get their act together - been on that battle, and not winning - so in the meantime I have to find ways to protect our side of the fence :-/
I think I like your last suggestion best. I can't put expiry time on the messages published because some of the critical subscribers get their messages by batch so it takes a couple of hours before they pick up theirs (but their receiving qmgrs are pretty stable so these haven't had any issue with big volumes unlike the non critical ones). So breaking up the flow and setting expiry time only on the second part on a distlist mode for the non critical messages seems like a great solution for this use case!! Thanks so much! |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Jan 01, 2014 10:40 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Glad to be of some help.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| 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
|
|
|
|
