| Author |
Message
|
| KIT_INC |
 Posted: Thu Jun 25, 2015 6:35 am Post subject: Waiting for message in group, Wait interval ? |
 |
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
I am using WMB 7004 on Linux.
We want to understand how MQINPUT handles MQ message group.
We have 'Logical order' 'All messages available' and commit by message group' selected in the MQINPUT node.
The V7 info enter says "If a message flow waits for a group message that does not arrive within the wait interval, a BIP2675 warning message is issued"
I don't think there is any wait interval you can specify on the MQINPUT node. So what is the wait interval the info center is referring to here ?
My understanding is MQINPUT Node is normally doing MQGET with wait unlimited. Please help me with thse questions
1. If one of the message in the group is delayed , when will we got BIP2675 warning message.
2. If one of the message in group is actually missing which means that 'all messages available' will not satisfied, will the flow be hung waiting or will it pick up the next available message on the queue ? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Jun 25, 2015 7:49 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What have you tried? Have you tested it?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Thu Jun 25, 2015 8:49 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
I just tested it.
I remove one of the messages in a group of 4 messages before I put it to a test message flow. The INput Q shows a Q depth of 3. Nothing hapen with the message flow in the last 45 minutes. I then put another test message to the flow. This message is not part of the group. That message was processed.
So I have answered my own question 2.
The broker is smart enough to skip over the 3 messages waiting and process the next available one.
However I am still not getting the BIP2675 warning as indicated by the info center after 45 minutes. If my understanding of MQINPUT node doing MQGET with wait unlimited is correct, this warning message will never show up unless there is a time interval that can be specified which is my question 1. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Jun 25, 2015 9:02 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Was the MQ Message group valid? Right GROUP ID etc etc etc
Did the last message have the right indicator?
Does Broker process the whole group when all the messages are present?
Message grouping is not a subject for MQ Beginners. {not saying that you are btw} There are a number of pitfalls just waiting to trap the unwary.
I have seen a flow described here where the MQINPUT Node was used to read the first message. Then if it is the first in a group an MQGET Node was used to read the remainder of the messages in the group.The MQGET node has the advantage over the MQINPUT Node in that it can have a read timeout set.
I have no idea if this would work or not but ut might be worth a try.
IMHO, this would be a nice subject for a developerwoks post. {hint,hint}
_________________
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 |
|
|
| KIT_INC |
| Posted: Thu Jun 25, 2015 10:05 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
I am not sure how much longer I should wait for the warning message. After waiting for another 45 minutes, I placed the last message that I removed back to the input queue and now the group get processed.
So the broker does what it is suppose to do with group message. The info center statement
"If a message flow waits for a group message that does not arrive within the wait interval, a BIP2675 warning message is issued"
on the warning message and the wait interval may need to be updated.
Last edited by KIT_INC on Thu Jun 25, 2015 10:30 am; edited 1 time in total |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Jun 25, 2015 10:21 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
But as you said, you can't configure the Read Timeout on an MQInput Node.
You can on an MQGET Node.
So you will IMHO never get the warning message.
Perhaps someone who had used message grouping with Broker could comment. I've only ever done it with an applcation written in C.
There I had total control over what happened.
_________________
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 |
|
|
| KIT_INC |
| Posted: Thu Jun 25, 2015 10:43 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
Thanks, I just want to make sure that I have not missed any time interval parameter that I can specified.
The statement
"If a message flow waits for a group message that does not arrive within the wait interval, a BIP2675 warning message is issued" is under the topic
"Receiving messages in a WebSphere MQ message group
You can configure the MQInput node to receive messages that are in a WebSphere® MQ message group."
This makes me believe that there is a wait interval I can use in MQINPUT node for handling message groups. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 25, 2015 12:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| KIT_INC wrote: |
Thanks, I just want to make sure that I have not missed any time interval parameter that I can specified.
The statement
"If a message flow waits for a group message that does not arrive within the wait interval, a BIP2675 warning message is issued" is under the topic
"Receiving messages in a WebSphere MQ message group
You can configure the MQInput node to receive messages that are in a WebSphere® MQ message group."
This makes me believe that there is a wait interval I can use in MQINPUT node for handling message groups. |
The wait interval in the MQInput node is 'forever'. So you will wait 'forever' to get your timeout and BIP message..
If you were to use an MQGet Node the wait interval would come into play...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 25, 2015 12:14 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| The wait interval in the MQInput node is 'forever'. So you will wait 'forever' to get your timeout and BIP message.. |
....
I'm not exactly doubting that. But if it's true, how do multiple instances get quiesced when they are not in use for a minute?
You can't use FAIL_IF_QUIESCING...
So I don't think it's the wait interval on the MQInput node, I think it's the wait interval on passing messages out of the MQInput node if the group is not satisfied. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 25, 2015 12:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
| fjb_saper wrote: |
| The wait interval in the MQInput node is 'forever'. So you will wait 'forever' to get your timeout and BIP message.. |
....
I'm not exactly doubting that. But if it's true, how do multiple instances get quiesced when they are not in use for a minute?
You can't use FAIL_IF_QUIESCING...
So I don't think it's the wait interval on the MQInput node, I think it's the wait interval on passing messages out of the MQInput node if the group is not satisfied. |
Would one of those 'END' type messages do the trick and allow the thread to close? Would the broker monitoring thread generate those for the inactive threads?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 25, 2015 12:38 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| Would one of those 'END' type messages do the trick and allow the thread to close? Would the broker monitoring thread generate those for the inactive threads? |
 |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Jun 25, 2015 10:33 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Two respondents here have mentioned using an MQGET Node to process the 2nd-->nth messages in the group.
My message to the OP is please give that a try instead of wondering about some unseen setting of a wait interval for the MQINPUT Node.
Remember the MQINPUT Node is what I call an 'Originator node'. It starts a unit of work (the threaad) that can be transactions or not. Anything that is not configurable in the properties is probably not available to be changed.
The MQINPUT node seems to be hardwired to do an MQGET with NO TIMEOUT.
This is correct in my eyes
The MWGET node however can have a read timeout set.
The code that I have written for handling groups in 'C' always starts off with a MQGET with no timeout. Subsequent MQGET operations for the later messages in the group do have a timeout. Also if the group is unterminated you should be able to reject/discard everything because in MQ terms, the message is incomplete. Syncpoint settings are vital here as is the understanding of an MQ Unit of work.
As I said above
| Quote: |
Message grouping is not a subject for MQ Beginners. {not saying that you are btw} There are a number of pitfalls just waiting to trap the unwary.
|
_________________
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 |
|
|
| zpat |
| Posted: Thu Jun 25, 2015 11:38 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Logically you can regard the MQinput node as having no timeout. I believe that it is internally coded with a 20 second wait interval (presumably to avoid blocking the thread indefinitely). It is then re-issued of course, I am basing that on looking at traces etc.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
