The server-side DGC implementation for J2SE RMI (JRMP) has both of the bugs described in 4852216 (which represents these bugs for the server-side DGC implementation of net.jini.jeri.BasicJeriExporter, which were fixed in JSK 2.0).

Please see 4852216 for a description of these bugs.

The server-side DGC implementation for J2SE RMI (JRMP) also has the bug described in 4852243 (which represents this bug for the server-side DGC implementation of net.jini.jeri.BasicJeriExporter and has not yet been fixed).

Here is a reiteration of that bug:

After receiving a DGC clean call with strong=true, the sequence number entry for the client VMID 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 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.

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.