|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
enabling failIfQuiesce behavior for JMS and MDBeans |
« View previous topic :: View next topic » |
Author |
Message
|
vilyin |
Posted: Mon Aug 22, 2005 6:41 am Post subject: enabling failIfQuiesce behavior for JMS and MDBeans |
|
|
Novice
Joined: 26 Mar 2002 Posts: 20 Location: Ilyin Consulting Knowledge, Inc. USA - Boston, NY tri-state
|
Hi all,
I am trying to figure out how to "enable" "fail if quiescing" behavior of jms applications.
This needs to be done for both stand-alone jms apps as well as for jms apps and MDBeans running within the app server.
According to the manuals and to IBM's response to pmr, failIfQueiece needs to be set up for qcf:
Name: failIfQuiesce (use a capitol I in If)
Value: true
Type: java.lang.String
It also says that this option is set by default: (failIfQuiesce property states that it is set to Yes by default.)
But it doesn't work !!!
Setting this option for qcf for jms queue definition and as a custom property for WAS 5.1 MDBean listner service doesn' help.
Applications do not disconnect and do not allow to either bring the SVRCONN channel down or to end the QMgr.
Is there anything else that needs to be done either at the application level or at the jms JNDI objects configuration level??? Is it doable at all? Does IBM's jms-over MQ implementation provides any means to turn on/off this behavior. Apparently it does not implement it as a default bahavior.
Thanks,
Vitaliy |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Aug 22, 2005 4:36 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
You need to do this in JNDI.
This is where the default property is being set.
Thanks
 |
|
Back to top |
|
 |
vilyin |
Posted: Mon Aug 22, 2005 6:58 pm Post subject: |
|
|
Novice
Joined: 26 Mar 2002 Posts: 20 Location: Ilyin Consulting Knowledge, Inc. USA - Boston, NY tri-state
|
fjb_saber,
Thank you for the response.
It is obvious that qcf is normally set in JNDI, whether it's a fs-based .binding file, WAS name space, LDAP based one or anything else.
Default property doesn't need to be set. That is why it's default.
My question was - what else needs to be done/set in addition to the already mentioned in the original post failIfQuiesce option (which in WAS is already set by default).
Setting of this option doesn't seem to do "the thing"! SVRCONN cann't be stopped!!!
Thanks,
Vitaliy |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Aug 22, 2005 7:28 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Use the FORCE option on the STOP command of the SVRCONN channel. It will work. FAIL IF QUIESCING does nothing as far as MQCLient channels are concerned, other than giving the client app a different return code. I have the exact details of this at work from a discussion on the listserve and how fail if quiescing did nothing for MQClients, I'll post it tomorrow . _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
vilyin |
Posted: Tue Aug 23, 2005 5:33 am Post subject: |
|
|
Novice
Joined: 26 Mar 2002 Posts: 20 Location: Ilyin Consulting Knowledge, Inc. USA - Boston, NY tri-state
|
Peter,
I would really appreciate if you could post the details.
Thanks!
Vitaliy |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Aug 23, 2005 6:58 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Here is my post from the list serve:
Quote: |
After years of always preaching that apps should code the FAIL_IF_QUIESCING
option on puts gets and opens, I found it doesn't apply to MQClients!
Whether I coded it or not, my MQClient apps would end their outstanding
MQGET with waits immediatly. I brought this to IBM's attention, and they
responded as below. They accepted my form to have the manuals be more
explicit in this area - That FAIL_IF_QUIESCING is N/A for MQClients. No
question really. Just some info.....
If I *DON'T* code MQC.MQGMO_FAIL_IF_QUIESCING, the MQGET *immediatly*
returns the following:
2202-amqmdain end
2202-Right Click..Stop QM Controlled
2009-Right Click..Stop QM Immediate
Below is a quote from Karthik of IBM from PMR 20236 L6Q:
If the it is not a client application, then we wait till the agent has
finished with it's job ( in this case, we wait till the MQGET call
completes ) and then end the Qmgr. But if the MQGET is from an client,
the end command, first stops all the active channels on this queue
manager. During this stop, we call an internal function
lpiSPICancelWaiter, which cancels all pending wait requests on a queue
and returns 'MQRC_CONNECTION_QUIESCING' to the application.
|
_________________ Peter Potkay
Keep Calm and MQ On |
|
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
|
|
|
|