[jira] Created: (RIVER-156) sequence numbers from strong clean calls should eventually be discarded

["Bob Scheifler (JIRA)" <ji...@apache.org>]

sequence numbers from strong clean calls should eventually be discarded
-----------------------------------------------------------------------

                 Key: RIVER-156
                 URL: https://issues.apache.org/jira/browse/RIVER-156
             Project: River
          Issue Type: Bug
          Components: net_jini_jeri
    Affects Versions: jtsk_2.0
            Reporter: Bob Scheifler
            Priority: Trivial


Bugtraq ID [4852243|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4852243]

After receiving a DGC clean call with strong=true, the sequence number entry for the client UUID with the given remote object is retained (its "keep" flag is set to true), in order to protect against a non-malicious dirty call with a lower sequence number that might yet be delivered (out of order).  Currently, such a sequence number entry is kept forever (well, until the remote object is unexported, or its VM terminates).

In theory, this behavior is a possible memory leak in a very long running application that exports DGC-enabled remote objects, although in practice (given the sequence of events that need to occur repeatedly for it to proceed) the leak would be likely be slow enough to be minimally perceptible.

The specification for net.jini.jeri.BasicJeriExporter, as part of its discussion of the server-side behavior of DGC clean calls, has this to say about how long keep=true sequence number entries should be retained:

	If strong is true, then a record is kept of the specified sequence
	number from the DGC client for some reasonable period of time, in the
	event of a dirty call that might arrive later with a lower sequence
	number.

There's only so long that we should need to worry about such a non-malicious, late dirty call getting delivered.  The TCP specification uses two minutes for a reasonable maximum segment lifetime to expect.  It seems that keep=true sequence number entries should be discarded (or at least their "keep" flag can be cleared, if another dirty call for the client VMID has been received) after some reasonable period of time-- perhaps on the order of several minutes, or even hours/days, if we want to be conservative and guard against custom transport mechanisms in which the maximum lifetime of a dirty call could be higher.

Comments

Note that we do not need to worry about retaining keep=true sequence number entries because of RMI-level retries of dirty calls, because such dirty call retries (unlike clean call retries) always use a new sequence number and a set of object identifiers that reflects the correspondingly newer state of reachability of live remote references in the client VM.  This aspect of client-side DGC behavior is not specified, but hopefully it is common sense...

peter.jones@sun.com 2004-05-28

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.