Author |
Message
|
djaedrol |
Posted: Mon Jun 20, 2011 12:00 am Post subject: Selective reading with mq series |
|
|
Newbie
Joined: 19 Jun 2011 Posts: 6
|
I would like to know if it's possile to have selective reading with mq series?
Thanks you in beforehand. |
|
Back to top |
|
 |
mvic |
Posted: Mon Jun 20, 2011 12:04 am Post subject: Re: Selective reading with mq series |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
djaedrol wrote: |
I would like to know if it's possile to have selective reading with mq series?
Thanks you in beforehand. |
MQ supports the JMS interface. You can use selectors with JMS. Is this an answer to your question? |
|
Back to top |
|
 |
djaedrol |
Posted: Mon Jun 20, 2011 12:09 am Post subject: |
|
|
Newbie
Joined: 19 Jun 2011 Posts: 6
|
Yes! I will check this, specially how to implement it. Thanks! |
|
Back to top |
|
 |
djaedrol |
Posted: Mon Jun 20, 2011 12:17 am Post subject: |
|
|
Newbie
Joined: 19 Jun 2011 Posts: 6
|
Sorry but i'm affraid your answer is not what i was waiting for. I've already used JMS interface to receive message(JMSReceiver). It seems that the principle to read message is : first in, first out. Then i would like to know if it is possible to change this principle for a selective reading? |
|
Back to top |
|
 |
mvic |
Posted: Mon Jun 20, 2011 12:42 am Post subject: |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
djaedrol wrote: |
Sorry but i'm affraid your answer is not what i was waiting for. I've already used JMS interface to receive message(JMSReceiver). It seems that the principle to read message is : first in, first out. Then i would like to know if it is possible to change this principle for a selective reading? |
Search the MQ Information Center for selectors.
Search Google for MQ JMS selectors. |
|
Back to top |
|
 |
djaedrol |
Posted: Mon Jun 20, 2011 1:45 am Post subject: |
|
|
Newbie
Joined: 19 Jun 2011 Posts: 6
|
|
Back to top |
|
 |
zpat |
Posted: Mon Jun 20, 2011 1:55 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Depends what you want to select on. Selectors have certain limitations.
You can browse the queue (optionally locking messages) and then get the message under the browse cursor when you find the one you want. |
|
Back to top |
|
 |
djaedrol |
Posted: Mon Jun 20, 2011 11:34 pm Post subject: |
|
|
Newbie
Joined: 19 Jun 2011 Posts: 6
|
Thank you for your advice. I appreciate it. |
|
Back to top |
|
 |
zpat |
Posted: Mon Jun 20, 2011 11:39 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
However in a request/reply design (using a pair of queues) you would get your own response message by getting with a match on correlid.
You would know the correlid because it should have been set from the msgid of the request message that you sent (by the server application).
All in all, the question is - what are you trying to achieve?
In any situation where you do not consume messages unconditionally - make sure that "unwanted" messages cannot build up over time - one way is to set an expiry value on them. |
|
Back to top |
|
 |
djaedrol |
Posted: Tue Jun 21, 2011 12:22 am Post subject: |
|
|
Newbie
Joined: 19 Jun 2011 Posts: 6
|
I would like consume message from a queue and manage the acknowledge. That mean that i should have this setting session = connection.createQueueSession(false, Session.CLIENT_ACKNOWLEDGE). The limit of this solution is the message may be read next time if there was not acknowledge before. So i should find a way to avoid this. I think the queue browser can be the solution : that mean i hope the next cursor value is independant of acknowledge. |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Jun 21, 2011 1:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
That sounds very confused.
If the message hasn't been acknowledged, how do you know for sure that it hasn't already been processed?
If you choose to do your own acknowledgment, you are accepting the risk of some message duplication.
And the right way to limit that is to tightly control your processing such that you ensure that when a message is NOT acknowledged, then it DOES need to be reprocessed.
Trying to use browse for this is the wrong idea. Because you can still browse the same message more than once.
You need to ensure that you know all of the error paths your code can take and then ensure that all of these error paths lead to the correct acknowledgment state for reprocessing the message. |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Jun 21, 2011 5:05 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
djaedrol wrote: |
I would like consume message from a queue and manage the acknowledge. That mean that i should have this setting session = connection.createQueueSession(false, Session.CLIENT_ACKNOWLEDGE). The limit of this solution is the message may be read next time if there was not acknowledge before. So i should find a way to avoid this. I think the queue browser can be the solution : that mean i hope the next cursor value is independant of acknowledge. |
I would have expected JMS to handle this seemless behind the scenes if you used following:
createQueueSession(true, Session.DEFAULT_ACKNOWLEDGE)
It is called a transaction...
 _________________ MQ & Broker admin |
|
Back to top |
|
 |
|