You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "John McClain (JIRA)" <ji...@apache.org> on 2007/08/17 19:06:37 UTC
[jira] Updated: (RIVER-254) request initiation can block on I/O for
inapplicable connection
[ https://issues.apache.org/jira/browse/RIVER-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John McClain updated RIVER-254:
-------------------------------
Description:
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.
was:
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.
*** (#1 of 1): 2005-08-08 14:22:36 EDT peter.jones@sun.com
> 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
> Priority: Minor
>
> 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.