Author |
Message
|
Glass |
Posted: Mon Oct 29, 2007 9:11 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2006 Posts: 56
|
Hi,
I have a similar issue. The messages are stuck in a queue. The DataFlowEngine says 'Inactive' but there are messages sitting there. The flow is running and the input count is 1 (active) and output count is 3 (inactive). There is nothing in the logs.
When I stop the flow and start it back up, it picks up the messages.
Thanks |
|
Back to top |
|
 |
elvis_gn |
Posted: Mon Oct 29, 2007 9:45 am Post subject: |
|
|
 Padawan
Joined: 08 Oct 2004 Posts: 1905 Location: Dubai
|
Hi Glass,
Please start a new topic, lets not guess your issue is what someone else is facing...
It could be that a message is looping in your flow...do u see the CPU usage for the execution group increase in such a situation ?
Regards. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Oct 29, 2007 10:27 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
split from hijacked topic _________________ MQ & Broker admin |
|
Back to top |
|
 |
Glass |
Posted: Mon Oct 29, 2007 10:38 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2006 Posts: 56
|
Hi,
Thanks for creating a new discussion. I will check the CPU usage next time it happens.
Thanks |
|
Back to top |
|
 |
shalabh1976 |
Posted: Mon Oct 29, 2007 11:35 am Post subject: |
|
|
 Partisan
Joined: 18 Jul 2002 Posts: 381 Location: Gurgaon, India
|
elvis,
Could this be a poison message scenario where the Broker doesn't know what to do with the flow if catch & failure are not wired and backout and dead letter queues are not defined.
See here:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/topic/com.ibm.etools.mft.eb.doc/ac00414_.htm
I have seen this happening before. There was no abnormal CPU utilization.
Best thing was to clear the queue to remove the poison message( Obviously one has to find out why the poroblem happened) and the flow proceeds.
As per the infocenter Broker will keep retrying but I have seen that the CPU utilization may not be high.
Awaiting your inputs. _________________ Shalabh
IBM Cert. WMB V6.0
IBM Cert. MQ V5.3 App. Prog.
IBM Cert. DB2 9 DB Associate |
|
Back to top |
|
 |
Glass |
Posted: Tue Oct 30, 2007 8:44 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2006 Posts: 56
|
Hi,
We ran into this again today. The CPU did not have any big spike or anything out of the ordinary. As for the messages, we tried taking out the first message but the rest would still not process. Only when we stop and start the flow the messages go though. It has happened in several flows and not just one in particular.
We have not been able to reproduce this so we don't know when this will happen again.
Any suggestions? |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Oct 30, 2007 8:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Try turning on user trace at debug level for the flow, and see what that says. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Glass |
Posted: Tue Oct 30, 2007 10:44 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2006 Posts: 56
|
The trace did not show anything.
Has anybody experienced this before? |
|
Back to top |
|
 |
shalabh1976 |
Posted: Tue Oct 30, 2007 10:56 am Post subject: |
|
|
 Partisan
Joined: 18 Jul 2002 Posts: 381 Location: Gurgaon, India
|
When there is no problem why will the trace show anything?
You must send the input messages that cause the problem to occur and see the trace at that point of time. _________________ Shalabh
IBM Cert. WMB V6.0
IBM Cert. MQ V5.3 App. Prog.
IBM Cert. DB2 9 DB Associate |
|
Back to top |
|
 |
Glass |
Posted: Tue Oct 30, 2007 11:17 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2006 Posts: 56
|
We turned on the trace when the messages were stuck. Then we restarted the flow and nothing in the trace. Turning the trace on all day is going to slow the flow of messages down tremendously so we skipped that idea. But now it seems that may be the only way to go.
I have tried sending the same messages (that was stuck) in another environment and it processes fine. But then again, the faulty message (if there is one) must be already picked up and will not show in the queue. |
|
Back to top |
|
 |
shalabh1976 |
Posted: Tue Oct 30, 2007 11:21 am Post subject: |
|
|
 Partisan
Joined: 18 Jul 2002 Posts: 381 Location: Gurgaon, India
|
Is your error/exception handler coded to throw a message to the event log? On Windows you can have a look at the event viewer( but it will only show something if you have not handled or have used a throw node). _________________ Shalabh
IBM Cert. WMB V6.0
IBM Cert. MQ V5.3 App. Prog.
IBM Cert. DB2 9 DB Associate |
|
Back to top |
|
 |
TonyD |
Posted: Tue Oct 30, 2007 11:40 am Post subject: |
|
|
Knight
Joined: 15 May 2001 Posts: 540 Location: New Zealand
|
Quote: |
Has anybody experienced this before?
|
Yes, I have seen it happening recently with a couple of flows. Everything appears normal, the queues are open for input by the execution group process but the flows do not consume the messages. This has been happening in unit testing so I remove the unread message from the queue and resubmit the same test message which usually will then be read. A bit contact admin really! I would recommend that you raise a PMR. |
|
Back to top |
|
 |
Glass |
Posted: Tue Oct 30, 2007 12:37 pm Post subject: |
|
|
Acolyte
Joined: 02 Mar 2006 Posts: 56
|
From the MQInput node we have the 'Failure' and 'Catch' mapped to some queue.
Earlier I tried exporting the stuck messages to a file and then putting it back in the queue but that did not help either.
I am going to trun on the trace and hopefully it will happen again soon since it is going to slow the process down a lot. I will probably open a PMR but they will probably ask for a log/trace or have me replicate the issue, which I cannot right now.
Thanks to all for the input. |
|
Back to top |
|
 |
shalabh1976 |
Posted: Tue Oct 30, 2007 12:41 pm Post subject: |
|
|
 Partisan
Joined: 18 Jul 2002 Posts: 381 Location: Gurgaon, India
|
On the queues connected to Failure/Catch change the transaction mode to No and wire a THROW node to the out terminal of the MQOutput. This way you should see messages in the event log.
See if this helps _________________ Shalabh
IBM Cert. WMB V6.0
IBM Cert. MQ V5.3 App. Prog.
IBM Cert. DB2 9 DB Associate |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Oct 30, 2007 12:43 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
DO NOT WIRE A THROW NODE TO THE FAILURE TERMINAL OF THE INPUT NODE. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
|