| Author |
Message
|
| rconn2 |
 Posted: Thu Jan 10, 2008 7:53 am Post subject: JMS Client MessageListener trigger / event notifier? |
 |
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
I read about a support pack that provides a client-trigger. But, that approach seems good only where there are few client triggered queues.
We have a case where there will be many clients, each with its own assigned queue. A trigger monitor (from my understanding) would be run on each client machine and would monitor an inititation queue. But, these would have to be initiation queues also assigned to each client. For example, if we had 100 client assigned queues, we'd need 100 client initiation queues.
I'm trying to figure out a different solution now, w/out using initiation queues... would a MessageListener work? I'm thinking of sending the process to be called as a command line argument to a JMS app, and then call that process in the onMessage method. I want the called process to get the message. So, the onMessage must leave the message on the queue... and just be used as a message-has-arrived-event notifier.
Would using CLIENT_ACKNOWLEDGE when creating the session for the listener work? Anyone else come up w/ something like this or have any ideas? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Jan 10, 2008 7:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can use one initiation queue, and one trigger monitor.
You may need to use LOTS of process definitions, though.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 10, 2008 9:35 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Jeff, isn't the default client trigger monitor restricted to starting up processes on the machine its running on? So when you say 1 TM and 1 INITQ, you mean a custom trigger monitor that can fire up processes on remote machines, and the process definitions would contain the hostnames?
I don't think MA7K can do this as-is, right?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 10, 2008 11:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm sorry - was there something in the original message that said the clients were going to run on their own machines?
I'd thought they were going to run on one machine.
I wonder if you can use a dynamic queue as an initiation queue?
No, MA7K in it's current incarnation can't start a process on a remote machine.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rconn2 |
| Posted: Fri Jan 11, 2008 7:54 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
| test -- I can't post to this thread |
|
| Back to top |
|
|
| rconn2 |
| Posted: Fri Jan 11, 2008 7:56 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
Jeff - sorry. Yes, the clients are different machines connecting to a commonly accessbile queue manager on a different machine. And each client has it's own assigned queue.
i.e. machine1.LQ machine2.LQ etc.
So, each client-machine and client-queue would need a corresponding initiation queue. |
|
| Back to top |
|
|
| rconn2 |
| Posted: Fri Jan 11, 2008 7:58 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
I did try using a JMS MessageListener w/ the session set to CLIENT_ACKNOWLEDGE.
In the onMessage method, it calls: |
|
| Back to top |
|
|
| rconn2 |
| Posted: Fri Jan 11, 2008 7:59 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
Runtime rt = Runtime.getRuntime
Process proc = rt.exec "test.cmd"
int exitVal = proc.waitFor
The test.cmd script then calls a java app to get and process a single message on the queue that is being listened-to.
This doesn't work as the 2nd message processing app (which does an AUTO ACK) doesn't find any messages on the queue.
The basic idea is that I'd like to have a generic message listener app that I can assign to a queue, and have that listener call a process (whose name is passed as a parameter to the app) when a message arrives (event driven). The process that gets called would then handle the message. So, this would be like a client trigger except instead of using an initiation queue to find the process definition, the process definition is passed to the listener app.
I could put listener functionality into the java app that does message processing. But, that app is called by script that does further, dependent processing. I'd have to split things up and have two running background processes -- the listener/processing app and script that would have to check to see if it has new data (incoming files) to further process. |
|
| Back to top |
|
|
| rconn2 |
| Posted: Fri Jan 11, 2008 8:01 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
| sorry for chopping up my replies. The code sample above, when it had parentheses, was preventing my post from being accepted... said the server was temporarily down or had reached capacity. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jan 11, 2008 8:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So the usual mechanism for deciding between a listener pattern and a trigger pattern is - the usecase of the application.
Is this client application going to be running "unattended"? Is the client application going to be running all the time?
What is the pattern of expected message delivery - is it mostly request/reply, or is it mostly asynch? Do messages come in large groups at discrete times, or individually at random times over the course of a day?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rconn2 |
| Posted: Fri Jan 11, 2008 8:10 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
I just had a thought (happens from time to time  )...
Can the Client Trigger Monitor filter on the initiation queue? So, filter for messages triggered by messages arriving on a particular queue (the queue assigned to the client machine on which the particular Monitor is running)?
If so, then a problem might still be that there'd be many Monitors running on up to a hundred (in our case) machines all listening on the same initiation queue... but this might not be a problem... messages are sporadic... maybe several to a few dozen a day for all queues. |
|
| Back to top |
|
|
| rconn2 |
| Posted: Fri Jan 11, 2008 8:31 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
| I just realized MA7K is for Windows only... we're using AIX... I did a google and didn't find any client trigger monitors for unix. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jan 11, 2008 8:47 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| rconn2 wrote: |
| I just realized MA7K is for Windows only... we're using AIX... I did a google and didn't find any client trigger monitors for unix. |
There is a presupplied commandline program, that comes with Windows as well as all Unix MQ distribtuions, called "runmqtrc".
MA7K provides advanced, Windows, features compared to the runmqtrc. There isn't, that I'm aware of, a Unix equivalent.
I'm happy to take suggestions/requirements for a Unix version of MA7K. But I won't make any guarantees of implementation dates... 
Also, in MQ v6, most of what you get from MA7K on Windows is available through MQ Services.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 11, 2008 8:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| rconn2 |
| Posted: Fri Jan 11, 2008 9:05 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
Jeff - just saw your reply.
It's a file deployment system from a small number of source servers to many possible destination servers (which may involve one or more hops) across the enterprise. MQ is being used for security/networking reasons. (and, this'll also help us establish an mq infrastructure as a side-benefit.)
1. The file transfer is initiated manually by calling a unix script w/ arguments (file and destination). The file, as a message, is then put on a remote queue using a JMS app.
2. A destination client machine will get files from a queue assigned to it (also using a JMS app) and reply w/ an Ack. Then, other processing steps will occur. This 2nd step, should be automatic.
A. An initial design had a receiving script in #2, run in the background while looping and checking its assigned queue w/ a JMS app after an interval. This would be okay, except the requirement became for this to be run at high frequency (loop every 10 seconds). It's workable, but inefficient. The destination servers have other work to do besides this.
B. An event driven design for the receiving server would be best, and so a Listener or Trigger Monitor. These are client machines connecting to a separate queue manager, so the regular trigger monitor won't work.
i) The issue w/ a client trigger monitor is the number of initiation queues, or using one but applying different filters for each of the monitors that'll be running (one per client machine... in the 100's). Also, I don't know of any ready made code for a non-Windows client trigger monitor.
ii) I haven't been able to get a Listener on the assigned queue to drive another process that then gets the message. The called process (which calls a JMS app to save a message as a file) sees the queue as empty. That called process is a script that also does further processing.
iii) Bundle Listener functionality into the JMS app in ii) above -- the process that saves the message as a file. The problem w/ this approach is that the script that calls that JMS app also does further dependent processing. So, not only would the JMS app need to run in the background, but the part of the script that does further processing will also need to run and loop in the background to check for incoming files. |
|
| Back to top |
|
|
|
|
