You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Sim IJskes (JIRA)" <ji...@apache.org> on 2010/03/08 09:51:27 UTC
[jira] Created: (RIVER-331) improve documentation to include the
role of AcknowledgmentSource in DGC
improve documentation to include the role of AcknowledgmentSource in DGC
------------------------------------------------------------------------
Key: RIVER-331
URL: https://issues.apache.org/jira/browse/RIVER-331
Project: River
Issue Type: Improvement
Components: net_jini_core
Environment: documentation
Reporter: Sim IJskes
improve documentation to include the role of AcknowledgmentSource in DGC
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-331) improve documentation to include the
role of AcknowledgmentSource in DGC
Posted by "Sim IJskes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842584#action_12842584 ]
Sim IJskes commented on RIVER-331:
----------------------------------
from email:
After export, you get a Proxy with a reference to a BasicInvocationHandler with a reference to a BasicObjectEndpoint with a reference to a ImplContainer with a reference to your service.
As long as you keep the reference to the exported service, the service is 'strongly reachable' from the exported service.
The problem starts when you marshall it in BasicInvocationDispatcher.marshalReturn(), and the reply has enough latency to arive 'late' at the client side.
In this window the service becomes 'weakly reachable' and if the GC kicks in before DgcServer.dirty the object gets finalized.
> improve documentation to include the role of AcknowledgmentSource in DGC
> ------------------------------------------------------------------------
>
> Key: RIVER-331
> URL: https://issues.apache.org/jira/browse/RIVER-331
> Project: River
> Issue Type: Improvement
> Components: net_jini_core
> Environment: documentation
> Reporter: Sim IJskes
>
> improve documentation to include the role of AcknowledgmentSource in DGC
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-331) improve documentation to include the
role of AcknowledgmentSource in DGC
Posted by "Sim IJskes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842586#action_12842586 ]
Sim IJskes commented on RIVER-331:
----------------------------------
reply from Peter Jones:
Here is the way that this case is supposed to be covered:
- The OutputStream returned by InboundRequest.getResponseOutputStream on the server side implements net.jini.io.ObjectStreamContext, which contains an element that implements net.jini.io.context.AcknowledgmentSource.
- BasicObjectEndpoint.writeObject (which represents the "live references" in the DGC sense) detects this element during marshalling and registers an AcknowledgmentSource.Listener with it, which keeps the BasicObjectEndpoint strongly referenced until its acknowledgmentReceived method is invoked.
- When its acknowledgmentReceived method is invoked, either with true to indicate that the reading side has successfully unmarshalled the data (and thus registered the BasicObjectEndpoint with DGC) or with false to indicate that the transport layer has failed or given up, then the listener drops its strong reference.
The standard net.jini.jeri.* transport layer implementations should implement this AcknowledgmentSource protocol, but I'm wondering if you are using some other implementation that doesn't, or a layered implementation that needs to expose the underlying functionality.
I'm surprised (or I should say embarrassed) to see that the relationship between DGC and this AcknowledgmentSource protocol is not clearly called out in the net.jini.jeri package spec-- the mechanism only seems to be covered in the serialized form spec for BasicObjectEndpoint.writeObject.
FYI, this return value case was well anticipated (back to [1]), it's actually the parameter case that can be surprisingly vulnerable to modern JVM GC improvements:
http://bugs.sun.com/view_bug.do?bug_id=6181943
although that bug was for JRMP, and JERI's BasicInvocationHandler is incidentally not susceptible to that problem because of the OutboundRequestIterator.
-- Peter
[1] http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-116.pdf
> improve documentation to include the role of AcknowledgmentSource in DGC
> ------------------------------------------------------------------------
>
> Key: RIVER-331
> URL: https://issues.apache.org/jira/browse/RIVER-331
> Project: River
> Issue Type: Improvement
> Components: net_jini_core
> Environment: documentation
> Reporter: Sim IJskes
>
> improve documentation to include the role of AcknowledgmentSource in DGC
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.