How to check whether JMS is still alive? - Weblogic

This is a discussion on How to check whether JMS is still alive? - Weblogic ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: How to check whether JMS is still alive?

  1. How to check whether JMS is still alive?


    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.

  2. Re: How to check whether JMS is still alive?


    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/jav...timeMBean.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.setExceptionList ener
    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" wrote:
    >
    >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.



  3. Re: How to check whether JMS is still alive?


    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.dis patchSyncNoTran(DispatcherWrapperState.java:495)
    at weblogic.jms.client.JMSSession.receiveMessage(JMSS ession.java:461)
    at weblogic.jms.client.JMSConsumer.receive(JMSConsume r.java:421)
    at myapp.JmsTopicListener.listen(JmsTopicListener.jav a: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.ShutdownUtilDelegat e.mapSystemException(ShutdownUtilDelegate.java:89)
    at javax.rmi.CORBA.Util.mapSystemException(Util.java: 65)
    at weblogic.jms.dispatcher._DispatcherImpl_Stub.dispa tchSyncNoTranFuture(_DispatcherImpl_Stub.java:131)
    at weblogic.jms.dispatcher.DispatcherWrapperState.dis patchSyncNoTran(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.purg e_calls(IIOPConnection.java:438)
    at com.sun.corba.se.internal.iiop.ReaderThread.run(Re aderThread.java:70)





    "Kats" wrote:
    >
    >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/jav...timeMBean.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.setExceptionList ener
    >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" wrote:
    >>
    >>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.

    >



  4. Re: How to check whether JMS is still alive?

    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.setExceptionList ener().

    Tom

    Iggy wrote:
    > 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.dis patchSyncNoTran(DispatcherWrapperState.java:495)
    > at weblogic.jms.client.JMSSession.receiveMessage(JMSS ession.java:461)
    > at weblogic.jms.client.JMSConsumer.receive(JMSConsume r.java:421)
    > at myapp.JmsTopicListener.listen(JmsTopicListener.jav a: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.ShutdownUtilDelegat e.mapSystemException(ShutdownUtilDelegate.java:89)
    > at javax.rmi.CORBA.Util.mapSystemException(Util.java: 65)
    > at weblogic.jms.dispatcher._DispatcherImpl_Stub.dispa tchSyncNoTranFuture(_DispatcherImpl_Stub.java:131)
    > at weblogic.jms.dispatcher.DispatcherWrapperState.dis patchSyncNoTran(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.purg e_calls(IIOPConnection.java:438)
    > at com.sun.corba.se.internal.iiop.ReaderThread.run(Re aderThread.java:70)
    >
    >
    >
    >
    >
    > "Kats" wrote:
    >
    >>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/jav...timeMBean.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.setExceptionList ener
    >>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" wrote:
    >>
    >>>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.

    >>

    >



  5. Unhappy Re: How to check whether JMS is still alive?

    I am having a similar problem with Weblogic 10.3.
    In my case it is a little bit worse because I get absolutely no exceptions when the connection goes down because of server going down. The thread that attempts to create a session from the broken connection just hangs indefinitely on an internal Object.wait().

    I am pasting the example code I am using to reproduce this (search for the word PROBLEM for descriptions inside the code of the problems I am having):


    package example.weblogic.queue;

    import java.io.BufferedReader;
    import java.io.InputStreamReader;
    import java.util.Hashtable;

    import javax.jms.Connection;
    import javax.jms.ConnectionFactory;
    import javax.jms.ExceptionListener;
    import javax.jms.JMSException;
    import javax.jms.Message;
    import javax.jms.MessageConsumer;
    import javax.jms.MessageListener;
    import javax.jms.MessageProducer;
    import javax.jms.Queue;
    import javax.jms.Session;
    import javax.jms.TextMessage;
    import javax.naming.Context;
    import javax.naming.InitialContext;
    import javax.naming.NamingException;

    public class ManualWebLogicCall implements ExceptionListener
    {
    public static final String JNDI_INITIAL_FACTORY = "weblogic.jndi.WLInitialContextFactory";
    public static final String JNDI_PROVIDER_URL = "t3://localhost:7001";
    public static final String QUEUE_NAME = "someDistributedQueue";
    public static final String CONNECTION_FACTORY_JNDI_NAME = "ePortConnectionFactory";

    /**
    * @param args
    * @throws Throwable
    */
    public static void main(String[] args) throws Throwable
    {
    new ManualWebLogicCall(args).run();
    }

    private final Context jndiContext;
    private final ConnectionFactory connectionFactory;
    private Connection connection;

    public ManualWebLogicCall(String[] args) throws NamingException, JMSException
    {
    jndiContext = createJndiContext();
    connectionFactory = createConnectionFactory();
    connection = createConnection();
    }

    private Context createJndiContext() throws NamingException
    {
    Hashtable props = new Hashtable();

    props.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_INITIAL_FACTORY);

    props.put(Context.PROVIDER_URL, JNDI_PROVIDER_URL);

    return new InitialContext(props);
    }

    private ConnectionFactory createConnectionFactory() throws NamingException
    {
    Object temp = jndiContext.lookup(CONNECTION_FACTORY_JNDI_NAME);
    if (temp instanceof ConnectionFactory)
    {
    return (ConnectionFactory) temp;
    }
    else
    {
    throw new IllegalArgumentException("The connectionFactory is not of type ConnectionFactory: "
    + temp);
    }
    }

    private Connection createConnection() throws JMSException
    {
    Connection connectionCreated = connectionFactory.createConnection();
    connectionCreated.setExceptionListener(this);
    return connectionCreated;
    }

    public void run() throws JMSException
    {
    Runnable producerRunnable = new ProducerRunnable();
    Runnable consumerRunnable = new ConsumerRunnable();
    connection.start();
    new Thread(producerRunnable).start();
    new Thread(consumerRunnable).start();
    }

    private Queue getQueueDestination() throws NamingException
    {
    return (Queue) jndiContext.lookup(QUEUE_NAME);
    }

    /**
    * PROBLEM: According to * >java ee specification, this method should be called "If a JMS provider
    * detects a serious problem with a connection, it informs the connection's
    * ExceptionListener, if one has been registered. It does this by calling the
    * listener's onException method, passing it a JMSException object describing the
    * problem."
    *


    * For some reason, it is not being called when the Weblogic instance goes down.
    *


    * In this example, we are setting this as the exception listener
    * directly on {@link #createConnection()} method.
    *
    * @see javax.jms.ExceptionListener#onException(javax.jms. JMSException)
    */
    public void onException(JMSException e)
    {
    // PROBLEM: This never gets called
    System.err.println("ERROR: The connection throwed an exception: " + e);
    e.printStackTrace();
    }

    private final class ProducerRunnable implements Runnable
    {
    public void run()
    {
    try
    {
    System.out.println("Enter something. It will be echoed to you (Ctrl+C to finish):");
    BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
    for (String line; (line = reader.readLine()) != null
    {
    // PROBLEM: if the server goes down the connection object does
    // not detect this and the createSession() method ultimately
    // hangs on an Object.wait() internally.
    Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
    MessageProducer producer = session.createProducer(getQueueDestination());

    Message message = session.createTextMessage(line);
    producer.send(message);
    }
    }
    catch (Exception e)
    {
    e.printStackTrace();
    }
    }
    }

    private final class ConsumerRunnable implements Runnable
    {
    public void run()
    {
    try
    {
    Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
    MessageConsumer consumer = session.createConsumer(getQueueDestination());
    consumer.setMessageListener(new MessageListener()
    {
    public void onMessage(Message message)
    {
    try
    {
    System.out.println("OUTPUT: " + ((TextMessage) message).getText());
    }
    catch (JMSException e)
    {
    e.printStackTrace();
    }
    }
    });
    }
    catch (Exception e)
    {
    e.printStackTrace();
    }

    }
    }
    }


+ Reply to Thread