Notification on communicator shutdown

stephan

Hi!

Maybe I just need a pointer to the documentation but I cannot find the issue there

Is it possible to be notified when the communicator is about to be destroyed? The reason is that I would like to do 'one very last thing', i.e. logging out from a session manager on shutdown.

The alternative would be to use a smart singleton that also receives such a notification (it is being destroyed automatically on application destroyal). But this point should be too late since I assume that the communicator object will already be dead at the point where the singleton object is about to be deleted.

If you know a design alternative, I'd be eager to learn more about it

Kind regards,

Stephan

michi

Re: Notification on communicator shutdown

Originally posted by stephan
Is it possible to be notified when the communicator is about to be destroyed? The reason is that I would like to do 'one very last thing', i.e. logging out from a session manager on shutdown.

No, there is no such callback hook.

The alternative would be to use a smart singleton that also receives such a notification (it is being destroyed automatically on application destroyal). But this point should be too late since I assume that the communicator object will already be dead at the point where the singleton object is about to be deleted.

Right. At that point, shutdown has been initiated already, and it will be too late to make further requests.

We could add such a callback hook, but I'm not sure it would be worthwhile. For one, the callback would have to be invoked pretty much immediately after some thread initiates shutdown. But, at that point, other threads may still be making invocations. In that case, you would still require synchronization between the callback object that makes the "final" call, and other threads that still may still be active. Second, I'm reluctant to clutter the API with rarely-used and special-purpose functionality.

An easier way to achieve what you want would probably be, instead of calling shutdown() on the communicator directly, to call an appliaction function; that function can first perform its finalization actions and then call shutdown() on the communicator (and possibly call waitForShutdown() as well). I think this will give you what a callback hook would do, and is really no harder to implement.

So there is no need to modify the API as far as I can see?

Cheers,

Michi.

stephan

Re: Re: Notification on communicator shutdown

Hi Michi!

Thanks for your fast and detailed answer.
API cluttering should be avoided, that's true and an important issue.

I'll describe more briefly what I want to do to make more clear why I thought placing a communicator shutdown callback in Ice could be nice.

I'm planning to write a login API for Ice (I'll release the sources as soon as they are working) which should be somewhat similar to JAAS but work over Ice and allow access to arbitrary backend authorization and permission vaults.

Logging in, checking credentials is quite easy to realize I think but logging out is something I'm worrying about a little bit. The main reason is that I don't know about the framework that the app uses (at least in my case, it's Qt) and probably should not care too much.
But when it comes to the application's end, I'd like to delete the session object on the session server (which is necessary for providing permission database access). Sure can I add a 'closeMe' function to my singleton, but who makes sure that this function is being called at all.

I hope I didn't confuse you too much

regs,

Stephan

michi

Hi Stephan,

I see what you mean. But adding a callback hook to Ice still won't solve this problem: if the application terminates cleanly, it might as well call the finalization function itself, so no callback hook is necessary. But, more significantly, even with a callback hook, you still have no guarantee that the callback hook will actually be called. For example, the application could crash, power could fail, or someone could bring down the application with a kill -9.

Your problem really is of a more general nature, namely, how to reclaim resources in the server if the client goes away (abortively or cleanly). Welcome to the world of distributed garbage collection :-)

I can see two viable solutions:

1) Use an evictor in the server that reaps session objects that haven't been used for a long time. This strategy works and is simple to implement, provided that you can afford to waste a bit of memory for old session objects. (An evictor example ships with each Ice distribution in demo/book/evictor, and you can read about evictors in the advanced server chapter.)

2) Implement a leasing protocol, such that a session object is valid only for a certain amount of time. The client is responsible for renewing the lease by touching the session object before the timer expires; if the client does not do that, the server reaps the session object.

Approach 2 is more complex, but has the advantage that the life time of session objects is strictly bounded by the timeout, whereas, with the evictor it is only vaguely bounded. (And an evictor, if its cache is too small, can evict session objects that are still in use.)

Cheers,

Michi.

marc

Just a clarification: For the evictor approach, a non-persistent evictor must be used, which simply discards evicted session objects. This is not to confuse with the Freeze evictor, which evicts and saves on disk, and restores the evicted object transparently when it is needed again. This persistent approach wouldn't make sense for session objects, because such objects are transient by nature.

The second approach is what we use most often, but as Michi says, it's more work. You need to set a timestamp each time the client calls a method, and you need a thread that periodically checks which sessions have expired using this timestamp, removing idle sessions as appropriate. (Setting the timestamp is best done in a servant locator, so that you don't have to do this in each method implementation.)

The upcoming Glacier2 firewall and session manager will use exactly this method. Glacier1 works a bit differently: It has one router process per connected client, and it simply uses Ice.ServerIdleTime to make the router terminate (and with it the session) once the client becomes idle.

Perhaps it would be worthwhile to extract the session mangement part of Glacier2 into a demo, as how to do session management is one of the most frequently asked design questions.

rdilipk

2) Implement a leasing protocol, such that a session object is valid only for a certain amount of time. The client is responsible for renewing the lease by touching the session object before the timer expires; if the client does not do that, the server reaps the session object.

This is a bit off-topic but .NET remoting implements exactly this approach. If you want to see some examples you can search for the ILease interface at http://msdn.microsoft.com

michi

IONA's O2K provides something similar: http://www.iona.com/support/docs/orbix2000/2.0/session_cpp/html/UseLeasing2.html

It may be an idea to provide something like this for Ice as well. (If only the days had more hours... )

Cheers,

Michi.

marc

Well, Ice does have this, but integrated into a firewall only

stephan

Thanks for the Orbix info. CORBA isn't that bad after all?!

It may be an idea to provide something like this for Ice as well. (If only the days had more hours... )

I'm not trying to push you into an implementation, but what is the big deal/ secret behind the lease functionality on ORBIX? It's more or less about applying the active object, is it?

regs,

Stephan

michi

Originally posted by stephan
Thanks for the Orbix info. CORBA isn't that bad after all?!

:-)

Actually, that isn't CORBA, it's IONA-proprietary. CORBA doesn't specify anything relating to garbage collection or session management.

I'm not trying to push you into an implementation, but what is the big deal/ secret behind the lease functionality on ORBIX? It's more or less about applying the active object, is it?

No big deal/secret -- it's simply a bit of useful functionality. (The implementation isn't entirely trivial though.) I don't know what you mean by "applying the active object"?

Cheers,

Michi.

stephan

I don't know what you mean by "applying the active object"?

It was too early today... I was refering to the active object pattern. I.e. it would be possible to implement a remote object (the "leaseManager") that works by itself instead of being invoked all the time..

regs,

Stephan

michi

By "lease manager", I take it you mean a process that runs somewhere and automatically renews the leases for clients? If so, yes, that's one way of implementing this. Another way to do it is to run a background thread in each client that renews the leases.

The active object pattern really is about avoiding blocking in the calling process: instead of directly and synchronously executing a request, the caller calls an active object that queues the request, processes it at some convenient time, and returns the results later. (Ice supports this pattern through AMI and AMD.) I'm not sure where this pattern would be used in the context of distributed garbage collection and lease renewal... I guess you could consider the part of the system that reaps objects with expired leases as the active object. But all that really means is that there is something that runs asynchronously with respect to client and server. For example, reaping expired leases could be done by a background thread in the server.

Cheers,

Michi.