| Author |
Message
|
| goffinf |
 Posted: Fri Apr 17, 2009 3:27 am Post subject: MQPut failure for same CorrelaionID |
 |
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
Is there any way to configure MQ to reject an MQPut for a message that has the same CorrelID (or MessageID ??) of one which already exists on a queue ??
Thanks
Fraser. |
|
| Back to top |
|
 |
| JosephGramig |
| Posted: Fri Apr 17, 2009 3:58 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 17, 2009 4:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If you're putting to a remote queue, the queue you're putting to could be empty by the time you put the next message.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Apr 17, 2009 4:31 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| And you might want to put several msgs to the same queue with the same correlation ID because they're correlated. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Apr 17, 2009 4:55 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Anyone else getting a bad (but familiar) feeling about where this is going?  |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 17, 2009 4:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kevinf2349 wrote: |
| Anyone else getting a bad (but familiar) feeling about where this is going? |
My deja is vu'd all over the place. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vol |
| Posted: Fri Apr 17, 2009 5:24 am Post subject: |
|
|
Acolyte
Joined: 01 Feb 2009
Posts: 69
|
There is no way to configure WMQ to reject a msg, but you can set it up so that all msgs have a unique CorrelId.
All the qmgrs in the network must have a unique name, and then ask the qmgr to allocate the CorrelId at the time the msg is put. All msgs in the system will have a unique CorrelId. |
|
| Back to top |
|
|
| goffinf |
| Posted: Fri Apr 17, 2009 5:28 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
Ok guys cut me a little slack here, I'm (clearly) no MQ expert, thats why I'm posting !
Let me plainer. I want to PREVENT a message being written to a queue if there is already a message on that queue with the SAME ID (maybe MessageID is a better choice - thats why I'm asking). I am in control of what the 'id' value is, its based on business content from messages being received elsewhere and I set it before attempting the Put.
In one sense you can view this as a mechanism for detecting duplicate messages.
Any ideas
Fraser. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Fri Apr 17, 2009 5:29 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| vol, dont you mean message id rather than correl id? |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Fri Apr 17, 2009 5:34 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| goffinf wrote: |
Let me plainer. I want to PREVENT a message being written to a queue if there is already a message on that queue with the SAME ID |
There is nothing out of the box to do this as the first response to your question stated.
You will have to get your application to not put duplicates or filter them out somewhere.
Its also not a great idea to tinker with the msgid of a message.
Last edited by WMBDEV1 on Fri Apr 17, 2009 5:36 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 17, 2009 5:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| goffinf wrote: |
I am in control of what the 'id' value is, its based on business content from messages being received elsewhere and I set it before attempting the Put.
...
Any ideas
|
Yes - do not do this! (as everybody's deja vu fires)
There are many, many discussions on the forum on why a) you shouldn't set message id and b) you shouldn't (if you set it) put business data in it. This is a road that leads only to pain and misery. The search function will yield these.
If you want to do duplicate message avoidance, get the application coded to remove or ignore duplicates.
Do not set the message id yourself. It is a really bad idea.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 17, 2009 5:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| goffinf wrote: |
Ok guys cut me a little slack here, I'm (clearly) no MQ expert, thats why I'm posting !
Let me plainer. I want to PREVENT a message being written to a queue if there is already a message on that queue with the SAME ID (maybe MessageID is a better choice - thats why I'm asking). I am in control of what the 'id' value is, its based on business content from messages being received elsewhere and I set it before attempting the Put.
In one sense you can view this as a mechanism for detecting duplicate messages.
Any ideas
Fraser. |
This is entirely wrong. Message IDs and CorrelationIDs should not contain business data. You should put this business data into MQv7 properties, if you feel that you must put it somewhere outside of the message body itself.
As others have said, there is no way you can tell MQ to refuse an MQPUT because of the contents of any header field nor even any MQ v7 property.
The detection of duplicate messages is best done and feasibly only done by the consuming application, not at the sending side.
Queues should not hold messages in general, they should be consumed at the same rate as they are put. So you shouldn't even expect that the original message will still be on the queue when you go to PUT it's duplicate. |
|
| Back to top |
|
|
| goffinf |
| Posted: Fri Apr 17, 2009 5:50 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
OK guys, thanks for the advice it all makes good sense.
I agree it would be nice if the sending application wouldn't push out duplicates, but unfortunately I have no control over that (the messages arrrive via a published web service from many potential trading partner applications over the Internet).
As for the consuming application side, yes that is a possibility. However, this is part of a pub/sub application (the messages are business events) so it would mean implementing a duplicate detection solution in each and every subscriber application. For some this might be possible for others, it would push the bar too high.
Me, ... well I'm piggy in the middle(ware) so I was looking for a way of doing this cheaply and centrally without having to creating a bespoke durable and expiry enabled cache with a database of some other technology. Admittedly this is perhaps not the best use of MQ (and is possibly completely inappropriate) but ... budgets, delivery deadlines, ... you get the idea !
Thanks
Fraser. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 17, 2009 5:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| goffinf wrote: |
| Admittedly this is perhaps not the best use of MQ (and is possibly completely inappropriate) |
At best it won't work. At worst it will break WMQ
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| goffinf |
| Posted: Fri Apr 17, 2009 5:58 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
OK fair enough.
I guess I can do a non-destructive read using correlation id before the put and see if I get anything.
Thanks for your patience
Fraser. |
|
| Back to top |
|
|
|
|
