In Active-Backup mode, Clients fail to connect after active server is restarted.
aengineer Dec 15, 2010 4:54 PMThis 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