[omniORB] Dynamic destruction of servants when no clientreferences

[Steven King]

Mike,

We have just received the Henning and Vinoski book, I wish we had bought
it earlier. :)

The hit() method is invoked by the server onto a clients listener
servant. We thought that if this fails, then we know that the client
does not want use of the Document interface and we can clean up the
Document POA that was created and hence all servants created as part of
that Document.

The client activates a listener servant on its POA and passes a
reference to this with the request for a Document.  It then deactivates
the servant when it no longer wants use of the Document interface.  Done
so by wrapping up the Document interface in another class on the client
side.

Hope this clears things up,  (I can post some code if you like)

Steve

Okeefe, Michael K wrote:

 > "For each client that is no
 > longer connected to the ORB (by checking a hit() method on the Listener
 > interface), I destory() the POA associated with that clients 
connection. "
 >
 > There is a great example, I believe called the "Pacific Ocean
 > Problem", in Henning & Vinoski.  The idea is that once you've shipped
 > out the object reference (in the example, a message in a bottle), it's
 > out of your control, i.e. it's hard to say whether the client is
 > disconnected or not.
 >
 > Therefore, how does your hit() method work?  Is it that you have
 > someway of telling that the connection is active, i.e. you are either
 > sending or receiving (or processing), and once that completes, the
 > reference would not be reused?  If so, what if it fails to complete?
 >
 > -Mike
 >
 >
 > -----Original Message-----
 > From: omniorb-list-bounces at omniorb-support.com
 > [mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of Steven 
King
 > Sent: Friday, April 15, 2005 2:28 AM
 > To: omniorb-list at omniorb-support.com
 > Subject: Re: [omniORB] Dynamic destruction of servants when no
 > clientreferences
 >
 >
 > Okeefe, Michael K wrote:
 >
 > >"Duncan has made a game example application that shows how to do the
 > >child poa
 > >creation and registering of the objects. Google for it. "
 > >
 > >Here's the link I think you're referring to, it covers factory pattern,
 > >garbage collection, and more:
 > >http://www.grisby.org/presentations/py10tut.pdf
 > >
 > >
 > >_______________________________________________
 > >omniORB-list mailing list
 > >omniORB-list at omniorb-support.com
 > >http://www.omniorb-support.com/mailman/listinfo/omniorb-list
 > >
 > >
 > Thanks for you help,
 >
 > I thought that I would let the list know of the solution we ended up
 > using for reference, please comment and critique.
 >
 > Each client connection made to request a DOM Document causes a new
 > Document servant to be created.  This servant is registered on new
 > unique POA (using the rootPOA and the POA Manager of the root POA).
 >  Each client is also required to implement a Listener interface and pass
 > it with the request for the Document.  This listener and the created POA
 > is registered onto a Document Clients register.
 > Each servant created by operations on the Document are attached to the
 > same POA as that Document.
 >
 > Upon initialisation, a cleaning thread is created which runs every 30
 > seconds or so.  The cleaning thread iterates through the list of known
 > clients from the DocumentClients register.  For each client that is no
 > longer connected to the ORB (by checking a hit() method on the Listener
 > interface), I destory() the POA associated with that clients connection.
 >  This destroy in turn cleans up all of the servants registered to this
 > POA (calls all of their destructors).
 >
 > This was done because:
 > 1) We wanted to know when a client was finished and not just remove the
 > servants without the clients knowledge.
 >      Some clients will be connected for very long periods of time - with
 > potentially long wait times between requests.
 > 2) Elegantly clean up all of the servants created from within the
 > context of DOM Document servant.
 > 3) Fitted in well with our DOM Document caching mechanism (the cache
 > needed to be reevaluated every so often)
 >
 > Please feel free to comment,
 >
 > Thanks,
 >
 > Steve
 > --
 >
 > <http://www.eminence.com.au/> Eminence Technology Pty Ltd
 > PO Box 118, Moorooka QLD 4105
 > Web: www.eminence.com.au <http://www.eminence.com.au/>
 > Ph: +61-7-3277-4100
 > Fax: +61-7-3277-4577
 >


-- 


<http://www.eminence.com.au/> Eminence Technology Pty Ltd
PO Box 118, Moorooka QLD 4105
Web: www.eminence.com.au <http://www.eminence.com.au/>
Ph: +61-7-3277-4100
Fax: +61-7-3277-4577