Author |
Message
|
elomon |
Posted: Wed Mar 12, 2014 12:56 pm Post subject: Deleting a message you have browsed |
|
|
Novice
Joined: 12 Mar 2014 Posts: 10
|
I'm building an application that browses the queue, reads a message, stores it in a database, and parses it in the database to verify business logic. If the message passes the business logic, I then need to delete the message off the queue.
According to the documentation, that should be possible by setting the message queue option MQGMO_MSG_UNDER_CURSOR and doing a Get on the message again. When I attempt this, the exception says the queue is 'not open for input'. I then tried to specify an input option when first opening the queue, only to run into an exception MQRC_OPTIONS_ERROR. The C# code follows - any insight is most appreciated.
Code: |
MQQueueManager mqQueueManager = new MQQueueManager(QManager);
MQQueue mqQ = new MQQueue(mqQueueManager, QDown, 8232, QManager, "", "");
MQGetMessageOptions mqGetMessageOptions = new MQGetMessageOptions();
mqGetMessageOptions.Options += MQC.MQGMO_BROWSE_NEXT;
mqGetMessageOptions.Options += MQC.MQOO_INPUT_SHARED;
MQMessage mqMessage = new MQMessage();
mqQ.Get(mqMessage, mqGetMessageOptions); //Exception occurs here
string msgText = mqMessage.ReadString(mqMessage.MessageLength);
//database logic snipped.
// remove it from the queue:
mqGetMessageOptions.Options = MQC.MQGMO_MSG_UNDER_CURSOR;
mqQ.Get(mqMessage, mqGetMessageOptions); //get the message, which deletes it
|
|
|
Back to top |
|
 |
PaulClarke |
Posted: Wed Mar 12, 2014 1:22 pm Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
Well I'm just guessing here since I prefer to write in C but is 8232 actually
MQOO_INPUT_BROWSE +
MQOO_INQUIRE +
MQOO_FAIL_IF_QUIESCING
in which case should you not add
MQOO_INPUT_SHARED
or whatever ?
Cheers,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
elomon |
Posted: Wed Mar 12, 2014 1:25 pm Post subject: Need some kind of input? |
|
|
Novice
Joined: 12 Mar 2014 Posts: 10
|
Originally I did not have 'MQOO_INPUT_SHARED' and an exception was thrown that the queue was not open for input. Apparently the queue needs to be 'open for input' but 'input shared' isn't a valid input option to use in this scenario.
Is there another input option that works for deleting the message being browsed? |
|
Back to top |
|
 |
zpat |
Posted: Wed Mar 12, 2014 1:41 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
You can use input exclusive if you wish (or set this on the queue def).
You might also want to use the "lock the message under cursor" option to prevent anyone else getting it.
What do you do if the message does not pass the validation? _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
PaulClarke |
Posted: Wed Mar 12, 2014 1:43 pm Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
Well, I don't see how you can expect to get a message from the queue without using at least one of the MQOO_INPUT options.
What was the full set of options you used when the open failed?
I don't know your full environment, is there something else which would cause the open to fail when you try to access for get ? _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
elomon |
Posted: Wed Mar 12, 2014 1:49 pm Post subject: |
|
|
Novice
Joined: 12 Mar 2014 Posts: 10
|
zpat wrote: |
You can use input exclusive if you wish (or set this on the queue def).
You might also want to use the "lock the message under cursor" option to prevent anyone else getting it.
What do you do if the message does not pass the validation? |
I tried the input exclusive (MQOO_INPUT_EXCLUSIVE) and the lock (MQGMO_LOCK) and received the same message about the queue not being open for input (MQRC_NOT_OPEN_FOR_INPUT).
If the message does not pass validation, the message is to remain in the queue. An alert will be sent to the application team and they require the message remain in the queue for investigation. |
|
Back to top |
|
 |
elomon |
Posted: Wed Mar 12, 2014 1:53 pm Post subject: |
|
|
Novice
Joined: 12 Mar 2014 Posts: 10
|
PaulClarke wrote: |
Well, I don't see how you can expect to get a message from the queue without using at least one of the MQOO_INPUT options.
What was the full set of options you used when the open failed?
I don't know your full environment, is there something else which would cause the open to fail when you try to access for get ? |
Good point about using an MQOO_INPUT but MQ does not like the input options we tried .
The original code snippet has everything that was used to retrieve the message and attempt to remove it after reading. The only part that fails is the second GET which is supposed to delete the message now that it's done being browsed (saved). |
|
Back to top |
|
 |
