You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org> on 2007/07/27 16:17:18 UTC
[jira] Created: (RIVER-99) consider replacing "mux writer" threads
with asyncronous tasks
consider replacing "mux writer" threads with asyncronous tasks
--------------------------------------------------------------
Key: RIVER-99
URL: https://issues.apache.org/jira/browse/RIVER-99
Project: River
Issue Type: Improvement
Components: net_jini_jeri
Affects Versions: jtsk_2.1
Reporter: Thomas Vinod Johnson
Priority: Minor
Bugtraq ID [6313649|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6313649
When not operating in NIO mode, for each multiplexed JERI connection (i.e. connections with the tcp, ssl, and kerberos transport providers, and any others based on the net.jini.jeri.connection.ConnectionManager APIs) there are two threads that run for the lifetime of the connection: a "mux reader" thread and a "mux writer" thread.
The per-connection "mux reader" thread is required in order to continuously read from the connection (only the NIO mode can avoid this requirement), but the per-connection "mux writer" thread could possibly be avoided-- most of the time it simply waits on a queue for data to write to the connection. Instead of having a dedicated "mux writer" thread per connection, all connections could share a thread pool of unbounded concurrency for asynchronously processing write tasks in the connections' queues when they are non-empty. This change could significantly reduce the instantaneous thread count requirement when not using NIO mode connections, especially to the extent that many open connections are simply idle (before timing out). Performance impact of such a change would need to be measured, of course.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-99) consider replacing "mux writer" threads
with asyncronous tasks
Posted by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Vinod Johnson updated RIVER-99:
--------------------------------------
Description:
Bugtraq ID [6313649|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6313649]
When not operating in NIO mode, for each multiplexed JERI connection (i.e. connections with the tcp, ssl, and kerberos transport providers, and any others based on the net.jini.jeri.connection.ConnectionManager APIs) there are two threads that run for the lifetime of the connection: a "mux reader" thread and a "mux writer" thread.
The per-connection "mux reader" thread is required in order to continuously read from the connection (only the NIO mode can avoid this requirement), but the per-connection "mux writer" thread could possibly be avoided-- most of the time it simply waits on a queue for data to write to the connection. Instead of having a dedicated "mux writer" thread per connection, all connections could share a thread pool of unbounded concurrency for asynchronously processing write tasks in the connections' queues when they are non-empty. This change could significantly reduce the instantaneous thread count requirement when not using NIO mode connections, especially to the extent that many open connections are simply idle (before timing out). Performance impact of such a change would need to be measured, of course.
was:
Bugtraq ID [6313649|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6313649
When not operating in NIO mode, for each multiplexed JERI connection (i.e. connections with the tcp, ssl, and kerberos transport providers, and any others based on the net.jini.jeri.connection.ConnectionManager APIs) there are two threads that run for the lifetime of the connection: a "mux reader" thread and a "mux writer" thread.
The per-connection "mux reader" thread is required in order to continuously read from the connection (only the NIO mode can avoid this requirement), but the per-connection "mux writer" thread could possibly be avoided-- most of the time it simply waits on a queue for data to write to the connection. Instead of having a dedicated "mux writer" thread per connection, all connections could share a thread pool of unbounded concurrency for asynchronously processing write tasks in the connections' queues when they are non-empty. This change could significantly reduce the instantaneous thread count requirement when not using NIO mode connections, especially to the extent that many open connections are simply idle (before timing out). Performance impact of such a change would need to be measured, of course.
Fix bugraq ID URL
> consider replacing "mux writer" threads with asyncronous tasks
> --------------------------------------------------------------
>
> Key: RIVER-99
> URL: https://issues.apache.org/jira/browse/RIVER-99
> Project: River
> Issue Type: Improvement
> Components: net_jini_jeri
> Affects Versions: jtsk_2.1
> Reporter: Thomas Vinod Johnson
> Priority: Minor
>
> Bugtraq ID [6313649|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6313649]
> When not operating in NIO mode, for each multiplexed JERI connection (i.e. connections with the tcp, ssl, and kerberos transport providers, and any others based on the net.jini.jeri.connection.ConnectionManager APIs) there are two threads that run for the lifetime of the connection: a "mux reader" thread and a "mux writer" thread.
> The per-connection "mux reader" thread is required in order to continuously read from the connection (only the NIO mode can avoid this requirement), but the per-connection "mux writer" thread could possibly be avoided-- most of the time it simply waits on a queue for data to write to the connection. Instead of having a dedicated "mux writer" thread per connection, all connections could share a thread pool of unbounded concurrency for asynchronously processing write tasks in the connections' queues when they are non-empty. This change could significantly reduce the instantaneous thread count requirement when not using NIO mode connections, especially to the extent that many open connections are simply idle (before timing out). Performance impact of such a change would need to be measured, of course.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.