| Author |
Message
|
| smdavies99 |
 Posted: Tue Dec 21, 2010 2:55 am Post subject: MBTIME01 |
 |
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Is there somewhere that documents the contents/structure of this header?
WMQ Seems to understand it
We use Timeouts (SYSTEM.BROKER.TIMEOUT.QUEUE) to delay some processing and sometimes the delayed operation never gets reactivated. We are trying to scan the entries on the queue to pick up the errant messages and requeue them.
Yeah, I know this is not ideal but changing the whole mechanism is just not on.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
 |
| gs |
| Posted: Thu Dec 23, 2010 5:13 am Post subject: |
|
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
The lost timeout notifications, do they still reside as messages on the timeout queue? In that case you could browse them to see exactly what timeout information is stored.
All timeout information is stored in the payload...not a separate header.
Fiddling with the messages on the queue seems like a very dirty solution considering it's a broker internal queue. I'd rather place a PMR.. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Dec 23, 2010 9:34 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The 'lost' events are still on the Timeout Queue.
So I propose to indeed browse the queue (not using Broker) looking for the events that didn't fire. Then I'd sent the TimeoutRequest + payload to the broker wher a flow would CANCEL the event and then SET a new one.
A PMR is probably a good idea. However upon examining the code I see that whilst that date might change the actualt time of the event does not.
So we have a scenario where we could have 200+ events all firing off at the same time. It comes as no surprise to me that sometimes we miss one or two.
I need to try to replicate the problem in another environment to see if there is a limit to the number of simultaneous events that can be handled. However I know that this may well be influenced by other factors.
I've put forward a three line ESQL Fix that would spread the events over an hour rather that all going off at the same second. But I'm meeting resistance to its implementation as it is not a sure fire fix to the problem.
Despite the fact that the original code is just plain wrong.
This does highlight one thing though. There is no way to manage timeout events in the product. I'm coming round to thinking that this is a deficiency.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| gs |
| Posted: Thu Dec 23, 2010 10:05 am Post subject: |
|
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
Is the time exactly the same for the 200+ events?
Considering that the Date object has a resolution of milliseconds it sounds unlikely that you'd get the same time.
Could you describe the message flow and possibly post the code where you generate the timeout request in the localenv?
When doing an implementation using the timeout nodes some time ago I tested with a lot of messages in a short time span (burst) without any problems.. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 23, 2010 10:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| smdavies99 wrote: |
| However I know that this may well be influenced by other factors. |
First place to look is instances of TimeoutNotification...  |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Dec 23, 2010 10:57 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| gs wrote: |
Is the time exactly the same for the 200+ events?
Considering that the Date object has a resolution of milliseconds it sounds unlikely that you'd get the same time.
|
It goes something like this...
| Code: |
SET timRef.StartTime = '00:00:01';
|
So yes the times are all the same. As I said, it is hard coded. The time param in the struct is AFAIK, a CHAR not a TIME.
And yes because of the hardcoding the time is the same for all 200+ events.
| mqjeff wrote: |
First place to look is instances of TimeoutNotificationFirst
|
The issue is that if I increase the instance count of the flow then we risk breaking an SLA with a Large Search Engine who only allows us to send one request at a time.
I'd like to re-engineer the whole thing but that takes a lot more money than 'fixing' the problem and the bean counters don't like spending it for maybe 10-20 missed events a month out of 4-5000.
For me, even one missed event is one too many.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 23, 2010 11:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Multi-thread TimeoutNotification, feed it to MQOutput. Single-thread MQInput... |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Dec 23, 2010 11:24 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
| Multi-thread TimeoutNotification, feed it to MQOutput. Single-thread MQInput... |
Exactly what I was thinking but... this would be a design change and not a bug fix which naturally comes out of a different bean counters pot of gold.
I'm still minded to get the times spread over an hour as I can probably get this in as a bug fix.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Dec 23, 2010 11:24 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
| Multi-thread TimeoutNotification, feed it to MQOutput. Single-thread MQInput... |
Exactly what I was thinking but... this would be a design change and not a bug fix which naturally comes out of a different bean counters pot of gold.
I'm still minded to get the times spread over an hour as I can probably get this in as a bug fix.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