PaulClarke |
Posted: Wed Mar 12, 2014 2:07 pm Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
Well, I see no reason why MQ itself should prevent you opening a queue with both MQOO_BROWSE and MQOO_INPUT_SHARED set. Perhaps it's a limitation of the C# interface but that would be surprising. However, I can't for the life of me find the documentation on the MQ C# classes.
Of course it's always possible that something else is getting in the way like an API exit or an inherited class or whatever. Might be worth running a trace on the server to see what is actually getting through to the queue manager and see whether it is indeed the queue manager itself that is rejecting the call.
Cheers,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
elomon |
Posted: Wed Mar 12, 2014 2:13 pm Post subject: |
|
|
Novice
Joined: 12 Mar 2014 Posts: 10
|
PaulClarke wrote: |
Well, I see no reason why MQ itself should prevent you opening a queue with both MQOO_BROWSE and MQOO_INPUT_SHARED set. Perhaps it's a limitation of the C# interface but that would be surprising. However, I can't for the life of me find the documentation on the MQ C# classes.
Of course it's always possible that something else is getting in the way like an API exit or an inherited class or whatever. Might be worth running a trace on the server to see what is actually getting through to the queue manager and see whether it is indeed the queue manager itself that is rejecting the call.
Cheers,
Paul. |
I appreciate your time on this Paul. The exception is coming from the queue manager and I've run this as an absolute minimal/pure MQ code to try and nail it down.
I will keep at it; maybe someone has done the delete the browsed message trick and can offer insight. |
|
Back to top |
|
 |
markt |
Posted: Wed Mar 12, 2014 2:29 pm Post subject: |
|
|
 Knight
Joined: 14 May 2002 Posts: 508
|
Quote: |
Code: |
mqGetMessageOptions.Options += MQC.MQGMO_BROWSE_NEXT;
mqGetMessageOptions.Options += MQC.MQOO_INPUT_SHARED;
|
|
That code is mixing Get and Open options.
MQOO - used for MQOPEN
MQGMO - used for MQGET |
|
Back to top |
|
 |
Tibor |
Posted: Thu Mar 13, 2014 4:14 am Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
markt wrote: |
That code is mixing Get and Open options. |
But at least there is no problem with transaction handling...  |
|
Back to top |
|
 |
elomon |
Posted: Thu Mar 13, 2014 4:55 am Post subject: |
|
|
Novice
Joined: 12 Mar 2014 Posts: 10
|
markt wrote: |
Quote: |
Code: |
mqGetMessageOptions.Options += MQC.MQGMO_BROWSE_NEXT;
mqGetMessageOptions.Options += MQC.MQOO_INPUT_SHARED;
|
|
That code is mixing Get and Open options.
MQOO - used for MQOPEN
MQGMO - used for MQGET |
Markt - I only added the input shared because MQ threw an exception that queue was not open for input when trying to delete the browsed message.
What would be valid options for browsing the queue and having it open for input so the browsed message could be deleted? According to the documentation, this is possible but it doesn't provide an example of what queue/message options to use. |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Mar 13, 2014 5:28 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
elomon wrote: |
I only added the input shared because MQ threw an exception that queue was not open for input when trying to delete the browsed message. |
You cannot whimsically mix open-options with get-message-options. Open-for-input is an open-option, NOT a get-message-option. Correct your code. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
elomon |
Posted: Thu Mar 13, 2014 5:40 am Post subject: |
|
|
Novice
Joined: 12 Mar 2014 Posts: 10
|
bruce2359 wrote: |
elomon wrote: |
I only added the input shared because MQ threw an exception that queue was not open for input when trying to delete the browsed message. |
You cannot whimsically mix open-options with get-message-options. Open-for-input is an open-option, NOT a get-message-option. Correct your code. |
Bruce - do you have any insight into what options would work for browsing the messages while having the queue open for input as MQ requires? |
|
Back to top |
|
 |
zpat |
Posted: Thu Mar 13, 2014 5:54 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
There is this amazing thing - called IBM documentation.
In the Application Programming Reference part - all sorts of magic options are explained.
One of which is MQOO_BROWSE
If you really just want to browse the queue, you can open it for browse only.
Just remember to understand the difference between OPEN options and GET options - they can look similar.
MQOO - Open Options
MQGMO - Get Message Options
Even if the queue is open for input - you can still browse a message using the MQGMO_BROWSE_NEXT option.
Then you can get the message under the browse cursor if you want to (for example).
Some of my favourite options are MQGMO_CONVERT and MQGMO_WAIT.
If you want to experiment with all this stuff - why not use the MQ API exerciser that comes with MO71? _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Last edited by zpat on Thu Mar 13, 2014 5:59 am; edited 1 time in total |
|
Back to top |
|
 |
|