| Author |
Message
|
| sebastia |
 Posted: Thu Nov 08, 2007 2:39 am Post subject: can WILDCARD be used to search a message by (partial) MsgID? |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
We generate MsgID manually - that's a requirement.
The consumer does search the queue for a specific Message ID.
Now we do it sequentially ...
Can a "wildcard" be used if the consumer knows PART of the Msg ID ?
Thanks. Seb. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Nov 08, 2007 3:08 am Post subject: Re: can WILDCARD be used to search a message by (partial) Ms |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
| We generate MsgID manually - that's a requirement. |
It's a bad requirement. Search for the much repeated debates in the forum
| sebastia wrote: |
| The consumer does search the queue for a specific Message ID. |
This is another bad requirement. WMQ is not a database, should not be used as one and the consumer will get benefits (including faster searching) if the message contents are loaded into a database. This would also allow generated Msgids to be used.
| sebastia wrote: |
| Can a "wildcard" be used if the consumer knows PART of the Msg ID ? |
Not out of the box, but he could if you loaded the messages into a database. This is another benefit.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Thu Nov 08, 2007 3:16 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
But how does the remote machine
(that now has MQ Client only)
access that DataBase ???
( ) |
|
| Back to top |
|
|
| sebastia |
| Posted: Thu Nov 08, 2007 3:23 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Can't we use "GroupID" for this purpose ?
( and MQMO_MATCH_GROUP_ID ... )
I mean, is this field NOT USED by MQ if we generate MsgID manually ?
Seb. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Nov 08, 2007 3:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
But how does the remote machine
(that now has MQ Client only)
access that DataBase ???
|
By using a database client instead of an MQ one???
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Nov 08, 2007 3:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
| Can't we use "GroupID" for this purpose ? |
No, it's still an exact match not a wildcard.
WMQ is not a database. Wishing it was will not make it so. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Thu Nov 08, 2007 3:54 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
DataBase Client ?
No, no - that is software to install, licences, etc etc |
|
| Back to top |
|
|
| sebastia |
| Posted: Thu Nov 08, 2007 3:57 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Group Id - I did lie to you ...
We shall generate MsgID manually
( lets say ABCD12345768901234567890 )
and will generate manually also a GroupID
( lets say "ABCD" )
Now, the client can Get/Browse by ( complete ) GroupID,
( 4 letters )
but now this contains ONLY the Shop-code, without the extensions ...
I think we shall go this way ...
Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Nov 08, 2007 3:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
DataBase Client ?
No, no - that is software to install, licences, etc etc |
Then what you need is a home brew piece of software that can take a wildcard from your customers and match it against the msg id.
I hope the total cost of ownership for this, both in terms of development costs, maintenance costs and of impact on the queue manager in terms of performance comes out to be less than the license for some database client software for you. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Nov 08, 2007 4:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can't do any kind of wildcarding to select messages from MQ, on any field in the MQMD.
IF you use JMS, then JMS will allow you to write code that looks like it supports tihs.
IN FACT, though, the JMS Provider underneath does the same thing you are doing - reads each message off the queue in sequence, and does a compare. When it find a match, then it returns that message to the JMS code. It is therefore slow.
Any solution that you write to do this will have to work the same way, and will be slow.
Re-examine your requirements! There may be a better way to solve this problem.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Nov 08, 2007 4:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
I think we shall go this way ...
|
This is still a bad and horrible way to go. Performance will suffer because (in database terms) you're doing a tablescan on the queue.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Thu Nov 08, 2007 4:18 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Today. a linear table scan IS DONE.
We want to improve it.
We did generate a MsgID (manual)
and it works fine.
Now we need a "wildcard" browse.
As there is not such in MQ,
we can generate a "GroupID"
( if this field is NOT USED by MQ )
and do a Browse by this field
It is a "simulation" of a wildcard
but it looks OK to me ...
Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Nov 08, 2007 4:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
As there is not such in MQ,
we can generate a "GroupID"
( if this field is NOT USED by MQ )
and do a Browse by this field
|
The queue manager is still doing a tablescan down the queue, the only change is it's doing it on group id not on msg id. This will not affect performance.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 08, 2007 7:58 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
#1 How deep will this q get?
#2 Once the app selects it message off of the q, it will destructivly read it so the message is gone?
#3 In the above example where you say the Group ID will have ABCD, will there only ever be one message on the queue with ABCD?
#4 What if anything are you using the Correl ID field for? Why not use that over the Group ID?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| markt |
| Posted: Thu Nov 08, 2007 8:03 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
| The MQMD.GroupId can never be "ABCD". Just like all the other id fields, it's 24 bytes. Exactly 24 bytes. |
|
| Back to top |
|
|
|
|
