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] Work started: (RIVER-254) request initiation can block on I/O for inapplicable connection
Date Mon, 07 Apr 2008 22:13:24 GMT

     [ https://issues.apache.org/jira/browse/RIVER-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Work on RIVER-254 started by Peter Jones.

> request initiation can block on I/O for inapplicable connection
> ---------------------------------------------------------------
>
>                 Key: RIVER-254
>                 URL: https://issues.apache.org/jira/browse/RIVER-254
>             Project: River
>          Issue Type: Bug
>          Components: net_jini_jeri
>    Affects Versions: jtsk_2.0
>            Reporter: John McClain
>            Assignee: Peter Jones
>            Priority: Minor
>             Fix For: AR2
>
>         Attachments: partialDump.zip
>
>
> Bugtraq ID [6307813|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6307813]
> The following blocked state of several threads attempting to initiate a request to the
same net.jini.jeri.connection-based endpoint has been observed (see attached partial thread
dump):
> (A) thread blocked in com.sun.jini.jeri.internal.mux.Mux.start waiting synchronously
for the receipt of the ServerConnectionHeader message over a new connection while holding
the lock for the ConnectionManager.OutboundMux instance for that connection
> (B) thread holding the lock for the ConnectionManager for the endpoint while trying to
determine the active and idle connections to pass to ConnectionEndpoint.connect, blocked waiting
to acquiring the lock for the OutboundMux instance (in order to determine whether it is active
or idle)
> (C) many threads blocked waiting to acquire the lock for the ConnectionManager for the
endpoint in order to initiate a new request to that endpoint
> (D) the reaper thread for the ConnectionManager waiting to acquire the lock for the ConnectionManager
in order to check for idle connections
> For TcpEndpoint, this situation might not seem so bad, because effectively all of thread
types (A), (B), and (C) are attempting to initiate a request to the same endpoint, and (A)
has an established connection that should be usable for all of those threads (established
connections to the same endpoint are effectively equal as far as TcpEndpoint is concerned--
constraints do not make one connection more or less suitable for a given request), so they
all might as well wait for (A) to complete, successfully or otherwise-- there is not much
reason to believe that the other threads would have better fortune were they to attempt to
establish new connections concurrently with (A).
> For other net.jini.jeri.connect-based endpoints, however, like SslEndpoint and KerberosEndpoint,
constraints can make a given connection not applicable or not preferable for a given request,
and therefore it is more clearly a bug that initiating a request can block on the receipt
of a ServerConnectionHeader message for any other connection to the endpoint.

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


Mime
View raw message