You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by re...@apache.org on 2006/03/25 00:59:57 UTC
svn commit: r388679 -
/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java
Author: remm
Date: Fri Mar 24 15:59:49 2006
New Revision: 388679
URL: http://svn.apache.org/viewcvs?rev=388679&view=rev
Log:
- Remove commented out code.
Modified:
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java
Modified: tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java
URL: http://svn.apache.org/viewcvs/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=388679&r1=388678&r2=388679&view=diff
==============================================================================
--- tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java Fri Mar 24 15:59:49 2006
@@ -90,24 +90,6 @@
/**
- * The acceptor thread.
- */
- //protected Thread[] acceptorThreads = null;
-
-
- /**
- * The socket poller thread.
- */
- //protected Thread[] pollerThreads = null;
-
-
- /**
- * The sendfile thread.
- */
- //protected Thread[] sendfileThreads = null;
-
-
- /**
* Available workers.
*/
protected WorkerStack workers = null;
@@ -606,7 +588,7 @@
// Initialize thread count defaults for acceptor, poller and sendfile
if (acceptorThreadCount == 0) {
- // FIXME: Default to one per CPU ?
+ // FIXME: Doesn't seem to work that well with multiple accept threads
acceptorThreadCount = 1;
}
if (pollerThreadCount == 0) {
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r388679 - /tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> just a small observation,
>
> working with multiple polling threads is pretty hard, we do it in the
> clustering code (NIO), on the receiver side of things,
> and it took a while to work out the kinks, and you need a shared place
> to lock, since a lot of the operations are not thread safe.
> The code becomes somewhat complex.
>
> I haven't made myself familiar enough of the APR code to comment there,
> but I can imagine the same scenario would be there. Usually a single
> thread, even on a multi CPU machine can perform all polling, as long as
> it doesn't do anything but read the buffer, then pass it on to a thread.
> If the poller thread starts doing more, such as putting packages
> together, copy data, deserialization etc, then you'll find yourself in a
> bottleneck.
>
> I like this guys approach,
> http://www.onjava.com/pub/a/onjava/2004/09/01/nio.html?page=1
> he had the same experience, one poller thread becomes way more
> manageable code, and he created a neat design of putting back
> registration request to happen async or sync.
It seems fine in our case.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r388679 - /tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
just a small observation,
working with multiple polling threads is pretty hard, we do it in the
clustering code (NIO), on the receiver side of things,
and it took a while to work out the kinks, and you need a shared place
to lock, since a lot of the operations are not thread safe.
The code becomes somewhat complex.
I haven't made myself familiar enough of the APR code to comment there,
but I can imagine the same scenario would be there. Usually a single
thread, even on a multi CPU machine can perform all polling, as long as
it doesn't do anything but read the buffer, then pass it on to a thread.
If the poller thread starts doing more, such as putting packages
together, copy data, deserialization etc, then you'll find yourself in a
bottleneck.
I like this guys approach,
http://www.onjava.com/pub/a/onjava/2004/09/01/nio.html?page=1
he had the same experience, one poller thread becomes way more
manageable code, and he created a neat design of putting back
registration request to happen async or sync.
Filip
remm@apache.org wrote:
> Author: remm
> Date: Fri Mar 24 15:59:49 2006
> New Revision: 388679
>
> URL: http://svn.apache.org/viewcvs?rev=388679&view=rev
> Log:
> - Remove commented out code.
>
> Modified:
> tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java
>
> Modified: tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java
> URL: http://svn.apache.org/viewcvs/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=388679&r1=388678&r2=388679&view=diff
> ==============================================================================
> --- tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
> +++ tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java Fri Mar 24 15:59:49 2006
> @@ -90,24 +90,6 @@
>
>
> /**
> - * The acceptor thread.
> - */
> - //protected Thread[] acceptorThreads = null;
> -
> -
> - /**
> - * The socket poller thread.
> - */
> - //protected Thread[] pollerThreads = null;
> -
> -
> - /**
> - * The sendfile thread.
> - */
> - //protected Thread[] sendfileThreads = null;
> -
> -
> - /**
> * Available workers.
> */
> protected WorkerStack workers = null;
> @@ -606,7 +588,7 @@
>
> // Initialize thread count defaults for acceptor, poller and sendfile
> if (acceptorThreadCount == 0) {
> - // FIXME: Default to one per CPU ?
> + // FIXME: Doesn't seem to work that well with multiple accept threads
> acceptorThreadCount = 1;
> }
> if (pollerThreadCount == 0) {
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org