| Author |
Message
|
| knegarpetter |
 Posted: Wed Dec 29, 2004 2:00 pm Post subject: Crazy stuff.... |
 |
|
Apprentice
Joined: 10 Dec 2004
Posts: 39
|
I have a strange problem...
I have a queuereceiver, with a onMessage method..
i now have three senders to this queue, that the listener is listening on...
an sometimes, like after 4 messages, it (the listener) takes get the same message twice, in onMessage.... i cant understand it.... WHY???!!!
regards Petter |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Dec 29, 2004 2:30 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Easy,
Should any processing of the onMessage method throw and Exception the transaction will be rolled back. Next message to be processed is then the same message you just received. If you have no backout threshold you are in presence of a potential poison message. (message that whatever you do you cannot process without exceptions being thrown).
Most probably your first processing attempt failed due to dblocking. The second attempt is successful as the db had the time to commit in the meantime. *--- we are talking about milliseconds here ---*
Enjoy  |
|
| Back to top |
|
|
| mqmhr |
| Posted: Wed Dec 29, 2004 7:55 pm Post subject: |
|
|
Centurion
Joined: 28 Dec 2004
Posts: 105
|
| You could check the BackoutCount attribute of the message to actually verify that the message is getting backed out by the application. It is incremented by one each time the message is backed out. |
|
| Back to top |
|
|
| knegarpetter |
| Posted: Thu Dec 30, 2004 12:32 am Post subject: |
|
|
Apprentice
Joined: 10 Dec 2004
Posts: 39
|
hi.
well after some investigations i found out that the onMessage is working as i should.... but...
ok, the senario...
i have three senders that puts strings on a MQsender that do textmessages of the stirings and then send them to a queue... i have an system.out and can monitor the messages... now the strange thing happens...
every one of the three "string senders" puts 4 strings on the mqsender, the mqsender creates 12 textmessages and then puts them on the queue... the system.out... looks good 12 different messages... BUT... when i look at them at the queue some of the messages have overridden the others... so i have 2 of some messages and none of some... always 12 al togehter though..
im going nuts...
Petter |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Dec 30, 2004 4:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I suspect that the "overwritten" messages are, in fact, an artifact of your viewing tool.
A lot of the queue browsing/editing tools out there have difficulties dealing with messages that have duplicate identifications (even CapitalWare's stuff still hasn't gotten this right). So, when list the messages on the queue, it will show you all 12. But then when you try to browse the queue, it is getting the message by msgID... and if there are duplicate message Id's you will only see the first one.
Try running amqsbcg against all the messages on the queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Dec 30, 2004 6:52 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| jefflowrey wrote: |
| (even CapitalWare's stuff still hasn't gotten this right) |
Cough, hack, cough. That's Mr. Capitalware to you!!! 
All of Capitalware's product use BOTH MsgID and CorrelID for editing, deleting, fowarding, etc... messages. This is IBM's recommended best practises standard. I fully agree that there are companies / developers / architects who voilate this practise.
I suppose I could add code that would 'determine the selected message as the 5th message with that particular MsgID & CorrelID combination'. Then loop through the hundreds of messages to find the 5th matching message then do the action. Of course, by the very nature of MQ, the 5th message could very well become the 4th matching message because an application did a MQGET. (Hence, it still would be deleting the wrong message).
Bottom line: Companies / developers / architects should allow MQ to generate a unique MsgID on a MQPUT and only modified / update the CorrelID field. (as per IBM's best practises standard)
I really wish IBM would have made MsgID field a read-only field. If I remember correctly, I don't think there was a CorrelID field in version 1.0 of MQ. I think it showed up in version 1.0.1 or 1.0.2 (or something). So, to be backwards compatible, IBM left MsgID as user changeable. It's too bad that 10 years ago IBM didn't make that decision. But then again, IBM was doing a hard sell to banks (I was at a bank) & insurance companies at the time and they didn't want any bad press.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Dec 30, 2004 7:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It doesn't seem that hard to me to try an extra MQGet to see if the same MsgID and CorrID return more than one message...
Of course, from there, figuring out that the user clicked on the FIFTH such message in your list box, and then going to get the fifth message may be a little harder.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Dec 30, 2004 12:46 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Oh sure, you want me to build a ResultSet interface for MQ. 
If you compare MQ's 'Get By' feature, it is similar in concept to a SQL SELECT WHERE clause. But the where is limited to MsgId, CorrelID & GroupID. It would be nice to be able to pick other fields like PutDateTime, etc... (Ya, I know, its not a database.)
I have too many things on my plate right now, but I will think about it.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Dec 30, 2004 1:13 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| RogerLacroix wrote: |
| Oh sure, you want me to build a ResultSet interface for MQ. |
Well, it sounds like there might be some sample code for a result set Interface that you could crib and adapt for MQ... So it really should just be a Simple Matter of Programming... 
| RogerLacroix wrote: |
| I have too many things on my plate right now, but I will think about it. |
It just seems to me to be a fairly common problem where programs go awry and don't create unique message/correlation ID pairs, and a tool that is designed to be a general purpose message handler should... you know... handle that fairly common case...
I do understand the issues involved though, particularly with not knowing if another program may get messages you were just working with. But I'd think allowing some things only if the queue has been openedby the tool exclusively (you *do* have that as an option, right?) is a reasonable approach.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Dec 30, 2004 2:01 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| jefflowrey wrote: |
| if the queue has been openedby the tool exclusively (you *do* have that as an option, right?) |
You know, you are the first to ever ask about that feature!!!!
It never occurred to me that someone would want to do that.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
