| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Querying a queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| klamerus |
 Posted: Fri Sep 08, 2006 3:48 pm Post subject: Querying a queue |
 |
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
We have the scenario where an end-user wants to to cancel a request that has been queued for processing. The queue used may be up to 100,000 messages in length.
For instance, we might get a request to cancel a request placed between 10:00 and 11:00 for customer 12345. It would be great to submit a query to MQ to select all messages between these times where the message body contains text 12345. Ideally, you could select an entire set of messages (or message IDs) that met the criteria.
Right now, we pull back every message from the queue manager (across the network) for filtering by a "selection" application.
There doesn't happen to be some mechanism in MQ itself that we've missed where we can direct the queue manager to do this work for us is there? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Sep 08, 2006 7:04 pm Post subject: Re: Querying a queue |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| klamerus wrote: |
We have the scenario where an end-user wants to to cancel a request that has been queued for processing. The queue used may be up to 100,000 messages in length.
For instance, we might get a request to cancel a request placed between 10:00 and 11:00 for customer 12345. It would be great to submit a query to MQ to select all messages between these times where the message body contains text 12345. Ideally, you could select an entire set of messages (or message IDs) that met the criteria.
Right now, we pull back every message from the queue manager (across the network) for filtering by a "selection" application.
There doesn't happen to be some mechanism in MQ itself that we've missed where we can direct the queue manager to do this work for us is there? |
No there is no easy way. But if this type of search is a common occurrence why don't you modify your sending app to record customer, timestamp and msgid into a DB. If then you need a specific message you can always go by messageId.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Sep 09, 2006 5:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yeah, I would have the process that receives the cancel requests put them in a database or something. Then the process that reads the messages can check if the current message is cancelled and just not process it.
Also, if you really have queues backed up to 100,000 or more messages... unless you've got batch processes coming on line all at once... you probably want to scale up your processing applications.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| klamerus |
| Posted: Sat Sep 09, 2006 6:36 pm Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
These are batch processes. The queues aren't so much backed up, as the work is CPU intensive and dependent upon external systems which can be qutie slow (FAXing). Other queues aren't so long.
The great thing would be something built into the MQ manager that could perform a query and return the results. It should be pretty quick since it's managing the data on the same box.
We also query other queues for a variety of things. We keep a backup of all the work processed in a queue with expiry of 1 week (and then browse to clean it up). It's not uncommon for something to have had an issue and the queries we get in that case are asking about what data was given to the system that may have resulted in a failure.
The needs vary, but the technical solution of a query capability performed server-side would be very handy. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sun Sep 10, 2006 3:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Again, I'd use a database for anything that resembles "long time storage+query".
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
