| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| trigger type Every |
« View previous topic :: View next topic » |
| Author |
Message
|
| jefflowrey |
 Posted: Thu Aug 23, 2007 8:04 am Post subject: Re: Peter's response on Triggering |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| George Carey wrote: |
| instead on a too frequently seen smarmy, glibness. |
Plain text does very little to convey intention or emotion.
What you may read as 'smary glibness', others may read as 'dispassionate terseness' or 'humorous sarcasm' or 'venomous personal attack', and may have been written as 'wry helpfulness'.
Also, you did not need a comma between 'smarmy' and 'glibness'.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| DaveHoffsommer |
| Posted: Tue Sep 04, 2007 10:08 am Post subject: |
|
|
Newbie
Joined: 17 Oct 2005
Posts: 3
|
There are several issues here which never seem to be discussed in relation to this topic. In the context of CICS applications, we have had a major problem in statistics. A few tasks that process with trigger FIRST can run for hours without stopping (when under heavy load). For these processes we cannot generate any meaningful statistics from the CICS end as to how each individual transaction is performing. Or identify if one of them is having a problem. We can measure overall throughput from the sending end, but that doesn't help identify problems or bottlenecks from the CICS side. We've reached a compromise by using trigger FIRST, using CICS to limit the max number of concurrent transactions, and each application checks the queue depth prior to the read and if it's greater than one, sets itself up to read that many times (or until 2033). That way we generally process one transaction per request yet still clean up any orphaned messages. Of course under heavy load we still get the occasional transaction that processes two messages and the resultant transaction that gets a 2033 on the first read and exits without doing any work, but we do get a much better picture of how CICS is behaving than with single-threaded long-running transactions.
Cheers,
Dave |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 05, 2007 4:04 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Dave,
Checking a q depth and then doing that # of MQGETs is a common mistake newbies make when programming MQ apps. I'm not saying you are one, just that this is a bad design.
You do an MQINQ and get 5:
Some of them may expire before you get to them - 5 was too high
Some of them may be uncommitted - 5 was too high
New ones may arrive - 5 was too low
I don't think you have a major problem here because you code to loop until 2033. Its just that if you are going to read until 2033 doing the MQINQ buys you zero and is just extra code and cycles for no gain.
Not big enough a problem to recode the thing, but I did want to mention it so someone doesn't come along and design a new app this way.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| DaveHoffsommer |
| Posted: Thu Sep 06, 2007 5:13 am Post subject: |
|
|
Newbie
Joined: 17 Oct 2005
Posts: 3
|
Yeah, it's not the best but it was the only thing we could think of to solve the problems. If we used trigger FIRST we had problems where transactions were delayed because of one mis-behaving transaction waiting on database resources would block all the following transactions. Or, worse, the occasional transaction abend would cause all processing to screech to a halt. We couldn't set the TRIGINT parameter low enough because it's on a queue manager level and it would cause other long-running transactions to start multi-threading, which we didn't want to happen.
Just triggering EVERY has the issues mentioned throughout this thread. I suppose if a developer really knew what they were doing and designed a system from scratch using MQ as a transport layer then things would be better. Our problem is that most of the systems are older systems originally communicating through SNA and have been re-fitted to use MQ. The few new ones were, unfortunately, modelled after the retro-fitted ones. As I don't usually get any input in the design phases I just get to try and keep things running once they hit Production.
Cheers,
Dave |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
