| Author |
Message
|
| Vin |
 Posted: Tue Feb 08, 2005 7:00 pm Post subject: running the trigger monitor process in background on windows |
 |
|
Master
Joined: 25 Mar 2002
Posts: 212
Location: India
|
| I have a trigger monitor running on windows and would like to know how to make it multi-threaded. Right now what is happening is that my messages are put on the trigger queue and are processed sequentially instead of in parallel and as a consequence if there a bunch of messages sitting in the queue, the responses for the last message will be sent after a while!! |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Tue Feb 08, 2005 7:49 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Sounds like you need Trigger Type of Every instead of Trigger Type First.
Make sure your app, when triggered, loops on the queue until it gets a 2033, regardless of whether it is trigger Every or First.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 09, 2005 5:01 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Err.
Actually, I still wouldn't recommend Trigger Every.
I'd just say that he needs to cause his processes to be executed in the background, using "start" or "&".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vin |
| Posted: Wed Feb 09, 2005 8:50 am Post subject: |
|
|
Master
Joined: 25 Mar 2002
Posts: 212
Location: India
|
| thanks for the replies, but I did try putting the ampersand '&' at the end of the process 'java -cp ......... JavaTrigger &' in the process definition but still the execution seems to be serialized, tried putting the & in the userdata field too |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 09, 2005 9:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
& doesn't work on Windows.
You need to use "start" at the front, like "start java...".
Edit: Whenever trying to get a process definition correct, try the full command from the command prompt FIRST. Then when it works that way, run the trigger monitor in a foreground command shell to watch what it does.
THEN when it works THAT way, try a background trigger monitor.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Feb 09, 2005 10:37 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| I'd just say that he needs to cause his processes to be executed in the background, using "start" or "&" |
But won't that still only start a single process that works it's way through the queue.
It sounds like Vin wants to spawn off multiple copies of the process to handle the messages in parallel. In which case, either Trigger Every, in combination with running in the background, or a Traffic Cop type application needs to be triggered, that spawns off the required processes to handle the messages.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 09, 2005 12:13 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It's not clear from his question, actually.
But I'd still recommend the Traffic Cop approach over the relatively unreliable Trigger Type Every approach.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vin |
| Posted: Wed Feb 09, 2005 1:49 pm Post subject: |
|
|
Master
Joined: 25 Mar 2002
Posts: 212
Location: India
|
| Thanks for the correction jeff, it seems to be working now, also wanted to ask you why you think trigger type EVERY is unreliable |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 09, 2005 1:51 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Vin wrote: |
| Thanks for the correction jeff, it seems to be working now, also wanted to ask you why you think trigger type EVERY is unreliable |
Because it is documented that the triggering process may only put one trigger message to the initiation queue in certain cases where more than one message has arrived on the triggered queue - and thus it's not guaranteed to be "EVERY".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Feb 09, 2005 6:07 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jefflowrey wrote: |
| Vin wrote: |
| Thanks for the correction jeff, it seems to be working now, also wanted to ask you why you think trigger type EVERY is unreliable |
Because it is documented that the triggering process may only put one trigger message to the initiation queue in certain cases where more than one message has arrived on the triggered queue - and thus it's not guaranteed to be "EVERY". |
And why I said:
| Quote: |
Make sure your app, when triggered, loops on the queue until it gets a 2033, regardless of whether it is trigger Every or First.
|
Trigger Every is used incorrectly 99% of the time in cases where Trigger First would be adequate. And in 90% of the cases where it is called for, the triggered apps are not correct. Thus it has a bad rep.
In cases where your triggered process takes so long on Message1, that you need additional processes spawned to concurrently handle Messages 2 and 3, then Trigger Every will work. Yes, there are rare cases where you will not get a trigger message for each and every app message, causing a rolling back log of messages. (Message 1,2,3,4 are on the queue, and there is no trigger (reason not important). Message 5 lands. One trigger message is produced. App get #1. Now 2,3,4 and 5 are stranded. And the process continues. You are always behind).
But if the app is properly written, and reads until 2033, you have no problem. When you get into the above scenario, the next instance of the app that is spawned off by #5 landing will consume 1 thru 5 and you are clean again.
It is a simple, easy, out of the box way to get parallel processing.
Having said all that, a safer more scalable way is to Trigger On First, and kick off a Traffic Cop app that monitors the depth of the incoming app queue and spawns off more children processes whenever the depth goes over 1. Writing this traffic cop app so that it is bullet proof is not for everyone, which is why trigger every can be used. But only in cases where you really need that parallel processing. When you really study these cases, 99% of the time a well written single trigered app is more than enough, and you can go with the safer Trigger On First.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 09, 2005 6:35 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| When you really study these cases, 99% of the time a well written single trigered app is more than enough, and you can go with the safer Trigger On First. |
Which is why I said "recommend"... 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
