There is no notion of leases (apart from the threaded service model, which AFAICT allocates a separate service instance for each thread that asks for the service. These instances will be collected when their threads die). Once a particular service is used, it will live until the whole registry dies. There's no way to deregister a service, either.
If you need a service to shrink when it's not being used, you'll have to write the service that way yourself, using soft/weak references for example. Luke ---- Original message ---- >Date: Fri, 9 Apr 2004 08:49:45 -0400 >From: "Ronald V. Simmons" <[EMAIL PROTECTED]> >Subject: Re: Hivemind and Jini >To: [email protected] > >And one further follow up. Is there a concept of leases in Hivemind >that I've missed? > >Specifically, can the Registry reclaim resources being consumed by >unused services or does a service have to explicitly deregister to be >gc'd? > >rvs > >On Apr 9, 2004, at 6:28 AM, Ronald Simmons wrote: > >> Ok, so I'm new here, forgive me if this sounds like a troll. It is >> not intended to be one. >> >> I've read the documentation and am still left wondering what the >> intended design differences are between Hivemind and Jini. The >> important ones I have been able to discern so far are: >> >> 1 - No hot loading of code in Hivemind >> 2 - No defined tuplespace engine in Hivemind >> 3 - Non-XML config files in Jini >> 4 - No multi-cast discovery mechanisms for the registry in Hivemind >> 5 - No (or poor) integration with J2EE in Jini >> 6 - Apache licensing (Hivemind) vs SCSL licensing (Jini) >> >> I guess a place where the documentation leaves me a bit confused as >> well is with regards to remote invocation of services. Is it the case >> that I could write an RMI or WS interceptor for a Hivemind service and >> vend that in a Jini LUS or a WS Registry? If I'm right there, then I >> think I see how I'd use Jini, J2EE and Hivemind together. Otherwise, >> I'm extremely confused. >> >> Thoughts? >> >> rvs >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
