Author |
Message
|
AYSC |
Posted: Tue Jul 12, 2005 5:34 am Post subject: Message Flow running problem (stalled) |
|
|
Newbie
Joined: 12 Jul 2005 Posts: 8
|
Hi All,
i have the situation here...
Environment:
WBI Message/Event Broker with CSD 4, AIX OS.
So, i have some flows running and messages remain in queue. I've tried to start/restart/etc couples of time, but... no results.
Another flow started after the shutdown->queue clear->start
But there still some flows that are blocked in some way.
And the strange thing is - there are no error logs!
Any suggestions ?  |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jul 12, 2005 5:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
What is the retry count of the first message in a blocked queue?
Likely, you have a loop where the message is getting rolled back and reprocessed continually. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
AYSC |
Posted: Tue Jul 12, 2005 5:45 am Post subject: |
|
|
Newbie
Joined: 12 Jul 2005 Posts: 8
|
jefflowrey wrote: |
What is the retry count of the first message in a blocked queue?
Likely, you have a loop where the message is getting rolled back and reprocessed continually. |
Where i can check that value ? |
|
Back to top |
|
 |
AYSC |
Posted: Tue Jul 12, 2005 5:50 am Post subject: |
|
|
Newbie
Joined: 12 Jul 2005 Posts: 8
|
jefflowrey wrote: |
What is the retry count of the first message in a blocked queue?
Likely, you have a loop where the message is getting rolled back and reprocessed continually. |
The flow is... quite simple. Read the message, db insert and output queue. DB is ok, no locks and etc.
But the messages are still there. I cant see any retry count param that can be set... |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jul 12, 2005 5:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
AYSC wrote: |
Where i can check that value ? |
I guess technically, it is the Backout count that I meant,
Application Programming Reference, Chapter 10 MQMD wrote: |
BackoutCount (MQLONG)
Backout counter.
This is a count of the number of times the message has been previously returned by the MQGET call as part of a unit of work, and subsequently backed out. It is provided as an aid to the application in detecting processing errors that are based on message content. The count excludes MQGET calls that specified any of the MQGMO_BROWSE_* options.
The accuracy of this count is affected by the HardenGetBackout queue attribute; see Chapter 40, Attributes for queues.
On z/OS, a value of 255 means that the message has been backed out 255 or more times; the value returned is never greater than 255.
On VSE/ESA, this is a reserved field.
This is an output field for the MQGET call. It is ignored for the MQPUT and MQPUT1 calls. The initial value of this field is 0.
|
You will have to browse the queue using some tool and look at this field. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
AYSC |
Posted: Tue Jul 12, 2005 5:56 am Post subject: |
|
|
Newbie
Joined: 12 Jul 2005 Posts: 8
|
jefflowrey wrote: |
AYSC wrote: |
Where i can check that value ? |
I guess technically, it is the Backout count that I meant,
Application Programming Reference, Chapter 10 MQMD wrote: |
BackoutCount (MQLONG)
Backout counter.
This is a count of the number of times the message has been previously returned by the MQGET call as part of a unit of work, and subsequently backed out. It is provided as an aid to the application in detecting processing errors that are based on message content. The count excludes MQGET calls that specified any of the MQGMO_BROWSE_* options.
The accuracy of this count is affected by the HardenGetBackout queue attribute; see Chapter 40, Attributes for queues.
On z/OS, a value of 255 means that the message has been backed out 255 or more times; the value returned is never greater than 255.
On VSE/ESA, this is a reserved field.
This is an output field for the MQGET call. It is ignored for the MQPUT and MQPUT1 calls. The initial value of this field is 0.
|
You will have to browse the queue using some tool and look at this field. |
Ah, that one... The value is 0. For all messages in queue.
It is more like.... that the flow doesn't start to get the messages. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jul 12, 2005 6:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
What is the Open Input Count of the queue? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
AYSC |
Posted: Tue Jul 12, 2005 6:06 am Post subject: |
|
|
Newbie
Joined: 12 Jul 2005 Posts: 8
|
jefflowrey wrote: |
What is the Open Input Count of the queue? |
2 open input count. And this is strange... Why 2?
But there is another flow... blocked, and that flow have 1 open input count. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jul 12, 2005 6:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
|
Back to top |
|
 |
JT |
Posted: Tue Jul 12, 2005 6:26 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003 Posts: 1564 Location: Hartford, CT.
|
Do you anything connected to the Catch terminal of the MQInput node?
If so, what?
If not, attach a Trace node, set the path/filename, and add the pattern ${ExceptionList}. |
|
Back to top |
|
 |
AYSC |
Posted: Tue Jul 12, 2005 7:36 am Post subject: |
|
|
Newbie
Joined: 12 Jul 2005 Posts: 8
|
JT wrote: |
Do you anything connected to the Catch terminal of the MQInput node?
If so, what?
If not, attach a Trace node, set the path/filename, and add the pattern ${ExceptionList}. |
Yeap, i have a failQ on the catch exit. No messages going to fail.
The point is that i have it in PROD env, in test/develop everything going right. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Jul 12, 2005 1:23 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Yeah, we run into this. Flows say they are running, the q is open, but the messages pile up, and there are no errors. Stopping and starting the flows does squat.
We Right Click on the EG, Remove deployed children, and then redeploy a new bar file.
What a pain.....
In WB-IMB 6.0, stopping a flow will actually stop the flow (release queue handles and everything). Today, its more of a PAUSE, when it works. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
AYSC |
Posted: Wed Jul 13, 2005 12:08 am Post subject: |
|
|
Newbie
Joined: 12 Jul 2005 Posts: 8
|
So, i have some msg...
User Trace is giving me:
"Unable to open MQ queue" catalog="BIPv500"
I think this is a problem...
Suggestions ? |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jul 13, 2005 3:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Did you try Peter's suggestion of completely undeploying the bad flows, and deploying them with new BAR files?
Also, you should (from some level of tracing) be able to get an RC/CC for that "unable to open queue" message. So try increasing the trace.
You have ensured that the broker service user has the proper MQ permissions for these queues, right? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
JT |
Posted: Wed Jul 13, 2005 4:53 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003 Posts: 1564 Location: Hartford, CT.
|
Quote: |
"Unable to open MQ queue" catalog="BIPv500" |
Also, post the entire error message. |
|
Back to top |
|
 |
|