| Author |
Message
|
| petermqiis |
 Posted: Wed Jun 17, 2009 6:53 am Post subject: |
 |
|
Novice
Joined: 17 Jun 2009
Posts: 10
|
Forgive me if I'm just being stupid but if 100 messages arrive and 100 triggered applications are started will there not be 100 totally isolated processes running? In that case each process must create its own http connection since they are isolated there can be no shared pool. Each of the processes will wait for its http response back from IIS before putting the response back on the queue. At that point it will exit but by then 100s more messages will have arrived triggering more instances.
There can only be a pool is there if there is one process managing that pool. But this is the scenario I don't want since it is a single point of failure. I'm happy for that single point to be IIS managing a pool of threads to service requests or some other application server. This seems like something I shouldn't be writing myself over and over but can get off the shelf. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Jun 17, 2009 6:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| petermqiis wrote: |
| Forgive me if I'm just being stupid but if 100 messages arrive and 100 triggered applications are started will there not be 100 totally isolated processes running? |
Only if you've configured the trigger in a seriously unrecommended way (unless you're using a mainframe which I think we can discount).
If 1/100/1000/10000 messages arrive when your applicaiton is not running, your application starts as a separate process to the trigger monitor with whatever connection pooling strategy it's coded to use. Exactly as if you'd started it from a command line, except the system is starting it on message arrival.
Once it's emptied the queue (if it empties the queue) it can then close down with the satisfaction of a job well done, saving resources.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Wed Jun 17, 2009 6:59 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| petermqiis wrote: |
| Forgive me if I'm just being stupid but if 100 messages arrive and 100 triggered applications are started will there not be 100 totally isolated processes running? |
It depends on the triggering mechanism used.... If you use "EVERY" then this could be the case, but with first it probably wont be. Using "FIRST" you could look at invoking your pooling app and have it read the messages until theres none left then exit (and re-trigger the next time a message arrives). |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 17, 2009 7:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WMBDEV1 wrote: |
| It depends on the triggering mechanism used.... If you use "EVERY" then this could be the case, but with first it probably wont be. Using "FIRST" you could look at invoking your pooling app and have it read the messages until theres none left then exit (and re-trigger the next time a message arrives). |
I couldn't have said it better myself, and wish I'd said it that well.
Note that in this scenario the re-triggering requires no intervention. In case you were worried. The application will be re-triggered automatically once the next batch of messages arrive on the queue.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| petermqiis |
| Posted: Wed Jun 17, 2009 8:47 am Post subject: |
|
|
Novice
Joined: 17 Jun 2009
Posts: 10
|
So the first instance disables triggering and then throws an exception and dies ...
what will cause triggering to be restarted? Seems like the whole system will be down again.
I'm sure these solutions work well enough for general usage but it's not a soluation to the essential problem of needing some type of generic manager overseeing the whole operation that is written once only and tested to death. If it were the case then apache, iis, all application servers wouldn't need to exist. We could just have happy processes listening out for http request as they choose. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 17, 2009 9:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| petermqiis wrote: |
| So the first instance disables triggering and then throws an exception and dies ... |
Did you even look at the documentation I suggested? The application instance started has no control over the triggering process which is under the control of the trigger monitor. There is one specific instance where triggering needs to be re-enabled by the application & that's not even slightly under discussion here.
| petermqiis wrote: |
| what will cause triggering to be restarted? Seems like the whole system will be down again. |
I made a specific point of posting that triggering didn't need manual intervention.
| petermqiis wrote: |
| I'm sure these solutions work well enough for general usage but it's not a soluation to the essential problem of needing some type of generic manager overseeing the whole operation that is written once only and tested to death. If it were the case then apache, iis, all application servers wouldn't need to exist. We could just have happy processes listening out for http request as they choose. |
You seem determined to mix technologies and software, as well as not reading the posts here. There is a raft of difference between JMS & http. If you decide not to follow this method and use an MDB running running under an app server then this is your design decision to make as I said above. But bear in mind an MDB doesn't poll in the way you originally suggest, but uses triggering via the onMessage method.
If you feel you need a generic manger overseeing the whole opperation then I recommend you implement that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| petermqiis |
| Posted: Wed Jun 17, 2009 11:14 am Post subject: |
|
|
Novice
Joined: 17 Jun 2009
Posts: 10
|
Sorry to invoke such a reaction. I have looked the documentation but it doesn't answer my questions.
Apologies for wasting your time. We'll look elsewhere for help on this matter. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 17, 2009 11:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| petermqiis wrote: |
| Sorry to invoke such a reaction. I have looked the documentation but it doesn't answer my questions. |
You should hear me when I get cross. 
Seriously - it is your requirement, your site and in the last analysis your decision on what to do. So you must produce a design which in your opinion is the one which best meets those parameters.
I do feel you've come to this with a preconcieved idea of how WMQ works and what needs to be done though.
| petermqiis wrote: |
| Apologies for wasting your time. We'll look elsewhere for help on this matter. |
I'm sorry I'm been unable to satisfactorially answer your questions, or adequately offer alternatives to you.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 17, 2009 12:31 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
Viewed another way:
If your app is written to open the triggered application queue and keep getting messages until there are no more messages (rc2033), then trigtype(first) should satisfy your requirement. The triggering process works like this:
1. you define an application queue as triggered; and in that definition
2. you specify an initiation queue where the event message (message arrived on triggered queue) is put
3. you specify (in a process definition) what application is to be launched when a message arrives, then
4. the trigger monitor application (a service task, and not necessarily associated with any particular application or queue) watches for the event message (an application message arriving in the triggered application queue), and
5. when an application message arrives in the triggered application queue,
6. the trigger monitor application starts the application
In answer to your specific concern, when the trigger fires (message arrives) AND trigtype(first), the qmgr triggering mechanism briefly turns triggering off; but turns it back on when queue depth returns to zero (when all messages have been consumed). Trigtype(first) ensures that no other instances of the consuming application will be launched.
Given your lack of experience with WMQ, I appreciate your skepticism.
However, given the tens of thousands of installed WMQ accounts around the world, the varied industries using WMQ, the pervasive use of triggers, and the depth and breadth of experience here at mqseries.net, I'd hesitate to dismiss WMQ as a solution so quickly.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jun 17, 2009 8:39 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
| In answer to your specific concern, when the trigger fires (message arrives) AND trigtype(first), the qmgr triggering mechanism briefly turns triggering off; but turns it back on when queue depth returns to zero (when all messages have been consumed). |
You missed mentioning a couple of other very important features of Trigger On First that petermqiss should be aware of to alleviate his concerns:
The QM will turn triggering back on if the app closes the queue and there are still messages on the queue.
Using Trigger Interval, if your app is triggered but dies before it gets a chance to open the queue, the QM will retrigger after Trigger Interval passes and another message lands.
In addition, you can have two trigger monitors on two different client servers, watching the same INITQ. They will race for the trigger messages the QM does generate. Only one will win. But if one of your client servers dies, you still have the other one watching your queues.
I assume one triggered thread will be able to keep up with the message arrival. There are ways to handle this if not, without resorting to using triggering every, which lacks the features of trigger first.
But dude,
| Quote: |
| This system will be processing upto 100 messages per second 24/7 |
This is not a case for triggering! When your server starts, your app starts, it opens the queue and then in works and works and works. Why should you ever close the queue with that kind of incoming volume. Triggering is for apps that deal with sporadic and occasional bursts of messages, not a constant stream of them.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 18, 2009 6:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| This is not a case for triggering! When your server starts, your app starts, it opens the queue and then in works and works and works. |
I think one of the key points from the poster is the fear that the app would start, open the queue and then work and work and fail..... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 18, 2009 7:05 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
If work means processing a message, then a loop wherein the application continues to get messages until the queue is empty (if ever), seems to be a good thing.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 18, 2009 7:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| If work means processing a message, then a loop wherein the application continues to get messages until the queue is empty (if ever), seems to be a good thing. |
I was using work in the "not abended" sense, and my phrasing was indeed ambiguous.
It's been a hard day in the real world...... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 18, 2009 8:46 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I was using work in the "not abended" sense |
I'd say that a well-written application is no more or less likely to abend with WMQ in the mix. Bad application coding is usually the source of abends.
| Quote: |
| and my phrasing was indeed ambiguous. |
Well, there you have it.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
