river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sim IJskes - QCG <...@qcg.nl>
Subject Re: strange problem with DGC
Date Fri, 05 Mar 2010 08:32:10 GMT
Peter Firmstone wrote:
> What exception does the client throw?

[-] FINE 
com.sun.jini.jeri.internal.runtime.ObjectTable$Target.collect: garbage 
collection of object with id 51eb1fe7-0b11-41c7-80e9-daad9065e2ee


[-] FAILED  net.jini.jeri.BasicInvocationHandler.invoke: outbound call 
nl.qcg.jini.jeri.mekong.internal.conn.MekongConnectionService.sendOutput 
remotely throws
java.rmi.NoSuchObjectException: no such object in table
         at 
net.jini.jeri.BasicObjectEndpoint.executeCall(BasicObjectEndpoint.java:420)

> What's the lease duration?  

Default, is it 10 minutes?

> Is the lease expiring prior to the the first dirty call?

It too quick for expiry, it looks like the GC cleaning the object out, 
before the DGC can take over.

> 
> Does it relate to River-142?
> 
> https://issues.apache.org/jira/browse/RIVER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel


I don't think so. There is no concurrency on the references.

I can't find any code that would suggest a 'bridge' time granted from 
the moment of export to the first DgcServer.dirty. I think it is 
possible (when it's a bug) it has never been detected earlier because in 
my experience the _18 release of the VM has much more aggresive GC.

One could say it is documented behaviour, but then, it's not very pratical.

I've included a shortlived reference keeper, and the thing works like a 
charm now.

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397

Mime
View raw message