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
