| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Browse when there is a message |
« View previous topic :: View next topic » |
| Author |
Message
|
| romulo.pereira |
 Posted: Fri Jan 19, 2007 9:14 am Post subject: Browse when there is a message |
 |
|
Newbie
Joined: 19 Jan 2007
Posts: 4
|
Hi,
Is there a method that only returns when there is a message in the queue but without consuming it?
It would be like the QueueReceiver.receive(TIMEOUT), but without consuming a message.
I know I could use the QueueBrowser, but then I would have to make many many calls to getEnumeration() until some message arrives...
Thanks, |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Jan 19, 2007 9:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
To what purpose?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| romulo.pereira |
| Posted: Fri Jan 19, 2007 9:31 am Post subject: |
|
|
Newbie
Joined: 19 Jan 2007
Posts: 4
|
My application must call a J2EE application to consume the messages. This J2EE application takes care o transaction, etc, so it is better for the retrieving process.
So, my application shouldn't consume messages, only discover when there are new ones.
And I wouldn't like to call the QueueBrowser.getEnumerate() a million times before a message arrives...
BTW, the J2EE application will consume the messages until it empties the queue. Then my application gets back into action... |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jan 19, 2007 9:55 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You're maybe talking about triggering a batch processing app - where the batch processing application is deployed in a J2EE container?
Maybe you should look at using a J2EE client application as "your" application. Then you can configure a client trigger monitor to start your J2EE client application - and it would invoke EJBs to start processing the queue.
But you really should have the J2EE process using MDBs - that way there's no need to delay any processing until someone else notices that there are messages.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| romulo.pereira |
| Posted: Mon Jan 22, 2007 9:11 am Post subject: |
|
|
Newbie
Joined: 19 Jan 2007
Posts: 4
|
Thanks for the help, jefflowrey.
Anyway, I decided to try MQ Base Java, and I think that the following code will do exactly what I want:
| Code: |
...
MQGetMessageOptions gmo = new MQGetMessageOptions();
gmo.options = MQC.MQGMO_WAIT | MQC.MQGMO_BROWSE_FIRST | MQC.MQGMO_FAIL_IF_QUIESCING;
gmo.waitInterval = MQC.MQWI_UNLIMITED;
MQMessage message = new MQMessage();
...
queue.get(message, gmo);
... |
So, the "get" method will wait undefinetely until a message arrives, and then sets the 'message' object, but without retriving the message (doesn't take the message out of the queue).
Right???
Thanks, |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 22, 2007 9:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You're essentially writing your own trigger monitor, I guess.
I don't think you're going down a good design path - but I don't know all your requirements. It looks like a bad design path from here, though.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| romulo.pereira |
| Posted: Tue Jan 23, 2007 1:50 am Post subject: |
|
|
Newbie
Joined: 19 Jan 2007
Posts: 4
|
OK. Let me explain in more details our design.
We have 300 queues.
A J2EE application will be responsible for retrieving the messages, as it implements transaction, which is better in order not to lose any message.
But, as a J2EE doesn't have a main() (right?), and therefore can't be triggered, some other application needs to be developed to call the J2EE application to consume the messages.
As we will develop this application in Java, it shouldn't be triggered, because the performance of it would suffer (the JVM would be initiated everytime).
So, the best thing is to use this application like a daemon, i.e., it would initiate once and then run forever.
That's why "You're essentially writing your own trigger monitor, I guess.".... 
The MDB alternative was considered by the analists in the past (I'm new to the project), but was rejected, because 1 instance of the J2EE application would be necessary to each queue or something like this (sorry, I don't remember exactly the reason...). As there are 300 queues, it would be too much J2EE applications running...
Well, I hope I have explained better now.
jefflowrey, now you can analyse better our case.
Do you still think it's a bad design?
If it is, help would be MUCH appreciated...
Thank you, |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 23, 2007 3:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Why do you have 300 queues, that all need to be read by the same application?
In the J2EE world, if you have the same business logic that needs to be performed by several different invokers, that's an EJB - probably an entity bean. Then all of your MDBs will invoke the entity bean, which could in theory be in a different container (although I wouldn't do that). Then the MDBs are small, and there's only one copy of the business logic running in the container.
Your J2EE architect should know that, and be screaming about doing it this way and be horrified at the notion of doing anything outside the J2EE container. Or at least, that's been my experience with J2EE architects.
In terms of everything else, you can't get most of the advantages of a J2EE application - transactionality and etc - outside of a J2EE container. A J2EE container is an application server. If you have standalone code that wishes to talk to a J2EE container, it is best to run that code in a J2EE application client.
So, again. 1) Reconsider why you need so many queues, 2) If you're using J2EE, use an App Server and 3) use MDBs and don't reinvent the wheel.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jan 23, 2007 3:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| Why do you have 300 queues, that all need to be read by the same application? |
I can only reinforce Jeff's question...
If you need this for security reasons or as concentrator just have them be alias or remote queues and point to one queue on the J2EE server.
Assuming there is no message affinity (and with a good design there should not be) you can now go and scale performance by determining the max number of instances of the MDB on the queue.
You really need to conform to the J2EE design...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
