Server side connection clean-up

[timfox]

In JBoss Messaging we want to clean-up server side connection resources when the connection from the client fails, e.g. the client dies.

On the client side, we can hook into connection failure using addConnectionListener() on the client class.

On the server side we would like some kind of equivalent hook so we can do our clean-up.

Is there currently any such hook?

I'm thinking of something along the lines of, if the client hasn't pinged the server for over x seconds then notify the exception listeners on the server...

[tom.elrod]

There is no such hook currently on the server side. Unless using callbacks, everything is stateless. If using callback, there will be a state for the client on the server side, but then get into the issue of if is a push or pull callback.

If is push callback (meaning server pushes callback message to the callback server, which usually exist within the client process), then is already thread started that is somewhat related at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=71259.

If is pull callback (meaning client periodically calls to get the callbacks), then would have to build in some sort of lease policy. So if client did not call to get callbacks within a certain period of time, then could be considered dead. This has been discussed before, but didn't have a strong enough use case for it at the time. If you have a need for this, will need to discuss how this would be configured (and will need to open a jira issue for it).

Am happy to add whatever you need. Just let me know what would work best for you.

[timfox]

Hi Tom-

In some cases we will have callbacks, but not all.

If the jms connection is just sending messages for instance, then there is no callback server set-up on the client since we don't need anything pushed back.

However, even in that case, the server still needs to know whether the connection is still alive.

This is because there are quite a lot of resources allocated in the server when the jms connection is created - these need to be destroyed when the client is thought to be dead.

I can see that you would need to store state on the server to do this without using callbacks.

Actually, we'd like to avoid callbacks altogether because we'd really like to use the UIL2 transport I believe you have in the pipeline (we don't want sockets from server to client).

[timfox]

So, to summarise.

From our perspective, what would be ideal would be to have the ability to register exception listeners on the server side, even for the case where there are no callbacks.

These would be called if the server detected that a connection from a client had died. Maybe by refreshing leases by some kind of ping mechanism as you described.

Is that something you would consider adding to remoting?

[tom.elrod]

Sure. Do you mind opening a jira issue for this? Also, when do you need this by?

[timfox]

Sure. Do you mind opening a jira issue for this?

Sure

Also, when do you need this by?

ASAP I guess.
This would be critical for JBossMessaging to work properly.
Is there a lot of work involved?

[timfox]

Issue opened: http://jira.jboss.com/jira/browse/JBREM-233

[tom.elrod]

Ok. Only reason I ask about timing is that we are about to release 1.4.0 final of remoting. I would prefer to push this feature off to 1.6.0 release so are not adding new functionality between a beta and final release. The issue there is that 1.6.0 won't be done for a while (have not even scheduled it yet at this point). I could add this feature to the code base for 1.6.0 and you could work off of a snapshot while we finish out the rest of the 1.6.0, but don't konw if that will work for you?

[ovidiu.feodorov]

Yes, that sounds great. We've worked off snapshots before. This is why JBoss Messaging code base has a src/resources directory.

Please let us know when you have an alpha version (or any version at all, for that matter) available.

[tom.elrod]

Just an update. Probably going to be at least a few weeks before I can get to this. Feel free to nag me if don't see something from me by late Nov.