river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John McClain (JIRA)" <j...@apache.org>
Subject [jira] Updated: (RIVER-254) request initiation can block on I/O for inapplicable connection
Date Fri, 17 Aug 2007 17:06:37 GMT

     [ 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.


Mime
View raw message