Author |
Message
|
kumar777_WMB |
Posted: Wed Mar 07, 2012 3:47 am Post subject: Timer nodes consuming 1/5th of CPU utilisation |
|
|
Newbie
Joined: 07 Mar 2012 Posts: 2
|
Hi Friends,
Is timer node consumes more cpu utilisation for triggering after waiting 60 more seconds if there is no response from back-end. It is happening in my current scenario. Could you please share your better solution or thoughts to improve the utilisation.
Thanks,
Swarna Kumar |
|
Back to top |
|
 |
zpat |
Posted: Wed Mar 07, 2012 4:51 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Check your timer queues - do they have messages with high backout counts? This could indicate that you are repeatedly trying to process the same message (and transactionally rolling back each time).
If so, there is an APAR fix to allow a backout threshold to be optionally set on a timer queue, this prevents indefinite repeated processing. |
|
Back to top |
|
 |
kumar777_WMB |
Posted: Wed Mar 07, 2012 7:18 pm Post subject: |
|
|
Newbie
Joined: 07 Mar 2012 Posts: 2
|
You mean SYSTEM.BROKER.TIMEOUT.QUEUE? i have checked there is no blackout threshold configured on that queue. This Time out flow is the parlell flow will be monitor on the some X queue which has to be cleared if the response has come from the back-end system for the another business flow. If that don't clear, then this time out flow will trigger after certain time based on the control information and check weather got the response and clear the X queue. If time out flow find the message for that msgId on X queue, This flow will notify to the front-end that response hasn't come from back-end. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Mar 07, 2012 8:53 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
kumar777_WMB wrote: |
You mean SYSTEM.BROKER.TIMEOUT.QUEUE? i have checked there is no blackout threshold configured on that queue. This Time out flow is the parlell flow will be monitor on the some X queue which has to be cleared if the response has come from the back-end system for the another business flow. If that don't clear, then this time out flow will trigger after certain time based on the control information and check weather got the response and clear the X queue. If time out flow find the message for that msgId on X queue, This flow will notify to the front-end that response hasn't come from back-end. |
This is IMHO an awful design.
You should look into message expiration, which will automatically clear the outdated responses... MQ's timeout on receive(long) (with wait) should be enough for the front end...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
zpat |
Posted: Wed Mar 07, 2012 10:24 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
kumar777_WMB wrote: |
You mean SYSTEM.BROKER.TIMEOUT.QUEUE? i have checked there is no blackout threshold configured on that queue. This Time out flow is the parlell flow will be monitor on the some X queue which has to be cleared if the response has come from the back-end system for the another business flow. If that don't clear, then this time out flow will trigger after certain time based on the control information and check weather got the response and clear the X queue. If time out flow find the message for that msgId on X queue, This flow will notify to the front-end that response hasn't come from back-end. |
Of course there is no backout threshold set now. It's a new feature to allow it to set by YOU (after the PTF is applied).
I asked if you have messages on the queue with a high backout count in the MESSAGE. |
|
Back to top |
|
 |
|