How to check whether JMS is still alive?

Iggy

unread,

Apr 13, 2004, 4:39:21 AM4/13/04

to

Hi,

I have a JMS application listening to a Queue on Weblogic 8.1, once in a while
the server has to be restarted, after that the application does not receive any
more messages from JMS, I guess because the references it obtained are no longer
valid, but no exception is thrown so how can the application check whether the
JMS objects are still valid?

Thanks,

A.

Kats

unread,

Apr 14, 2004, 10:14:20 AM4/14/04

to

Hi

From the client side, you can use register exception listeners on JMSconnection
as well as JMSSession to detect failures.

To detect the JMSServer failure, you can use JMX health monitoring API from the
JMSServerRuntimeMBean as:
http://e-docs.bea.com/wls/docs81/javadocs/weblogic/management/runtime/JMSRuntimeMBean.html

Here is more info on exception listeners from JMS FAQ:

http://e-docs.bea.com/wls/docs81/faq/jms.html

Does the WebLogic JMS server find out about closed or lost connections, crashes,
and other problems and does it recover from them?

A. Yes, but how it does this depends on whether a Java client crashes or WebLogic
Server crashes, as follows:

If a Java client crashes then the JMS server will clean up all the outstanding
server-side resource from the crashed client JVM, such as:
JMS connection(s) from the crashed client JVM
JMS temporary destination(s) created under the above JMS connection(s)
JMS session(s) created under the above JMS connection(s)
JMS client(s) created under the above JMS session(s) (connection consumer and
regular consumer)
JMS browser(s) created under the above session(s)
JMS producer(s) created under the above session(s)
If WebLogic Server crashes and it is the front-end to the JMS server, then:
A JMS client will lose all the server-side resources listed above.
The client's javax.jms.ExceptionListener.onException(...) will be called (if javax.jms.JMSConnection.setExceptionListener
is set) with a LostServerException, which extends JMSException.
If WebLogic server crashes and it is a back-end to the JMS server, then:
A JMS client may partially lose some of the server-side resources listed above
(only the resource on the crashed server, such as JMS temporary destination(s),
JMS client(s) and JMS browser(s).
The client's javax.jms.ExceptionListener.onException(...) will be called (if weblogic.jms.extensions.WLSession.setExceptionListener
is set) with a ConsumerClosedException, which extends JMSException.

Q. How does an application know if an application server goes down?

A. There are two exception listeners that you can register. Sun Microsystems'
JMS specification defines Connection.setExceptionListener that tells you if there
is a problem with the connection. That means that all consumers under that connection
are also in trouble. The reason you will get the connection exception is because
the WebLogic server you connect to on the other side is dead or not responding
or someone killed your connection via the Mbean interface.

However, for WebLogic Server JMS, you may have multiple sessions in a connection,
with the sessions going to multiple backend servers. WebLogic Server has an extension
for this called WLSession.setExceptionListener that tells you if there is a problem
with a session. For more information, see the JMS WLSession Javadoc.

Kats
BEA

Iggy

unread,

Apr 15, 2004, 7:12:07 AM4/15/04

to

Hi,

thanks for your reply. I register the ExceptionListener and then check with Connection.getExceptionListener()
that it's been correctly registered, I then manually shut down the weblogic server
but all I get is CORBA exceptions (see below), the listener's onException() method
is not being invoked, am I doing something wrong?

Thanks,

A.

weblogic.jms.common.JMSException: CORBA COMM_FAILURE 1398079696 Maybe; nested
exception is:
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 208 completed: Maybe
at weblogic.jms.dispatcher.DispatcherWrapperState.dispatchSyncNoTran(DispatcherWrapperState.java:495)
at weblogic.jms.client.JMSSession.receiveMessage(JMSSession.java:461)
at weblogic.jms.client.JMSConsumer.receive(JMSConsumer.java:421)
at myapp.JmsTopicListener.listen(JmsTopicListener.java:57)
at myapp.main(MyApp.java:62)
Caused by: java.rmi.MarshalException: CORBA COMM_FAILURE 1398079696 Maybe; nested
exception is:
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 208 completed: Maybe
at com.sun.corba.se.internal.iiop.ShutdownUtilDelegate.mapSystemException(ShutdownUtilDelegate.java:89)
at javax.rmi.CORBA.Util.mapSystemException(Util.java:65)
at weblogic.jms.dispatcher._DispatcherImpl_Stub.dispatchSyncNoTranFuture(_DispatcherImpl_Stub.java:131)
at weblogic.jms.dispatcher.DispatcherWrapperState.dispatchSyncNoTran(DispatcherWrapperState.java:463)
... 4 more
Caused by: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 208 completed:
Maybe
at com.sun.corba.se.internal.iiop.IIOPConnection.purge_calls(IIOPConnection.java:438)
at com.sun.corba.se.internal.iiop.ReaderThread.run(ReaderThread.java:70)

Tom Barnes

unread,

Apr 15, 2004, 11:47:28 AM4/15/04

to Iggy

Hi Iggy,

I would need to check to make sure, but I think
the onException may not be invoked for exceptions
thrown by synchronous calls (such as receive()).
Regardless, the application is already getting
these types of exceptions, and can handle them
as they are thrown.

Furthermore, if the connection host is still up, but
the JMS server is down, the connection's exception
listener will not get fired. These types of exceptions
are sent to the session's exception listener, see
weblogic.jms.extensions.WLSession.setExceptionListener().

Tom