Created attachment 422242 [details] Stack.txt Description of problem: When a Java consumer is connected to MRG, and the public interface is takedown with ifdown command, the Java MRG API catches and displays an exception to STDERR, but does not propogate the exception to the caller. This seems to prevent the client from receiving notification that the connection is down, and therefore cannot attempt to reconnect. How reproducible: Very Steps to Reproduce: 1. Start Java message consumer. 2. Take down the public interface on the server running the MRG broker. 3. Observe the output displayed on STDOUT or STDERR. Expected results: When the network interface is taken down the client will write out the stack trace for an exception that was caught internally to STDERR, and the client will not be notified that the connection is down.
1. May I know if an exception listener is used and properly set for the connection that failed ? 2. If an exception listener is set, does it report a different exception or nothing at all? 3. May I also know what the rpm versions being used? rpm -qa | grep qpid-java should do it.
Presented the customer with an example to recreate the issue. The exception was received as expected. It turned out that the customer was expecting to be notified (in a clustered env) of every interim connection failure even the client was able to connect to another broker in the cluster. The Qpid JMS Client provides automatic failover. The Qpid client will only notify if it cannot connect to a broker successfully. So if a broker is clustered, then the client will only report a connection failure only if it's unable to connect to any of the brokers within the cluster. If you don't need automatic failover, then you would need to handle failover at the application level. In this case you will be notified immediately if the current connection fails and then you would need to decide (at the application level) which broker to connect to.