| Author |
Message
|
| stephenboarder |
 Posted: Thu Dec 07, 2006 3:15 am Post subject: Remove x messages from an MQ queue using java app |
 |
|
Newbie
Joined: 07 Dec 2006
Posts: 9
|
I have a requirement to remove a specified number of messages from an MQ queue as part of a java application. Here is my code snippet;
public void purgeQueue(String queueName, int numberMsgs) throws UnableToProceedException {
int openOptions = MQC.MQOO_BIND_NOT_FIXED | MQC.MQOO_INPUT_SHARED | MQC.MQGMO_NO_WAIT ;
MQQueue queue = accessQueue(queueName, qMgr, openOptions);
MQMessage msg = new MQMessage();
MQGetMessageOptions gmo = new MQGetMessageOptions();
gmo.matchOptions = MQC.MQMO_NONE;
for(int i=0;i<numberMsgs;i++) {
try {
queue.get(msg, gmo, getMsgMaxLength);
msg.clearMessage();
} catch (MQException e) {
e.printStackTrace();
}
}
}
This works but is not performing as quickly as is required. Is there a better method to remove messages without doing a get??
Is there any options available to speed this up.
Any help would be much appeciated. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Dec 07, 2006 3:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
A get is (unsurprisingly) the only way to retrieve messages from a queue.
Is there an actual business requirement for a Java program to process a message then delete the next x messages? If you're just trying to remove unwanted messages from a queue, you might want to consider the q program (support pack MA01) or if it's a complete purge the CLEAR QLOCAL command.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| stephenboarder |
| Posted: Thu Dec 07, 2006 3:59 am Post subject: |
|
|
Newbie
Joined: 07 Dec 2006
Posts: 9
|
Yes, the business requirement is to process an event message and remove a configurable number of messages from the queue specified in the event message. This has to be a continually running application written in java. It is not a complete purge and there should be no manual intervention to remove messages.
Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 07, 2006 4:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
How do you ensure the next x messages in the queue are the ones associated with the event? And why send messages if the process is to delete them?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| stephenboarder |
| Posted: Thu Dec 07, 2006 4:09 am Post subject: |
|
|
Newbie
Joined: 07 Dec 2006
Posts: 9
|
| The event is a high queue depth event so the requirement is to remove a configurable number of messages from queue that has reached the high queue depth. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 07, 2006 4:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Ah! 
Why not do something more traditional, like spinning up more instances of the application to read the queue? Or if the messages are that disposable look into other methods of management, like expiry?
To get back to your original post, a get is the only way to remove messages.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| stephenboarder |
| Posted: Thu Dec 07, 2006 4:20 am Post subject: |
|
|
Newbie
Joined: 07 Dec 2006
Posts: 9
|
| Yes I am heading towards the route of multithreading the java app. I was looking to find out if any of the get options could be added/removed to improve performance. I am surprised that a loop to get messages is only performing at approx. 25 messages/second. |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Dec 07, 2006 4:25 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| stephenboarder wrote: |
| I am surprised that a loop to get messages is only performing at approx. 25 messages/second. |
What is your hardware environment? Are you using a client or bindings connection? What version and maintenance level of WMQ?
_________________
-wayne |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 07, 2006 4:25 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Performance depends on a number of factors, including box size. Also things like message persistence can have an impact.
It's an interesting way of dealing with a full queue - delete the offending messages. Still, whatever works for you. I'd still investigate alternatives, including the performance of the real processing application.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Dec 07, 2006 4:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also... how big are the messages?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 07, 2006 4:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Consider - you have a queue nearing full. To free up space you delete x messages from it. At the time of removal you have no knowledge of how long they've been sitting on the queue (no manual intervention you said, and there's no apparent code checking put time). The messages deleted are therefore randomly selected, in that which messages will be deleted rather than processed cannot be predicted when the message is sent. If the queue hovers around half full, then messages will be processed, but after a delay.
A more efficient and clearer way to deal with this is to set an SLA on messages, in that they will be processed in x seconds or not at all. This gives you a clear "contract" and allows for message resend (assuming message is important, given the willingness to clear them). You can then set the expiry on the messages which is a far faster and more efficient way of removing them.
Just a point of view. Other opinions are equally valid.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| stephenboarder |
| Posted: Thu Dec 07, 2006 7:05 am Post subject: |
|
|
Newbie
Joined: 07 Dec 2006
Posts: 9
|
I am using W2K server.
I believe I am using a client connection. My connect() method has the following line;
MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
Would a "bindings connection" be faster?
Message size is small, < 1K. |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Dec 07, 2006 7:15 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| stephenboarder wrote: |
| Would a "bindings connection" be faster? |
faster, better, cheaper, yes.
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Dec 07, 2006 7:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Computationally.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
