| Author |
Message
|
| Bosco |
 Posted: Wed Oct 26, 2005 4:16 pm Post subject: MQOutput Node delay problem |
 |
|
Novice
Joined: 30 Nov 2003
Posts: 17
|
Hi all,
Has anyone experienced that when a message flow writing a message through the IBM MQOutput node, it takes a while for the message actually being put into the queue?
WBIMB V5.0.4
Bosco  |
|
| Back to top |
|
 |
| wschutz |
| Posted: Wed Oct 26, 2005 4:38 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Do you see the curdepth on the queue go up right away? How are you determining the delay is on the MQOutput node and not in yor flow somewhere?
_________________
-wayne |
|
| Back to top |
|
|
| Bosco |
| Posted: Wed Oct 26, 2005 5:40 pm Post subject: |
|
|
Novice
Joined: 30 Nov 2003
Posts: 17
|
Hi wschutz,
I believe the delay is on the MQOutput node and not in flow somewhere. Here is the fragment of the usertrace:
2005-10-26 22:11:57.601871 7454 UserTrace BIP4460I: Message propagated to out terminal from node 'Do_Trace.ProductionTraceOff'.
2005-10-26 22:12:15.022171 7454 UserTrace BIP2638I: The MQ output node 'ABT_20.MQOutput' attempted to write a message to queue 'MULTI.REQ' connected to queue manager ''. The MQCC was '0' and the MQRC was '0'.
2005-10-26 22:12:15.022188 7454 UserTrace BIP2622I: Message successfully output by output node 'ABT_20.MQOutput' to queue 'MULTI.REQ' on queue manager ''.
As you can you at 2005-10-26 22:11:57 the message was propagated to the out terminal of Do_Trace.ProductionTraceOff node which is a subflow containing a IBM passthru node only. Its out terminal is direct connected to the input terminal of the MQOutput node. Somehow the message only put to the queue at 2005-10-26 22:12:15.
Thanks
Bosco |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Oct 26, 2005 7:07 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Well, I think it's time you start applying the ol' scientific method, eh?
1. Try putting the subflow content directly into your flow (i.e don't use a subflow), putting the MQOutput in front of where the subflow used to be connected to. See what happens.
2. Try the same as 1 with passthru node, see what happens.
3. Try putting to a different queue. (it's silly I know, but one wonders...)
4. Build a flow with just MQInput and MQOutput. See what happens.
5. Start adding logic from your real flow to the new dummy flow you built in 4, see when the problem begins to occur.
6. Additional points: make sure no debug is opened for that flow, ask yourself (and tell us!) "did this flow work fine in the past?" "Do other flows have the same delay?" "If so, why? if no, why?".
In short, use process of elimination, as you should have from the get-go. Mind you, 15 secs is not that much on a busy broker, but is indeed slightly unusual. Keep us posted.  |
|
| Back to top |
|
|
| JT |
| Posted: Wed Oct 26, 2005 7:26 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| What is the size of the output message ? |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Oct 26, 2005 7:33 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| JT wrote: |
| What is the size of the output message ? |
So simple, I'm in tears - and me going about my bloody scientific method... |
|
| Back to top |
|
|
| Bosco |
| Posted: Wed Oct 26, 2005 8:40 pm Post subject: |
|
|
Novice
Joined: 30 Nov 2003
Posts: 17
|
To JT, the size of the message is 13160 bytes.
This problem occured during our performance testing in a Production like environment ([i]yes! it supposed to be big enough to handle real volume of data[/i]) when we had about 1000 users doing various transactions at the same time.
Because of this MQ put delay, of course the CurDepth on the request queue for this message flow built up. The question is how does the MQOutput node work ? Does it wait for available MQ connection, if it can't get one as all MQ connection used up by other threads?
[b]Of course, this message flow does not have this problem in all our development environments  .[/b]
To hopsala, thanks for your suggestion. I wish life with WBIMB V5.0.4 was that simple.
PS. I intentionally called myself Newbusie and I have been using WBIMB V5 ever since IBM first released it . The problem with this product is you don't know what exactly under the cover. |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Oct 26, 2005 11:41 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
What are the Commit Interval and Commit Count on the bar file.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Oct 27, 2005 1:50 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
What type of message is the output node writing (xml, tds, cwf) and it is a very large message in terms of the number of fields that must be parsed out?
_________________
-wayne |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Oct 27, 2005 2:49 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| Bosco wrote: |
| To hopsala, thanks for your suggestion. I wish life with WBIMB V5.0.4 was that simple. |
As stated here below, I am aware of WBIs shortcumings, but what isn't simple about what I stated? If you were able to build the flow in the first place, you'll be able to try everything I had suggested - which (as can be easily logically proven) will give you the solution.
| Bosco wrote: |
| The problem with this product is you don't know what exactly under the cover. |
Amen to that, brother! |
|
| Back to top |
|
|
| jhosie |
| Posted: Thu Oct 27, 2005 3:55 am Post subject: |
|
|
Apprentice
Joined: 12 May 2005
Posts: 28
|
Typically, the message flowing through a Message Flow is a logical tree. Before writing it to a MQ Queue, it must be converted to its physical wire format (or serialized).
My guess would be that the biggest part of the elapsed time was spent converting the message from a logical tree to the physical, bitstream representation.
You could verify this by forcing the serialisation to happen before entering the MQOutputNode. e.g. place a RCD (ResetContentDescriptor) node before the output node, and reset domain to BLOB.
If you see the message spends a considerable amount of time in the RCD node then that would suggest that my hypothesis is correct. You should also see that the time between entering the MQOutputNode and putting to the queue is reduced.
NOTE There will still be some delay, as the headers will still need to be serialized. (Using the RCD node to reset the domain to BLOB will only cause the body to be serialized). |
|
| Back to top |
|
|
|
|
