| Author |
Message
|
| HenriqueS |
 Posted: Tue Jan 16, 2007 10:06 am Post subject: triggering Java apps - lightweight manner |
 |
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Folks,
I´ve got to design an app that consumes messages that arrive continously in a queue.
I´ve thought on 3 ways to accomplish that, but let´s focus in the 1st one I had in mind.
I thought in creating a process definition to call a Java app. The issue here is that I have no idea of how MQ behaves when I set:
a) The Application Type to Java
b) The Application Id
I do not want the overhead of loading the JVM everytime. And I am an optimistic person and I want to believe that IBM designed something that DOES NOT forces me supplying a comand line call ("jvm.exe myclass.class") in the "Application Id" field for doing that. But all the docs seems towards this!
The smart way could be contacting and already loaded JVM that has the class pre-loaded (like if it is under the context of an app server). But is it the way it works? All the docs I´ve browsed seem scarce about this issue (Application Types / Application Id behaviour). |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Jan 16, 2007 10:24 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
MQ triggering is only capable of starting a new process.
If your messages are really arriving continously on the queue, you can design your application to consume messages until it gets a 2033 and then execute another GET with a longer wait, to see if more messages show up.
This will limit how often your program exits, and thus limit how often a new trigger event occurs... and thus limit how often a new JVM is created.
If you don't like this idea, then don't use triggering at all. Use, for example, a custom service definition in MQ V6 to ensure that your program starts up when the queue manager does and stops when the queue manager does. This would also require some design consideration in your application.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Jan 16, 2007 10:31 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 16, 2007 10:32 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| RogerLacroix wrote: |
| Or simply write a Java Daemon that sits reading the queue forever. |
I guess that's what I meant for my option of configurable service. I left out that the program should run forever...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Tue Jan 16, 2007 11:54 am Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Thanks,
We´ve got to some architecture here that looks like this:
| Code: |
MQ -------> MQEntry Process --------------> Kernel
| ^
| msg |
------------------------------------------|
|
Well, the MQEntry Process should be the "daemon" that sticks reading forever the MQ server. But it actually does not consume any messages, just notifies the Kernel object which is goign to pull the message from the queue.
Some people have avoided the idea of a "daemon" and expected to use the triggering mechanism oferred by MQ. But we are almost 100% that every process definition implies in a new JVM process being started, what gives a considerable overhead on the server just to run a small class.
Anyhow, there was some common sense about MQEntry being as light as possible. We even considered MQEntry being a C app so it could be called many times (using the triggering) without considerable overhead. In this case it would issue some socket call to the kernel object, notifying that the queue is available for a GET.
It may look that MQEntry is an unnecessary component, but the Kernel actualy is going to interact with other input and output components such as FTP and a proprietary file-transfer utility that we have here...
At the very beginning we avoided to use any C language based triggers due maintainability.
We also thought on making the opposite, throw off this triggered-notifying mechanism and make the Kernel by itself pooling the MQ queues every n seconds or using a JMS listener. But since the Kernel is going to run under a J2EE context, some people freaked about this sort of loop-based processing, saying it is not a good J2EE practice, etc. and that it may overhead the Kernel role.
Any comments? Any ideas? Which approach do you guys think is the better? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 16, 2007 11:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You've basically written your own trigger monitor.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Tue Jan 16, 2007 12:52 pm Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
| jefflowrey wrote: |
| You've basically written your own trigger monitor. |
Still, I think that this Kernel thing (that talks with different input sources) pushed us to do that.
Which one of the approaches (to make the Kernel to GET from the queues) I cited do you think are worth?
a) Java, daemon, pooling (timer, notifying the kernel if finds anything) based MQEntry?
b) Java, daemon, JMS Listener (every new message notifies the kernel event) based MQEntry ?
c) Java, MQ triggered (every triggered condition starts JVM MQEntry.class that notifies the Kernel), based MQEntry ?
d) C, MQ triggered (every triggered conditions starts C program that notifies the Kernel thru sockets), based MQEntry ? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 16, 2007 12:59 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
My tendancy would be to encapsulate MQ entirely - so that the MQEntry would actually consume the message, and pass a data object of some kind into the Kernel. Do likewise with the other input sources.
And then I'd make MQEntry a daemon thread of the Kernel JVM that was doing some kind of continuous GET with WAIT (and FAIL_IF_QUIESCE).
I wouldn't have MQEntry do any kind of RMI to the Kernel.
Either that... or I would not bundle the other input sources into the same application. I'd build Kernel to act as an MQ listener of some kind, and only an MQ listener. And then the other input sources act as adapters, where they will process input from those other sources and then put them onto the MQ bus - where the kernel will read them.
Depending on the scale of this, you should consider something like WebSphere ESB instead of writing this yourself. Or if the data is not all XML, then WebSphere Message Broker.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Fri Jan 19, 2007 8:14 am Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
|
| Back to top |
|
|
|
|
