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:36 UTC
[jira] Created: (RIVER-254) request initiation can block on I/O for
inapplicable connection
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.
*** (#1 of 1): 2005-08-08 14:22:36 EDT peter.jones@sun.com
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (RIVER-254) request initiation can block on
I/O for inapplicable connection
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (RIVER-254) request initiation can block on I/O for
inapplicable connection
Posted by "John McClain (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (RIVER-254) request initiation can block on I/O
for inapplicable connection
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Jones resolved RIVER-254.
-------------------------------
Resolution: Fixed
> 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, RIVER-254.patch
>
>
> 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.
[jira] Commented: (RIVER-254) request initiation can block on I/O
for inapplicable connection
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586614#action_12586614 ]
Peter Jones commented on RIVER-254:
-----------------------------------
Regression test for this issue already exists in the qatests area, here:
source/vob/qa/jtreg/net/jini/jeri/connection/ConnectionManager/overlocking/Overlocking.java
> 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, RIVER-254.patch
>
>
> 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.
[jira] Updated: (RIVER-254) request initiation can block on I/O for
inapplicable connection
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Jones updated RIVER-254:
------------------------------
Attachment: RIVER-254.patch
Attached patch for this issue.
> 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, RIVER-254.patch
>
>
> 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.
[jira] Updated: (RIVER-254) request initiation can block on I/O for
inapplicable connection
Posted by "John McClain (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John McClain updated RIVER-254:
-------------------------------
Suggested Fix:
This bug could probably be fixed by rearrangement of the synchronization in ConnectionManager, but alternatively, it might be preferable to fix it by moving the blocking to receive ServerConnectionHeader to later I/O operations, like when the first data is to be written for the request, to allow for more pipelined processing on the client side, like creating an initial buffer of data to send for the request.
> 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
> 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.
[jira] Updated: (RIVER-254) request initiation can block on I/O for
inapplicable connection
Posted by "John McClain (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John McClain updated RIVER-254:
-------------------------------
Attachment: partialDump.zip
> 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
> 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.
[jira] Commented: (RIVER-254) request initiation can block on I/O
for inapplicable connection
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592103#action_12592103 ]
Peter Jones commented on RIVER-254:
-----------------------------------
Some notes on this fix:
I believe that the original intention for the distinction between the ConnectionManager instance lock and the OutboundMux instance lock was that a whole ConnectionManager (which manages all connections to an endpoint) would not get held up while one of its OutboundMux instances (representing one connection to the endpoint) was blocking on the connection handshake-- thus why ConnectionManager.connect doesn't just do the whole MuxClient.newRequest itself, and thus the need for the newRequestsPending counter, etc. The problem with this intention was that there are plenty of occasions in which an OutboundMux's lock is acquired while holding the enclosing ConnectionManager's lock anyway, and thus (indirectly) the whole ConnectionManager can get held up waiting for the OutboundMux to complete a connection handshake.
The fix is to assign the locks used to enforce exclusion on ConnectionManager & OutboundMux state differently. An OutboundMux has the following state variables that can be access concurrently:
pendingNewRequests
idleTime
pendingStart
It turns out that pendingNewRequests and idleTime are often accessed while holding the ConnectionManager's lock anyway-- the only path by which they aren't is in OutboundMux.newRequest, which is invoked by ReqIterator.next, but even then, it's not unreasonable to synchronize on the ConnectionManager's lock for their access, because it was just held earlier for the OutboundMux.connect invocation. The important thing is that it's not held during the Mux.start invocation. Therefore, the fix has ConnectionManager's lock used for the "pendingNewRequests" and "idleTime" state of all of the enclosed OutboundMux instances as well.
Some locking must be done around access of the pendingStart flag and the Mux.start invocation, because we don't want Mux.start invoked twice for the same connection, and we don't want a thread to proceed thinking that the mux has been started when the Mux.start invocation in another thread hasn't completed yet. Fortunately, it seems to me that this "mux start" locking is pretty independent of the other OutboundMux state and thus does not need to be done while holding the ConnectionManager lock.
As mentioned above, an automated test is here:
source/vob/qa/jtreg/net/jini/jeri/connection/ConnectionManager/overlocking/Overlocking.java
It uses a security manager to trick TcpEndpoint into wanting to use a different connection for a request to the same endpoint.
> 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, RIVER-254.patch
>
>
> 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.
[jira] Updated: (RIVER-254) request initiation can block on I/O for
inapplicable connection
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Jones updated RIVER-254:
------------------------------
Fix Version/s: AR2
Assignee: 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.
[jira] Closed: (RIVER-254) request initiation can block on I/O for
inapplicable connection
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone closed RIVER-254.
---------------------------------
> 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, RIVER-254.patch
>
>
> 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.