Author |
Message
|
rog552003 |
Posted: Mon Mar 13, 2006 2:46 pm Post subject: perform GET matching by UserID |
|
|
Novice
Joined: 11 Dec 2005 Posts: 11
|
Hello, greetings
I would like to know if anyone knows how to perform a get from a queue, but only the messages that belongs to a certain user, in the field userID whithin the message descriptor.
I know i can do this with the match_messageId or the matchCorrelationId, can i do it with the userId?
Thanks for the help!!! |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Mar 13, 2006 2:53 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
No. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Mar 13, 2006 2:58 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
To expand a little more.
The only options you can match against using the Get are Message ID and Correlation ID.
If you need to seperate messages by other criteria, either you should put all the logic that handles those different scenarios in one program, or you should implement a filter that will distribute messages to different queues based on that criteria.
If you are looking at UserId, though, maybe you are doing a request/reply scenario. In that case, you can look at temporary dynamic queues, which will ensure that each user has a private queue to receive replies in but does not require manual adminstration to create or maintain. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Mar 13, 2006 4:57 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Little bit of a problem here. I just hope that none of his messages are persistent (because I don't believe a temporary dynamic queue will accept persistent messages).
The next step is to really read up on the request / response pattern and go for messageid/correlationId. Or separate by replyto queue (whether temporary or permanent (queue local))
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
briancop |
Posted: Tue Mar 14, 2006 3:40 am Post subject: JMS selector? |
|
|
 Apprentice
Joined: 04 Apr 2005 Posts: 28 Location: Hursley, UK
|
> I would like to know if anyone knows how to perform a get from a queue, but only the messages that belongs to a certain user, in the field userID whithin the message descriptor.
> I know i can do this with the match_messageId or the matchCorrelationId, can i do it with the userId?
Since this is the Java / JMS forum, are you using MQ Classes for Java, or are you using JMS? If the latter, you could specify a selector when you create your message consumer. Something like: 'JMSXUserID IN ......' |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Mar 14, 2006 5:45 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
You certainly can.... but you won't like the performance!  _________________ MQ & Broker admin |
|
Back to top |
|
 |
rog552003 |
Posted: Tue Mar 14, 2006 9:05 am Post subject: |
|
|
Novice
Joined: 11 Dec 2005 Posts: 11
|
Hello,
Yes, i'm using MQ Classes, not JMS. Even if the performance is poor, can i make this filter without programming the logic? perharps with a browse?
Or am I lost and i shoud start programming code to filter messages using userId, perhaps with an intermediate structure like a hashmap, because using dynamic queues is really dangerous in the environment i'm using. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Mar 14, 2006 9:24 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
rog552003 wrote: |
Yes, i'm using MQ Classes, not JMS. Even if the performance is poor, can i make this filter without programming the logic? perharps with a browse? |
No. MQ will not provide any logic for filtering or sorting messages on a queue other than first in/first out and match msgId or match correlationId.
rog552003 wrote: |
Or am I lost and i shoud start programming code to filter messages using userId, perhaps with an intermediate structure like a hashmap, because using dynamic queues is really dangerous in the environment i'm using. |
You will have to write code.
You can either write code that will use more than one queue - one "input" queue and many "output" queues (for each userId). Or you can write code that will browse the entire queue looking for messages for a particular userID and then lock and GET that message by messageID.
Or you can describe your scenario in a wider detail and we can maybe give you a better solution.
Why do you need to distinguish messages by userID, anyway? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Mar 14, 2006 1:54 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
rog552003 wrote: |
Yes, i'm using MQ Classes, not JMS. Even if the performance is poor, can i make this filter without programming the logic? perharps with a browse? |
Sure, that's all JMS selectors do anway. Just open the queue, start browsing messages with a lock, and when you get to one that meets your criteria, do a destructive get on the locked cursor.
Performance will be worse the deeper the q gets.
The real question is, why do you need to select by this criteria (i.e. if it was a good idea, base MQ would have given you this option a long time ago.)? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mvic |
Posted: Tue Mar 14, 2006 4:07 pm Post subject: |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
PeterPotkay wrote: |
The real question is, why do you need to select by this criteria (i.e. if it was a good idea, base MQ would have given you this option a long time ago.)? |
Agreed. In a point-to-point system design, the facility exists as per jeff's suggestion, which IMHO is worth repeating.
"If you need to seperate messages by other criteria, either you should put all the logic that handles those different scenarios in one program, or you should implement a filter that will distribute messages to different queues based on that criteria."
Does the system design really require this queue to hold messages destined for multiple endpoints? Or could you have (eg.)
Code: |
incoming message -> Q
|
read by gatekeeper app -> blue messages -> Qblue
|
green messages -> Qgreen |
|
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Mar 14, 2006 5:41 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
mvic wrote: |
Or could you have (eg.)
Code: |
incoming message -> Q
|
read by gatekeeper app -> blue messages -> Qblue
|
green messages -> Qgreen |
|
Looks like content based routing - A perfect use for WB-IMB if the sending app can't be changed. Hopefully your shop has it. Otherwise you will have to code it in the sender. Browsing by the getter as I described is truly a last resort if you have to get by User ID (why do you need that again?). _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mvic |
Posted: Wed Mar 15, 2006 2:22 am Post subject: |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
Quote: |
Otherwise you will have to code it in the sender. |
Why so? The gatekeeper approach I "drew" is a way of doing content based routing without disturbing the sender app, and (importantly) without resorting to browsing a deep queue. It works best if there is one app processing blue messages, and one - separate - app processing green messages. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Mar 15, 2006 4:55 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Your referance to a gatekeeper app and mine to WB-IMB are the same. An intermediate application that handles the routing, so that the sender does not have to change. If WB-IMB is N/A, and a homegrown gatekeeper app can't / won't be written, then the sender needs to code it.
Or, I suppose you could install an API exit on the Queue manager and have it do this. That seems extreme though. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mvic |
Posted: Wed Mar 15, 2006 5:00 am Post subject: |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
PeterPotkay wrote: |
Your referance to a gatekeeper app and mine to WB-IMB are the same. |
Yes. Except with regard to cost  |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Mar 15, 2006 5:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
mvic wrote: |
PeterPotkay wrote: |
Your referance to a gatekeeper app and mine to WB-IMB are the same. |
Yes. Except with regard to cost  |
And reliability and maintainability and support and development time and ... Cost up front is not the same as TCO! _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
|