river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Jones (JIRA)" <j...@apache.org>
Subject [jira] Commented: (RIVER-229) reduce number of Reaper threads created by ConnectionManager
Date Thu, 24 Apr 2008 18:03:21 GMT

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

Peter Jones commented on RIVER-229:

Implementing RIVER-229 should help reduce thread counts for some users.  Some notes on this

The idea is to use only (at most) one reaper thread for all connection managers (i.e. all
connection-based endpoints).  This change maintains a static set of all connection managers
that need to be reaped by the shared thread, which are the managers with open connections
or connections pending open, and it actually makes use of the pendingConnects flag again.
 The reason for the flag is to avoid deadlock: we don't want to add the manager to the reaperSet
while synchronized on the manager's lock, because the reaper itself needs to acquire the manager's
lock when it invokes checkIdle, during which it will already have the reaperSet lock because
of iteration.

I removed the connectPending method because pendingConnects only gets incremented in one place,
and the decrement already occurs in a finally block in the connect(ORH) method, so I thought
that it was more symmetric to have the increment inlined in the same method (rather than the
existence of the connectPending method leading a reader to track down where it gets invoked...).

I don't think that the static reaperSet introduces any new reachability problems, because
a manager should only stay in the set as long as its own reaper thread would have been alive,
keeping it reachable, with the previous implementation.

The non-emptiness of reaperSet is used to indicate that the reaper thread is already running
(while synchronized on the set), so the "reaper" field is no longer necessary.  In particular,
this change fixes RIVER-242 because if an OutOfMemoryError (for example) occurs trying to
create the reaper, reaperSet will be left empty, and so next time a connection is attempted,
we will try to create the thread again.

I didn't write any automated tests for these changes, but I have tested RIVER-229 manually:
idle connections still get reaped, but only one reaper thread gets created.  RIVER-242 seems
tricky to test even manually, and it was only discovered it by code inspection, and I think
that it is pretty clearly no longer an issue by code inspection too.

> reduce number of Reaper threads created by ConnectionManager
> ------------------------------------------------------------
>                 Key: RIVER-229
>                 URL: https://issues.apache.org/jira/browse/RIVER-229
>             Project: River
>          Issue Type: Improvement
>          Components: net_jini_jeri
>    Affects Versions: jtsk_2.0
>            Reporter: Jim Hurley
>            Assignee: Peter Jones
>            Priority: Minor
>             Fix For: AR2
>         Attachments: RIVER-229.patch
> Bugtraq ID [6291824|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6291824]
> Each ConnectionManager instance currently spawns its own Reaper thread to close down
idle connections. If a client communicates with lots of different endpoints in a relatively
short time interval, lots of threads get spawned. It should be possible to use a shared thread
> See also Bugtraq ID 6319638

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

View raw message