river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RIVER-142) concurrency problem in DGC lease expiration handling
Date Sat, 14 Jan 2012 11:08:39 GMT

    [ https://issues.apache.org/jira/browse/RIVER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186160#comment-13186160

Hudson commented on RIVER-142:

Integrated in River-trunk #504 (See [https://builds.apache.org/job/River-trunk/504/])

Affects only River 2.2.0, this bug causes a memory leak by creating new threads unnecessarily.

> 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
>             Fix For: River_2.2.0
>         Attachments: River-142.patch
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message