river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: strange problem with DGC
Date Fri, 05 Mar 2010 01:38:58 GMT
N.B. The reasoning behind my thoughts about using OSGi bundles for 
activation is; all services could reside in one JVM along with the OSGi 
framework and the mechanism for Activation, reducing memory consumption.

Peter Firmstone wrote:
> 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
>>>>
>>>
>>>
>>
>>
>
>


Mime
View raw message