3 Replies Latest reply: Dec 16, 2010 6:00 PM by Clebert Suconic RSS

In Active-Backup mode, Clients fail to connect after active server is restarted.

Aspi Engineer Newbie

This test was conducted using source from the HQ trunk dated 12.06.2010

 

Consider the scenario that we have a HQ active-backup configuration. Server1 is active, Server2 is backup. JMS clients use a JNDI provider URL of "jnp://server1:port1,server2:port2"

 

Consider the following sequence of events:

a) start active server (server1)

b) start backup server (server2)

c) kill active server (server1)

    - backup server (server2) now becomes active

d) restart active server (server1)

 

At this point, a "new" JMS client is neither able to send or receive messages.

 

 

Detailed Information:

 

In step (c), When we kill the active server (server1), the backup server (server2) becomes active as expected. In server2's logs we see:

[Thread-1] 15:13:30,713 INFO [org.hornetq.core.server.impl.HornetQServerImpl]  Backup Server is now live

 

We can send and receive messages using JMS clients.

 

In step (d) when we restart the active server (server1), the logs remain stuck at:

[main] 16:01:09,035 INFO [org.hornetq.core.server.impl.FileLockNodeManager]  Waiting to obtain live lock

 

 

Now start a new JMS client and try to publish a JMS message again and you get:

 

2010-12-15 16:03:10,880 ERROR (QueueSend.java:108) - An exception occurred: cn=PUT_DEV.Extended.QueueConnectionFactory not bound

javax.naming.NameNotFoundException: cn=PUT_DEV.Extended.QueueConnectionFactory not bound

    at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)

    at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)

    at org.jnp.server.NamingServer.getObject(NamingServer.java:785)

    at org.jnp.server.NamingServer.lookup(NamingServer.java:443)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

    at java.lang.reflect.Method.invoke(Method.java:597)

    at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)

    at sun.rmi.transport.Transport$1.run(Transport.java:159)

    at java.security.AccessController.doPrivileged(Native Method)

    at sun.rmi.transport.Transport.serviceCall(Transport.java:155)

    at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)

    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)

    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)

    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

    at java.lang.Thread.run(Thread.java:619)

    at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)

    at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)

    at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)

    at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)

    at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)

    at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)

    at javax.naming.InitialContext.lookup(InitialContext.java:392)

    at com.putnam.jboss.queue.QueueSend.init(QueueSend.java:38)

    at com.putnam.jboss.queue.QueueSend.run(QueueSend.java:102)

    at com.putnam.jboss.queue.QueueSend.main(QueueSend.java:95)

 

 

What is expected behavior when server1 comes back up? Should server1 become active again and start processing requests or should server2 remain as the active server?  In my test neither server is now processing messages.

 

Thanks

Aspi Engineer

Putnam Investments