| Author |
Message
|
| vickas |
 Posted: Sun Jul 01, 2018 7:35 am Post subject: MQ browse behaviour with IIB v9 vs IIB v10 |
 |
|
Centurion
Joined: 18 Aug 2013
Posts: 126
|
Hi Experts ,
I have noticed a difference in behaviour with MQ browse option with the same msg flow deployed on IIB v9 & IIB v10 .
I have a deployed below flow
MQ Input Node(INQ ) --> compute node--> MQ Output Node(OUTQ) --> MQ Get Node(INQ)
Browse option Enabled on MQ Input Node(INQ )
MQ Output Node(OUTQ) failure terminal is connected to exception handler
MQ Output Node(OUTQ) out terminal is connected to MQ Get ( INQ)
The above sample POC flow is to implement Endless retry mechanism which works perfectly fine on IIB v9 with WMQ v7.5 whereas it behaves wierd on IIB v10 with IBM MQ v9.0.0/WMQ v7.5.
Test scenerio :
pushed 3 msgs with msgid's 1,2,3 onto the Input Node(INQ ) and inhibited the put option on MQ output node
observation in IIB v9 :
upon inhibiting the put option on MQ output node , the msg with msg id :1 which was supposed to be pushed onto the output queue kept retrying while the other msgs (msg id :2 ,msg id :3) recieved onto the MQ Input node sits in the queue as expected.When the msg flow is restarted during the retrial , the msg id : 1 is picked up and the msg id :1 is retried until the put option is enabled.
msgs in queue :
msg id 1
msg id 2
msg id 3
once the put option on MQ output node is inhibited :
trying to send msg id : 1
trying to send msg id : 1
trying to send msg id : 1
trying to send msg id : 1
upon flow restart
trying to send msg id : 1
trying to send msg id : 1
trying to send msg id : 1
trying to send msg id : 1
trying to send msg id : 1
trying to send msg id : 1
trying to send msg id : 1
observation in IIB v10 :
upon inhibiting the put option on MQ output node , the msg with msg id :1 which was supposed to be pushed onto the output queue kept retrying while the other msgs (msg id :2 ,msg id :3) recieved onto the MQ Input node sits in the queue as expected.When the msg flow is restarted during the retrial , the msg id : 1 is picked up first followed by msg id : 2 , msg id :3 and then msg id : 1 is retried until the put option is enabled.
msgs in queue :
msg id 1
msg id 2
msg id 3
once the put option is inhibited on MQ output node :
trying to send msg id : 1
trying to send msg id : 1
trying to send msg id : 1
trying to send msg id : 1
upon flow restart
trying to send msg id : 1
trying to send msg id : 2
trying to send msg id : 3
trying to send msg id : 1
trying to send msg id : 1
trying to send msg id : 1
trying to send msg id : 1
concern ::
Here in IIB v10 , whenever the flow is restarted , the flows picks all the msgs which are sitting in the MQ Input node and then it retries the first message until it is restarted/put option is enabled while in IIB v9 , it always picks the first msg and retries until it is restarted/put option is enabled
So why do we see this difference in behaviour?
How can we achieve the same behaviour as of IIB v9 in IIB v10 ?
Any settings to be done on IIB v10 or WMQ v9?
your inputs can be a great help !! |
|
| Back to top |
|
 |
| abhi_thri |
| Posted: Mon Jul 02, 2018 1:34 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
hi...just to be sure, can you please crosscheck whether 'additionalInstances' for the v10 flow is set to 1 or above (for eg:- additionalInstances getting overridden via the deployment framework or so).
Also worth checking whether you could reproduce the issue (MQInput consuming multiple messages in GET mode) using a simpler flow (MQInput - MQOutput) and queue up multiple messages on the queue.
PS: Isn't this 'Endless retry mechanism' bit resolve intensive? eg:- for any failure (database outage for 2 hours) the flow will need to continuously retry the same message until the issue is resolved. I've seen retry designs where the failed messages get re-queued to a retry queue and the retry flow get triggered every 10mins or so to check whether the issue is now resolved. |
|
| Back to top |
|
|
| vickas |
| Posted: Mon Jul 02, 2018 10:10 am Post subject: |
|
|
Centurion
Joined: 18 Aug 2013
Posts: 126
|
| abhi_thri wrote: |
| hi...just to be sure, can you please crosscheck whether 'additionalInstances' for the v10 flow is set to 1 or above (for eg:- additionalInstances getting overridden via the deployment framework or so). |
Its only 1 instance
| Quote: |
PS: Isn't this 'Endless retry mechanism' bit resolve intensive? eg:- for any failure (database outage for 2 hours) the flow will need to continuously retry the same message until the issue is resolved. I've seen retry designs where the failed messages get re-queued to a retry queue and the retry flow get triggered every 10mins or so to check whether the issue is now resolved. |
have implemented this kind of retrial mechanism to ensure not to miss out the sequencing .
btw , this retrial mechanism is implemented for file transfer thru SFTP , where sequence of files being sent is atmost important.
did you check the browse option with IIB v10 ?
any leads on the above scenerio ? |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Jul 02, 2018 4:08 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Quote: |
| have implemented this kind of retrial mechanism to ensure not to miss out the sequencing |
I assume you are aware that MQ does not guarantee message sequencing. The messages may seem to be processed in sequence, but don't rely on it for any critical interfaces.
_________________
Glenn |
|
| Back to top |
|
|
| abhi_thri |
| Posted: Mon Jul 09, 2018 4:37 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
| vickas wrote: |
did you check the browse option with IIB v10 ?
|
hi...I did a quick test and couldn't reproduce the issue of 'flow consuming multiple messages at the same time' for MQInput (with Browse). So if you are able to reproduce the issue with a simple flow (MQInput with browse -> MQOutput) I suggest raising it with IBM via a PMR.
PS: The IIB version tried is 10.0.0.7 |
|
| Back to top |
|
|
| vickas |
| Posted: Mon Jul 09, 2018 11:46 pm Post subject: |
|
|
Centurion
Joined: 18 Aug 2013
Posts: 126
|
| abhi_thri wrote: |
| vickas wrote: |
did you check the browse option with IIB v10 ?
|
hi...I did a quick test and couldn't reproduce the issue of 'flow consuming multiple messages at the same time' for MQInput (with Browse). So if you are able to reproduce the issue with a simple flow (MQInput with browse -> MQOutput) I suggest raising it with IBM via a PMR.
PS: The IIB version tried is 10.0.0.7 |
HI abhi , its only when the flow is restarted while the msgs are being retried ,we see this behaviour .
however I have raised the issue with IBM support , they acknowledged that they have noticed the difference in behaviour , waiting for their suggestion |
|
| Back to top |
|
|
| adubya |
| Posted: Thu Jul 12, 2018 12:41 am Post subject: |
|
|
Partisan
Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK
|
In MQ Explorer, how many "input" handles are shown as open on the INQ queue for both scenarios ?
_________________
Independent Middleware Consultant
andy@knownentity.com |
|
| Back to top |
|
|
|
|
