cleaning up server side callback handlers

[tom.elrod]

With regards to JBREM-117, need a way for server side callback back handlers to clean up when detect client callback servers are dead. This only applies to push callbacks where try to deliver callbacks to remote callback server and continue to get HandleCallbackExceptions.

I am good with how to implement this, but the question is when to know when this is appropriate. Is really the target handler that would best know when to give up and clean up. Putting some arbitrary exception counter would work technically, but what should this number be set to? Are there cases when target handler does not ever want the server side callback handler to clean itself up but continue to throw it exceptions?

[timfox]

Looks like we forget to respond to this one, sorry :(

Just to clarify what we'd like.

We's liket an ability to install an exception listener, but on the server side.

Currently we can do this on the client side, but not on the server side.

We don't want remoting to clean anything up automatically, we just want it to inform us when it finds the connection is broken so that we can do our own cleanup.

From the server side we currently don't know the connection is broken until we try and send on it.

Imgaine the case where a JMS connection has died, but no messages are being sent on it.

Since no messages are being sent, we get no exceptions so we don't know the connection is dead. Therefore it sits around potentially for ever with all the associated application level resources it has allocated.

I guess this would require some kind of ping to impement.

When discussed some time ago, you suggested implementing a kind of "lease" on the ping so if clients didn't ping within a certain amount of time, remoting would consider it broken and call our exception handler.

Just to clarify, we don't want remoting to do any cleanup automatically, simply to call a server side exception handler so we can do this.

I agree, what to cleanup is an application level issue, and varies from app to app.

HTH

Tim

[timfox]

Tom-

Do you need any more information on this, or are you good to go?

Thx

[tom.elrod]

Am good for now. Thanks.

[timfox]

Tom-

The server side connection listeners don't appear to be working.

I am registering a ConnectionListener with the Connector, then later on a Client instance for the connection either disconnects or the client process dies, but my ConnectionListener doesn't get invoked in either case.

I have sent you a test case to demonstrate this.

Perhaps I am doing something wrong?

[tom.elrod]

Ok. So a few thing with the test case. First, must explicitly set the lease period and add a connection listener for leasing to be triggered. So would need:

serverConnector.setLeasePeriod(1000);
serverConnector.addConnectionListener(new SimpleConnectionListener());


Second, since the server and client are in same VM, when the connect() is called on the Client class, it ask the client invoker if is already connected. Since is local, will always say that it is connected. This causes the initial request by the client to setup the lease to be by-passed. Therefore, the lease won't even be started on the server side until the first invocation from the client to the server is made. Even worse, after this first invocation is made and the server sets up its lease for the client, the client will NOT be sending a lease renewal because it was never started up (since the connect() call by-passed this).

So I have created a jira issue for this (JBREM-313). Although not working locally, should work if remote.

[tom.elrod]

Is fixed now for local case.

[timfox]

The test was adding a connectionlistener, it just wasn't setting a leasePeriod.

I (wrongly) assumed this was defaulted and setLeasePeriod was only used to set it to some other value than the default.

After setting the leasePeriod it seems to work.