[
https://issues.apache.org/jira/browse/RIVER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on RIVER-142 started by Peter Firmstone.
> concurrency problem in DGC lease expiration handling
> ----------------------------------------------------
>
> Key: RIVER-142
> URL: https://issues.apache.org/jira/browse/RIVER-142
> Project: River
> Issue Type: Bug
> Components: net_jini_jeri
> Affects Versions: jtsk_2.0
> Reporter: Peter Jones
> Assignee: Peter Firmstone
> Priority: Minor
>
> Bugtraq ID
> [4848840|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4848840]
> In the server-side DGC implementation's thread that check's for lease
> expirations
> ({{com.sun.jini.jeri.internal.runtime.ObjectTable.LeaseChecker.run}}), it
> checks for them while synchronized on the overall lease table, but it delays
> notifying the expired leases' individual registered {{Targets}} about the
> expirations until after it has released the lease table lock. This approach
> was taken from the JRMP implementation, which is that way because of the fix
> for 4118056 (a previous deadlock bug-- but now, I'm thinking that the JRMP
> implementation has this bug too).
> The problem seems to be that after releasing the lease table lock, it is
> possible for another lease renewal/request to come in (from the same DGC
> client and for the same remote object) that would then be invalidated by the
> subsequent {{Target}} notification made by the lease expiration check
> thread-- and thus the client's lease renewal (for that remote object) will be
> forgotten. It would appear that the synchronization approach here needs to
> be reconsidered.
> h4. ( Comments note: )
> In addition to the basic problem of the expired-then-renewed client being
> removed from the referenced set, there is also the problem of the sequence
> table entry being forgotten-- which prevents detection of a "late clean call".
> Normally, late clean calls are not a problem because sequence numbers are
> retained while the client is in the referenced set (and there is no such
> thing as a "strong dirty"). But in this case, with the following order of
> events on the server side:
> # dirty, seqNo=2
> # (lease expiration)
> # clean, seqNo=1
> The primary bug here is that the first two events will leave the client
> missing from the referenced set. But the secondary bug is that even if
> that's fixed, with the sequence number forgotten, the third event (the "late
> clean call") will still cause the client to be removed from the referenced
> set.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
