| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Browsing message from IBM MQ - output hold/inhibited |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Thu May 12, 2016 12:38 pm Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| wilfred wrote: |
Hi All,
I thank all of you for thinking through this issue i am facing.
I just want to know if I can get this resolved with the options we have in hand.
Can one of you let me know the usage of MQGMO_LOCK and MQC.MQOO_INPUT_EXCLUSIVE. Can one of these help me in this case?
Can I paste the code here to see if we can integrate one of these?
Regards,
Rajan.S |
Open option MQC.MQOO_INPUT_EXCLUSIVE attempts to gain exclusive ownership of the queue for input (GET, BROWSE). If some other app has the queue open, the your app will fail to open the queue. If your app successfully opens the queue with this option, all other apps will fail to open the queue.
In your app design, does each individual bean open a specific queue - a queue associated with that bean only?
Get message option MQGMO_LOCK attempts to establish a lock on the current message, so that no other app can consume it.
How does your consuming app know which of the n messages it is to consume (browse, get)? Will there only be one message in a queue?
So, your current design has one bean that produces a message, and another that browses? How does the app know which message to browse?
_________________
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 |
|
 |
| Vitor |
| Posted: Thu May 12, 2016 1:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| wilfred wrote: |
| Can one of these help me in this case? |
If you code the Web GUI with MQC.MQOO_INPUT_EXCLUSIVE, it will hang (or fail) waiting for all the MDBs to disconnect. If it does manage to connect, all the MDBs with hang (or fail) waiting for the GUI to disconnect.
Both of these scenarios will destroy your throughput.
I still don't see how this worked under v7.0. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu May 12, 2016 2:01 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
As I said before:
| hughson wrote: |
| You can make use of MQOO_INPUT_EXCLUSIVE but that does leave you battling with the MDB to get that lock. If the MDB already has the queue open, you can't get the exclusive lock. |
You have many excellent MQ Experts making suggestions, if you can't go the alias queue route then by far the most likely to succeed in my view is:
| Vitor wrote: |
| What you need is to write the messages to a separate queue and for this GUI to move them to the queue the MDB is processing once the user indicates he's reviewed the message and is happy with it. |
However, given you said:
| wilfred wrote: |
| One strange point I would like to mention here is, This specific requirement or the scenario is working perfectly fine in an legacy environment where the IBM MQ version is 7.0, EJB 2.x, Weblogic 10 combination. Today we have migrated the same application to IBM MQ 7.5, EJB 3.2 and Weblogic 12.1.3. Application is not working as expected on this new STACK. |
it seems that you might have more luck in investigating what part of your changed stack has changed in behaviour from old to new to stop this working. As noted:
| Vitor wrote: |
| There's certainly no changes in this very basic MQ behavior between 7.0 & 7.5. |
this group do not believe it is a change in MQ. Are you able to test the old stack with the new MQ version for example (even if not a supported combination for production) in order to home in on the thing that has changed?
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| wilfred |
| Posted: Mon May 16, 2016 5:08 am Post subject: |
|
|
Novice
Joined: 11 May 2016
Posts: 12
|
Hi bruce2359, Thanks for your interest on my queries. please see my comments below inline.
| bruce2359 wrote: |
Open option MQC.MQOO_INPUT_EXCLUSIVE attempts to gain exclusive ownership of the queue for input (GET, BROWSE). If some other app has the queue open, the your app will fail to open the queue. If your app successfully opens the queue with this option, all other apps will fail to open the queue.
|
Yes, I understand and totally agree to this point.
| bruce2359 wrote: |
In your app design, does each individual bean open a specific queue - a queue associated with that bean only?
|
Yes, in the design we have currently, each queue is associated to only one specific bean only.
| bruce2359 wrote: |
Get message option MQGMO_LOCK attempts to establish a lock on the current message, so that no other app can consume it.
|
I am fine with this.
| bruce2359 wrote: |
How does your consuming app know which of the n messages it is to consume (browse, get)? Will there only be one message in a queue?
|
MDB is always up and running (Listener). Meanwhile, a user also wants put hold (Get disabled) on a specific queue. Selects a browse option from our own application. There can be more than one message in the same queue.
| bruce2359 wrote: |
So, your current design has one bean that produces a message, and another that browses? How does the app know which message to browse? |
No, in the current design the application puts a message dynamically to a specific queue and the user manually tries to browse this message. This is a manual operation of viewing the message. Once the user is satisfied with this browse, he/she will remove the hold (Get allowed). Now bingo! the message can be consumed for processing by the respective MDB.
The requirement is very simple, a user should be able to browse a message with Exclusive option available in IBM MQ core api's.
Thanks,
Wilfred. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon May 16, 2016 5:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
So, if I understand this... please correct me if I am mistaken.
The producing app is bound to one and only one instance of a specific queue, AND the consuming app is bound to the exact same, one and only one queue. Further, there is one and only one message in the this queue.
I don't yet see why the OPEN_EXCLUSIVE is needed if only ONE app opens the queue. Are you saying that there is a 3rd app that wants to browse the message to make the determination if the message is to be consumed or not? Or is it the consuming app that makes the decision?
IMQ offers no option to make a message browse-able, but not destructively consumable. The LOCK option is temporary, and applies to a message, not the entire queue. MQGMO_BROWSE tells mq not to consume destructively, but does NOT prevent the app from subsequently getting the browsed message under the browse cursor.
_________________
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 |
|
|
| exerk |
| Posted: Mon May 16, 2016 5:45 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
| ...Further, there is one and only one message in the this queue... |
| wilfred wrote: |
| ...There can be more than one message in the same queue... |
Wilfred, what is the business reason for being able to browse a message prior to releasing it? What happens if the operator does not want to release the message?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| wilfred |
| Posted: Mon May 16, 2016 8:01 am Post subject: |
|
|
Novice
Joined: 11 May 2016
Posts: 12
|
| exerk wrote: |
Wilfred, what is the business reason for being able to browse a message prior to releasing it? What happens if the operator does not want to release the message? |
Hi Exerk,
Thanks for your reply.
Business requirement is as below:
1. There are 300+ QLOCALs queues existing in the IBM MQ configured for this application.
2. All these are also accessible through the application through a GUI. Which simply means, an end user of the app will be able to see list of Queues in his web page.
3. As per the requirement, after the user post a message to a particular queue, he/she should be able to browse it before the MDB processes it.
4. Since the MDB's are also configured and running in the server, the user is provided with a UI feature to put a output hold (Get disabled) on a particular queue.
5. The user will browse the message, and then release the output hold (GET enabled) so that the same can be processed by the MDB.
6. In the current code, during the time the user browses the message, programmatically the GET is enabled and disabled.
7. Within this small fraction of a second, the MDB starts processing this message and the message is removed from the queue. Which the User does not want this to happen.
8. In short the user wants to have the control on the messages as explained above.
Operator will just view and release/remove hold on this queue.
Thanks,
Wilfred. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon May 16, 2016 8:06 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| wilfred wrote: |
| exerk wrote: |
Wilfred, what is the business reason for being able to browse a message prior to releasing it? What happens if the operator does not want to release the message? |
Hi Exerk,
Thanks for your reply.
Business requirement is as below:
1. There are 300+ QLOCALs queues existing in the IBM MQ configured for this application.
2. All these are also accessible through the application through a GUI. Which simply means, an end user of the app will be able to see list of Queues in his web page.
3. As per the requirement, after the user post a message to a particular queue, he/she should be able to browse it before the MDB processes it.
4. Since the MDB's are also configured and running in the server, the user is provided with a UI feature to put a output hold (Get disabled) on a particular queue.
5. The user will browse the message, and then release the output hold (GET enabled) so that the same can be processed by the MDB.
6. In the current code, during the time the user browses the message, programmatically the GET is enabled and disabled.
7. Within this small fraction of a second, the MDB starts processing this message and the message is removed from the queue. Which the User does not want this to happen.
8. In short the user wants to have the control on the messages as explained above.
Operator will just view and release/remove hold on this queue.
Thanks,
Wilfred. |
None if the above is a business reason, and nor has my question been answered as regards what happens if the operator doesn't want to release the message?
If it's because the operator needs to check the content of the message then that should be done before they commit the put, so I ask again - what is the business reason that someone needs to browse a message they have just put?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon May 16, 2016 8:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
None if the above is a business reason, and nor has my question been answered as regards what happens if the operator doesn't want to release the message?
If it's because the operator needs to check the content of the message then that should be done before they commit the put, so I ask again - what is the business reason that someone needs to browse a message they have just put? |
Accepting all of the above as valid questions regarding the solution (and I stand by my previous comments), I still don't think we've got to the bottom of the OP's original assertion that it worked under v7.0 and now doesn't under v7.5.
I stand by and repeat my comment that the solution as described shouldn't have worked under v7.0 and hence there's a missing piece in the description somewhere. Either the legacy solution doesn't work and the users only think it does, or this is a new requirement that the users are trying to slide into the migration.
Because v7.0 and v7.5 are not different in this basic area of functionality. However this solution was implemented, regardless of the logic or value of the solution, it should behave the same under v7.0 and v7.5. It's this variance that holds the key to the OP's problem.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| wilfred |
| Posted: Mon May 16, 2016 9:28 am Post subject: |
|
|
Novice
Joined: 11 May 2016
Posts: 12
|
| exerk wrote: |
None if the above is a business reason, and nor has my question been answered as regards what happens if the operator doesn't want to release the message?
|
Exerk, the user will always release the message after viewing it. This is not kind of work flow. User will only read it, release the message for the MDB to consume so that if it was a wrong message, he will regenerate the right message through the scenarios again.
| exerk wrote: |
If it's because the operator needs to check the content of the message then that should be done before they commit the put, so I ask again - what is the business reason that someone needs to browse a message they have just put? |
The message put in to this queue is not manually, it is put by the application after few business flow. so The user will want to verify the message before the MDB consumes it so that he can always re-generate the right message untill his goal is met. |
|
| Back to top |
|
|
| wilfred |
| Posted: Mon May 16, 2016 9:34 am Post subject: |
|
|
Novice
Joined: 11 May 2016
Posts: 12
|
If there are any Java developers here. Can you please post an example code to show the usage of MQOO_INPUT_EXCLUSIVE? This will give me an option atleast to see if it serves my purpose.
I guess that should be a good start for me to explore programmatically.
Regards,
Wilfred. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 16, 2016 9:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| wilfred wrote: |
| The user will want to verify the message before the MDB consumes it so that he can always re-generate the right message untill his goal is met. |
Why should it go to a queue before the user verifies it?
Shouldn't it be held in the program somewhere else -a database or simply in memory - until the user releases it?
Input Exclusive will prevent the MDB from reading any messages until the process with the queue open has CLOSED the queue. It's not a by-message process.
If you go down this road you will have a lot of complicated scenarios to figure out and test... and then deal with at 4 in the morning when a user in another timezone has an issue.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon May 16, 2016 9:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
More precisely, Input Exclusive will prevent any other MDB from reading any messages until the process with the queue open has CLOSED the queue. It's not a by-message process.
_________________
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 |
|
|
| Vitor |
| Posted: Mon May 16, 2016 10:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| wilfred wrote: |
If there are any Java developers here. Can you please post an example code to show the usage of MQOO_INPUT_EXCLUSIVE? This will give me an option atleast to see if it serves my purpose.
I guess that should be a good start for me to explore programmatically. |
You don't need an example. This worked (you said) under MQ v7.0.
The Java API for MQ has not changed between v7.0 and v7.5.
If this used to work, it should still work.
If you try to use MQOO_INPUT_EXCUSIVE in the Web UI it will fail as long as the MDB has the queue open. If you use MQOO_INPUT_EXCLUSIVE in the MDB it will prevent the Web UI working.
If you blow up the MDB by setting the queue to get disabled, the Web UI will not be able to browse the message. As soon as you re-enable the queue the Web UI will be in a race with the MDB reconnection, which it will lose.
| wilfred wrote: |
| This is not kind of work flow. User will only read it, release the message for the MDB to consume so that if it was a wrong message, he will regenerate the right message through the scenarios again |
Can you hear yourself? A process generates a message. A user reviews it and, if needed, restarts the process to regenerate a "better" message.
How is that not a workflow??
Your best and only chance is to investigate why this used to work in v7.0. Or IF it worked in v7.0.
You cannot do what you want with the topology you've described, no matter how you code it. You need to find the missing piece of the scenario.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| wilfred |
| Posted: Mon May 16, 2016 11:59 am Post subject: |
|
|
Novice
Joined: 11 May 2016
Posts: 12
|
| Vitor wrote: |
You don't need an example. This worked (you said) under MQ v7.0.
|
Yes, this worked in the old stack. Since this is not working with the new stack we need to modify the code with the EXCLUSIVE option.
I asked an example from anyone of you with "EXCLUSIVE" option enabled and not a similar code which I already have.
| Vitor wrote: |
If you try to use MQOO_INPUT_EXCUSIVE in the Web UI it will fail as long as the MDB has the queue open. If you use MQOO_INPUT_EXCLUSIVE in the MDB it will prevent the Web UI working.
|
I wish to add this not in MDB, but in UI code where the user will browse the message first time.
| Vitor wrote: |
Can you hear yourself? A process generates a message. A user reviews it and, if needed, restarts the process to regenerate a "better" message.
|
I am sorry, you have not understood this right.
The user is responsible to generate the message by selecting few options.
The message gets generated with valid format.
The user wants to know if the generated message is in the right format and with right values and therefore browse the message from the Queue.
Hope this is clear to you Vitor.
I only want to know if IBM MQ has provided an option to browse a message with EXCLUSIVE option, why not I make use of that in my scenario? I do understand that this can be handled in different ways.
I am only trying to understand how to make use of the option LOCK or EXCLUSIVE to serve my purpose.
Regards,
Wilfred. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
