TopicConnection.close() Hangs When Reconnect Attempts = -1

[schwanitzb]

Hi,

Here is the code snippet:

// Setting up the listener

HornetQConnectionFactory

hornetQConnectionFactory = (HornetQConnectionFactory)HornetQJMSClient.createConnectionFactory(tcPrimary, tcBackup);

hornetQConnectionFactory.setReconnectAttempts(-1);

TopicConnection topicConnection = hornetQConnectionFactory.createTopicConnection();

TopicSession topicSession =

topicConnection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);

Topic topic = topicSession.createTopic(topicName);

TopicSubscriber topicSubscriber = topicSession.createSubscriber(topic);

topicSubscriber.setMessageListener(

this);

topicConnection.start();

.

.

.

// Stopping the listener

topicConnection.close()

If I shutdown the server between the start() and the close(), the close hangs forever. Other than setting reconnect attempts to something other than -1 is there a way to get the close to succeed?

Thanks,

Bill

[clebert.suconic]

With -1 you're basically telling it  to keep trying until the connection to your server is back. So, it's doing what it is supposed to do.

Say you temporarily missed the connection to the server. It needs to finish the operation accordingly to what you configured.

[schwanitzb]

Clebert,

In my case, the app is just hanging out listening to a topic. Even if the HornetQ server is down, I need to be able to exit. Any suggestions?

Thanks,

Bill

[clebert.suconic]

The client doesn't know the server is down. You're telling your client to keep trying the reconnection.

If you need a different behaviour, use a different reconnect attempt value.

[schwanitzb]

Well, I guess I want it both ways - I'm greedy that way :-)

I want the reconnect logic to do its thing during normal opearation of the app. But I also want the close() method to return when the app is trying to exit.

I guess what you are telling me is there is no way to get both of those at the same time.

Is it possible to add an exception listener and have the app reconnect when the server goes down? I pursued this approach, but, based on the exception sent to the app, the app cannot discriminate between:

a. the server (in a non-primary/backup configuration) going down (in which case, it should try to reconnect), and

b the primary server in a primary/backup configuration going down and HornetQ handling the switchover to the backup (in which case, it should NOT try to reconnect)

In each scenario, my apps exception listener receives this exception: javax.jms.JMSException: HornetQException[errorCode=4 message=The connection was disconnected because of server shutdown].

Cheers,

Bill

[clebert.suconic]

When you do a close, the client will close consumers on the servers, delete temporary queues if used.. and other cleanup that are needed.

You probably need this for a test scenario. If you had it both ways you would eventually break your production use case.

[timfox]

Actually - I'm with Bill on this one.

If a user calls close() on a connection it should terminate it's retry logic and exit.

This wouldn't be hard to do.

Bill, you could add a JIRA feature request for this...

[schwanitzb]

Tim & Clebert,

Thanks for your responses.

I created a bug report in JIRA: https://jira.jboss.org/jira/browse/HORNETQ-315

Cheers,

Bill