MQSeries.net :: View topic - What should you have in onException?

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Java / JMS » What should you have in onException?

What should you have in onException?

« View previous topic :: View next topic »

Author

Message

steffi2

Posted: Thu Nov 12, 2009 7:38 pm Post subject: What should you have in onException?

Apprentice

Joined: 04 Sep 2009
Posts: 31

If you want to handle failover say you have a cluster and the node fails over and you receive an onException thru your ExceptionListener what is it that it should do?

IBM's MQ jms jars are very fusy about what you close in the event of any kind of interruption and often simply block if you try to close receiver or session.

If you know that your application can reconnect by relaunching whenever you receive an onException call is there ever any reason to try to close receiver, session or connection upon shutting down?

Is it simply easier to shutdown the other areas of your application but let the JMS resources clean up upon exit of the application?

Note: this assumes you have the ability to relaunch the application automatically in the event something like this happens.

Otherwise it seems that if you try to recover by closing resources you will eventually block.

fjb_saper

Posted: Sat Nov 14, 2009 5:54 pm Post subject:

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

You should always explicitly manage your MQ resources and not wait for finalization. (Best practices)
So yes you need to close your resources in a finally block.

Getting the exceptions from the Exception listener is more for Server side sessions to use. You can use those as information. What this means is that the next operation you request from the session/connection that has trouble will throw a JMSException or a network exception or some kind of exception.

You will have to catch JMSException on your try call as well as put in a catch all on Exception... Then in the finally block release each and every resource acquired that is not null in its own try release object catch + finally set object to null block

Have fun

_________________
MQ & Broker admin

steffi2

Posted: Wed Nov 18, 2009 4:39 am Post subject:

Apprentice

Joined: 04 Sep 2009
Posts: 31

Where's an example of how to reconnect a message listener when a connection is interrupted? If found that if you try to close the session it blocks indefinately

suppose I have n connections and n message listeners and I want to reconnect when ever I have an interruption what shoud I do in the onException? I assume onexception is sent from the delivery thread

fjb_saper

Posted: Wed Nov 18, 2009 7:05 pm Post subject:

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

steffi2 wrote:

Where's an example of how to reconnect a message listener when a connection is interrupted? If found that if you try to close the session it blocks indefinitely

suppose I have n connections and n message listeners and I want to reconnect when ever I have an interruption what should I do in the onException? I assume onException is sent from the delivery thread

It depends greatly whether you are in a J2EE environment or in a stand alone environment. In a stand alone environment you can possibly have a method to release and reacquire the resources. In a J2EE environment you should let the pooling and appserver handle part if not all of it. You may need to schedule some admin operation to restart MDBs. You will still have to code the app to release acquired resources and retry.

Have fun

_________________
MQ & Broker admin

Display posts from previous:

Page 1 of 1

MQSeries.net Forum Index » IBM MQ Java / JMS » What should you have in onException?

Jump to:

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

Protected by Anti-Spam ACP