Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4B903A8B.3010508@zeus.net.au>
Date: Fri, 05 Mar 2010 08:56:11 +1000
From: Peter Firmstone <jini@zeus.net.au>
Organization: Zeus Project Services
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: strange problem with DGC
References: <4B8F86B0.6080305@qcg.nl> <4B903484.40701@zeus.net.au>
 <4B9036BA.8010701@zeus.net.au>
In-Reply-To: <4B9036BA.8010701@zeus.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Note that when you export your service it's proxy is stored in 
Marshalled form until the client discovers it, while in Marshalled form 
only, it cannot participate in DGC.  In that case you might want to hold 
a reference for a period of time (Lease), long enough to allow your 
clients to discover the service.

I've had thoughts about OSGi's use of bundle activation and 
deactivation, if a service is implemented in a bundle, the service id 
could be stored to disk on the dedicated area reserved for that 
particular bundle.   Another bundle might manage leases for several jini 
Services that are exported, activating them on demand.  There's always 
Phoenix of course, just some thoughts.

Cheers,

Peter.


Peter Firmstone wrote:
> Is DGC enabled?  It's disabled by default.
>
> Peter Firmstone wrote:
>> Sim IJskes - QCG wrote:
>>> Hello,
>>>
>>> i've got a strange problem with DGC.
>>>
>>> In a service, we create a service, export it with DGC, keep no 
>>> reference  of the service or exported service on the service side, 
>>> return it immediately to the caller.
>>>
>>> The expected behaviour is that from the moment of export, we get a 
>>> certain period for the exported service to be deserialized at the 
>>> caller side, and do our first DgcServer.dirty call.
>>>
>>> It turns out, that ObjectTable$Target.collect is called before the 
>>> first dirty call is done.
>> What exception does the client throw?
>>
>> What's the lease duration?  Is the lease expiring prior to the the 
>> first dirty call?
>>
>> Does it relate to River-142?
>>
>> https://issues.apache.org/jira/browse/RIVER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
>>
>>
>>>
>>> Is this expected behaviour? Should i bridge the time between the 
>>> export and the first dirty with a shortlived reference keeper? 
>>> Should i call dirty on the service side?
>>>
>>> Gr. Sim
>>>
>>
>>
>
>