Multi threaded accept and polling
Hi, A long time ago (in this galaxy, not another one), Tomcat has added the capability to have multiple accept threads. I have no idea what test revealed that Tomcat was somehow not accepting sockets fast enough, and maybe it could be the case in crazy microbenchmarks, but this is not going to happen in the real world. If the server is too busy accepting, then what comes after the accept (SSL handshake maybe) is much worse and refusing sockets may be the most sensible behavior. Having multiple accept threads is also now a known antipattern. So I am proposing to hardcode acceptorThreadCount to 1 for all connectors. Same for polling basically. Polling occurs once a socket waits for data or backlogs for about an eternity (in CPU time), so a single polling thread is more than enough to handle this in a responsive enough way (BTW, I am interested in current data that demonstrates a responsiveness benefit). Earlier in the past, with APR and plain old select (and Windows !!), it was probably way more justified to allow having multiple threads. So I am also proposing to hardcode pollerThreadCount to 1 for NIO. I will leave the feature in for APR, just in case. Note: NIO 2 works properly, yet uses no dedicated accept thread (accept is now an async task that restarts itself once done), and internally has one internal thread for polling and one internal thread for timeouts. So ... Comments ? Rémy
Re: Multi threaded accept and polling
On 09/05/2019 12:45, Rémy Maucherat wrote: > Hi, > > A long time ago (in this galaxy, not another one), Tomcat has added the > capability to have multiple accept threads. I have no idea what test > revealed that Tomcat was somehow not accepting sockets fast enough, and > maybe it could be the case in crazy microbenchmarks, but this is not going > to happen in the real world. If the server is too busy accepting, then what > comes after the accept (SSL handshake maybe) is much worse and refusing > sockets may be the most sensible behavior. Having multiple accept threads > is also now a known antipattern. > So I am proposing to hardcode acceptorThreadCount to 1 for all connectors. > > Same for polling basically. Polling occurs once a socket waits for data or > backlogs for about an eternity (in CPU time), so a single polling thread is > more than enough to handle this in a responsive enough way (BTW, I am > interested in current data that demonstrates a responsiveness benefit). > Earlier in the past, with APR and plain old select (and Windows !!), it was > probably way more justified to allow having multiple threads. > So I am also proposing to hardcode pollerThreadCount to 1 for NIO. I will > leave the feature in for APR, just in case. > > Note: NIO 2 works properly, yet uses no dedicated accept thread (accept is > now an async task that restarts itself once done), and internally has one > internal thread for polling and one internal thread for timeouts. So ... > > Comments ? accept() is effectively synchronized at the OS level. I recall doing some testing on this and there was a small gain in throughput when testing on localhost without keep-alive if I used two accept threads. Essentially, one thread was accepting the next connection while the other was handing a connection off to a processing thread. There was no benefit for more than 2 accept threads. I also had to keep the total number of concurrent requests to ~number of available cores. I can think of no real world scenario where Tomcat would be accepting new connections fast enough with a low enough concurrency level for 2 accept threads be useful. +1 to hard-coding to a single acceptor thread and removing the plumbing that supports more than that. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Multi threaded accept and polling
On Thu, May 9, 2019 at 2:36 PM Mark Thomas wrote: > accept() is effectively synchronized at the OS level. > > I recall doing some testing on this and there was a small gain in > throughput when testing on localhost without keep-alive if I used two > accept threads. Essentially, one thread was accepting the next > connection while the other was handing a connection off to a processing > thread. There was no benefit for more than 2 accept threads. > I also had to keep the total number of concurrent requests to ~number of > available cores. > Ok. > > I can think of no real world scenario where Tomcat would be accepting > new connections fast enough with a low enough concurrency level for 2 > accept threads be useful. > > +1 to hard-coding to a single acceptor thread and removing the plumbing > that supports more than that. > Ok, done. So I suppose you prefer keeping the ability to have multiple poller threads for NIO ? Rémy
[tomcat] branch master updated: Remove acceptorThreadCount attribute
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new e9e9b22 Remove acceptorThreadCount attribute
e9e9b22 is described below
commit e9e9b2201069f8b0857c541018a7aa81a9cebe52
Author: remm
AuthorDate: Thu May 9 15:35:56 2019 +0200
Remove acceptorThreadCount attribute
Now hardcoded to one. Leave the attribute access methods as deprecated
for compatibility. Remove all relevant loops and fields.
---
java/org/apache/coyote/AbstractProtocol.java | 5 +-
.../apache/tomcat/util/net/AbstractEndpoint.java | 110 +
java/org/apache/tomcat/util/net/AprEndpoint.java | 42
java/org/apache/tomcat/util/net/Nio2Endpoint.java | 11 +--
java/org/apache/tomcat/util/net/NioEndpoint.java | 2 +-
webapps/docs/changelog.xml | 6 ++
webapps/docs/config/http.xml | 8 --
7 files changed, 80 insertions(+), 104 deletions(-)
diff --git a/java/org/apache/coyote/AbstractProtocol.java
b/java/org/apache/coyote/AbstractProtocol.java
index 51bdb3b..4e35f43 100644
--- a/java/org/apache/coyote/AbstractProtocol.java
+++ b/java/org/apache/coyote/AbstractProtocol.java
@@ -310,11 +310,12 @@ public abstract class AbstractProtocol implements
ProtocolHandler,
return endpoint.getConnectionCount();
}
+@Deprecated
public void setAcceptorThreadCount(int threadCount) {
-endpoint.setAcceptorThreadCount(threadCount);
}
+@Deprecated
public int getAcceptorThreadCount() {
- return endpoint.getAcceptorThreadCount();
+ return 1;
}
public void setAcceptorThreadPriority(int threadPriority) {
diff --git a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
index 8d01292..a33e192 100644
--- a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
@@ -172,9 +172,9 @@ public abstract class AbstractEndpoint {
}
/**
- * Threads used to accept new connections and pass them to worker threads.
+ * Thread used to accept new connections and pass them to worker threads.
*/
-protected List> acceptors;
+protected Acceptor acceptor;
/**
* Cache for SocketProcessor objects
@@ -406,10 +406,10 @@ public abstract class AbstractEndpoint {
*/
protected int acceptorThreadCount = 1;
-public void setAcceptorThreadCount(int acceptorThreadCount) {
-this.acceptorThreadCount = acceptorThreadCount;
-}
-public int getAcceptorThreadCount() { return acceptorThreadCount; }
+@Deprecated
+public void setAcceptorThreadCount(int acceptorThreadCount) {}
+@Deprecated
+public int getAcceptorThreadCount() { return 1; }
/**
@@ -923,13 +923,7 @@ public abstract class AbstractEndpoint {
*/
private void unlockAccept() {
// Only try to unlock the acceptor if it is necessary
-int unlocksRequired = 0;
-for (Acceptor acceptor : acceptors) {
-if (acceptor.getState() == AcceptorState.RUNNING) {
-unlocksRequired++;
-}
-}
-if (unlocksRequired == 0) {
+if (acceptor == null || acceptor.getState() != AcceptorState.RUNNING) {
return;
}
@@ -948,46 +942,42 @@ public abstract class AbstractEndpoint {
try {
unlockAddress = getUnlockAddress(localAddress);
-for (int i = 0; i < unlocksRequired; i++) {
-try (java.net.Socket s = new java.net.Socket()) {
-int stmo = 2 * 1000;
-int utmo = 2 * 1000;
-if (getSocketProperties().getSoTimeout() > stmo)
-stmo = getSocketProperties().getSoTimeout();
-if (getSocketProperties().getUnlockTimeout() > utmo)
-utmo = getSocketProperties().getUnlockTimeout();
-s.setSoTimeout(stmo);
-
s.setSoLinger(getSocketProperties().getSoLingerOn(),getSocketProperties().getSoLingerTime());
-if (getLog().isDebugEnabled()) {
-getLog().debug("About to unlock socket for:" +
unlockAddress);
-}
-s.connect(unlockAddress,utmo);
-if (getDeferAccept()) {
-/*
- * In the case of a deferred accept / accept filters
we need to
- * send data to wake up the accept. Send OPTIONS * to
bypass
- * even BSD accept filters. The Acceptor will discard
it.
- */
-OutputStreamWriter sw;
-
-sw = new OutputStreamWriter(s.getOutputStre
[tomcat] branch 8.5.x updated: Sync NIO2 IO code with trunk
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new 6f354d0 Sync NIO2 IO code with trunk
6f354d0 is described below
commit 6f354d040d5f170e51e12548edd46b6017f1465f
Author: remm
AuthorDate: Thu May 9 16:29:45 2019 +0200
Sync NIO2 IO code with trunk
---
.../catalina/security/SecurityClassLoad.java | 6 ++
.../apache/tomcat/util/net/AbstractEndpoint.java | 13
java/org/apache/tomcat/util/net/Nio2Endpoint.java | 69 ++-
.../apache/tomcat/util/net/SecureNio2Channel.java | 12 ++--
.../apache/tomcat/util/net/SocketWrapperBase.java | 80 ++
webapps/docs/changelog.xml | 16 +
6 files changed, 145 insertions(+), 51 deletions(-)
diff --git a/java/org/apache/catalina/security/SecurityClassLoad.java
b/java/org/apache/catalina/security/SecurityClassLoad.java
index 9caf2b8..a76515d 100644
--- a/java/org/apache/catalina/security/SecurityClassLoad.java
+++ b/java/org/apache/catalina/security/SecurityClassLoad.java
@@ -179,6 +179,12 @@ public final class SecurityClassLoad {
loader.loadClass(basePackage +
"util.net.NioBlockingSelector$BlockPoller$RunnableAdd");
loader.loadClass(basePackage +
"util.net.NioBlockingSelector$BlockPoller$RunnableCancel");
loader.loadClass(basePackage +
"util.net.NioBlockingSelector$BlockPoller$RunnableRemove");
+loader.loadClass(basePackage +
"util.net.Nio2Endpoint$Nio2SocketWrapper$OperationState");
+loader.loadClass(basePackage +
"util.net.Nio2Endpoint$Nio2SocketWrapper$VectoredIOCompletionHandler");
+loader.loadClass(basePackage +
"util.net.SocketWrapperBase$BlockingMode");
+loader.loadClass(basePackage +
"util.net.SocketWrapperBase$CompletionCheck");
+loader.loadClass(basePackage +
"util.net.SocketWrapperBase$CompletionHandlerCall");
+loader.loadClass(basePackage +
"util.net.SocketWrapperBase$CompletionState");
// security
loader.loadClass(basePackage + "util.security.PrivilegedGetTccl");
loader.loadClass(basePackage + "util.security.PrivilegedSetTccl");
diff --git a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
index 603bb47..2bc782e 100644
--- a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
@@ -152,6 +152,11 @@ public abstract class AbstractEndpoint {
private static final int MAX_ERROR_DELAY = 1600;
+public static long toTimeout(long timeout) {
+// Many calls can't do infinite timeout so use Long.MAX_VALUE if
timeout is <= 0
+return (timeout > 0) ? timeout : Long.MAX_VALUE;
+}
+
// - Fields
/**
@@ -740,6 +745,14 @@ public abstract class AbstractEndpoint {
public boolean getDaemon() { return daemon; }
+/**
+ * Expose asynchronous IO capability.
+ */
+private boolean useAsyncIO = true;
+public void setUseAsyncIO(boolean useAsyncIO) { this.useAsyncIO =
useAsyncIO; }
+public boolean getUseAsyncIO() { return useAsyncIO; }
+
+
protected abstract boolean getDeferAccept();
diff --git a/java/org/apache/tomcat/util/net/Nio2Endpoint.java
b/java/org/apache/tomcat/util/net/Nio2Endpoint.java
index ca94fe0..68c4136 100644
--- a/java/org/apache/tomcat/util/net/Nio2Endpoint.java
+++ b/java/org/apache/tomcat/util/net/Nio2Endpoint.java
@@ -31,6 +31,8 @@ import java.nio.channels.CompletionHandler;
import java.nio.channels.FileChannel;
import java.nio.channels.InterruptedByTimeoutException;
import java.nio.channels.NetworkChannel;
+import java.nio.channels.ReadPendingException;
+import java.nio.channels.WritePendingException;
import java.nio.file.StandardOpenOption;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
@@ -47,6 +49,9 @@ import org.apache.juli.logging.LogFactory;
import org.apache.tomcat.util.ExceptionUtils;
import org.apache.tomcat.util.collections.SynchronizedStack;
import org.apache.tomcat.util.net.AbstractEndpoint.Handler.SocketState;
+import org.apache.tomcat.util.net.SocketWrapperBase.BlockingMode;
+import org.apache.tomcat.util.net.SocketWrapperBase.CompletionHandlerCall;
+import org.apache.tomcat.util.net.SocketWrapperBase.CompletionState;
import org.apache.tomcat.util.net.jsse.JSSESupport;
/**
@@ -519,7 +524,7 @@ public class Nio2Endpoint extends
AbstractJsseEndpoint {
}
}
}
-getSocket().write(buffer, toNio2Timeout(getWriteTimeout()),
TimeUnit.MILLISECONDS, attachment, this);
+getSocket().write(buffer, toTimeout(getWriteTimeout()),
TimeUnit.MILLISECONDS, attachment,
Re: Multi threaded accept and polling
On 09/05/2019 14:38, Rémy Maucherat wrote: >> +1 to hard-coding to a single acceptor thread and removing the plumbing >> that supports more than that. > > Ok, done. Great. > So I suppose you prefer keeping the ability to have multiple poller threads > for NIO ? NIO defaults to 1 anyway. I agree with that multiple Poller threads is unlikely to offer a performance benefit in any realistic scenario. APR only supported multiple Poller threads because of a Windows XP / Server 2003 issue that limited poller size to 1024. Other than that, comments in the APR code indicate a preference for a single Poller. I've no objection to making a similar change to the pollerThreadCount. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in on tomcat-85-trunk
The Buildbot has detected a restored build on builder tomcat-85-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-85-trunk/builds/1765 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-85-commit' triggered this build Build Source Stamp: [branch 8.5.x] 6f354d040d5f170e51e12548edd46b6017f1465f Blamelist: remm Build succeeded! Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Multi threaded accept and polling
On Thu, May 9, 2019 at 4:47 PM Mark Thomas wrote: > On 09/05/2019 14:38, Rémy Maucherat wrote: > > > > >> +1 to hard-coding to a single acceptor thread and removing the plumbing > >> that supports more than that. > > > > Ok, done. > > Great. > > > So I suppose you prefer keeping the ability to have multiple poller > threads > > for NIO ? > > NIO defaults to 1 anyway. > > I agree with that multiple Poller threads is unlikely to offer a > performance benefit in any realistic scenario. > > APR only supported multiple Poller threads because of a Windows XP / > Server 2003 issue that limited poller size to 1024. Other than that, > comments in the APR code indicate a preference for a single Poller. > Yes, I ran into that then ... > > I've no objection to making a similar change to the pollerThreadCount. > Ok, so this is turning into a large refactoring. I'll put it up for review first, even though the testsuite looks ok (locally, so it means nothing I guess, haha). Rémy
[tomcat] branch master updated: Avoid possible NPE on commit
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new 659b28c Avoid possible NPE on commit
659b28c is described below
commit 659b28c00d94e2a9049e0a8ac1e02bd4d36dd005
Author: remm
AuthorDate: Thu May 9 18:38:59 2019 +0200
Avoid possible NPE on commit
---
java/org/apache/coyote/http11/Http11OutputBuffer.java | 5 -
webapps/docs/changelog.xml| 4
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/java/org/apache/coyote/http11/Http11OutputBuffer.java
b/java/org/apache/coyote/http11/Http11OutputBuffer.java
index aa5ad48..62d5223 100644
--- a/java/org/apache/coyote/http11/Http11OutputBuffer.java
+++ b/java/org/apache/coyote/http11/Http11OutputBuffer.java
@@ -303,7 +303,10 @@ public class Http11OutputBuffer implements
HttpOutputBuffer {
// Sending the response header buffer
headerBuffer.flip();
try {
-socketWrapper.write(isBlocking(), headerBuffer);
+SocketWrapperBase socketWrapper = this.socketWrapper;
+if (socketWrapper != null) {
+socketWrapper.write(isBlocking(), headerBuffer);
+}
} finally {
headerBuffer.position(0).limit(headerBuffer.capacity());
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index f05b40d..a115137 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -75,6 +75,10 @@
was the only other sensible value, but without and impact beyond
certain microbenchmarks. (remm)
+
+Avoid possible NPE in Http11OutputBuffer.commit on
+connector stopclose. (remm)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Multi threaded accept and polling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rémy and Mark, On 5/9/19 12:32, Rémy Maucherat wrote: > On Thu, May 9, 2019 at 4:47 PM Mark Thomas > wrote: > >> On 09/05/2019 14:38, Rémy Maucherat wrote: >> >> >> +1 to hard-coding to a single acceptor thread and removing the plumbing that supports more than that. >>> >>> Ok, done. >> >> Great. >> >>> So I suppose you prefer keeping the ability to have multiple >>> poller >> threads >>> for NIO ? >> >> NIO defaults to 1 anyway. >> >> I agree with that multiple Poller threads is unlikely to offer a >> performance benefit in any realistic scenario. >> >> APR only supported multiple Poller threads because of a Windows >> XP / Server 2003 issue that limited poller size to 1024. Other >> than that, comments in the APR code indicate a preference for a >> single Poller. >> > > Yes, I ran into that then ... I'm not sure it's okay to drop support for Server 2003 at this point, is it? Or, I guess we are okay if we drop APR support on Server 2003 ; NIO will still work just fine, right? >> I've no objection to making a similar change to the >> pollerThreadCount. > > Ok, so this is turning into a large refactoring. I'll put it up for > review first, even though the testsuite looks ok (locally, so it > means nothing I guess, haha). +1 :) - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzUWNoACgkQHPApP6U8 pFjBcBAAjTiY/fEs/EMzjsd+Q/AtUN6Bs+W86uRZPuK5pRzWNQuKoBVTFNU13bJ7 5dXybkDsQrTf3WfBJr68Pznkezr96cQmQmfN2g67hE/AeygHbd7Hn5pwQGMmJOAt 5bOzTOqaKMYQvif81CUy7S4HCbx4qWXkLmJ7ypfJksvVO7UF/PpdFZKGRlrnkHXb FzFO9W1ruCnsDrxMud94jbpMTyqCJN1DPu5ra/852UEivN3TKDfh1YeHe+lm190Q Uff82ELzAQlhkJ8qkHW9xYszmBZmwydozJw86jtTQ+7c4+0RWKcxiUHWfz/W3rez emy1co6gDJ/PNsz9br6InJHorv6SREBx4TH5F7hPfI6AoYO7nsWKlM5nLsB5P64k aTK2E6sAOw7+mKIDVEzSraqX8E6KomRHyOfMLDZjRyT9nKP5dyQaRcCBOLfYLTqv gqJBp7f+IZloSVsJYALmABF0mi/StUsqEan2Y7RFfgsJx6ZYVDQq+QzwXV8etqfK zMZNPF9L7kUBouF3KAzmi1qlLrmFhBXQ1XGUiUnZAx6BWKmKu3JKLEb+wAe/znb2 kLSuxgb8YY2PfPK4EGYv+QydM1nwWbyLnx6aVICzXTm4WaPSun8OTV8jdu1t44Kx DDEFzP62Ayb3nn9rNlW2TPxXd52MHaWCVCvJk0Jre0ji+ES4TP0= =XCp9 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Multi threaded accept and polling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/9/19 12:49, Mark Thomas wrote: > On 09/05/2019 17:44, Christopher Schultz wrote: >> Rémy and Mark, >> >> On 5/9/19 12:32, Rémy Maucherat wrote: >>> On Thu, May 9, 2019 at 4:47 PM Mark Thomas >>> wrote: >> On 09/05/2019 14:38, Rémy Maucherat wrote: >> +1 to hard-coding to a single acceptor thread and >> removing the plumbing that supports more than that. > > Ok, done. Great. > So I suppose you prefer keeping the ability to have > multiple poller threads > for NIO ? NIO defaults to 1 anyway. I agree with that multiple Poller threads is unlikely to offer a performance benefit in any realistic scenario. APR only supported multiple Poller threads because of a Windows XP / Server 2003 issue that limited poller size to 1024. Other than that, comments in the APR code indicate a preference for a single Poller. >> >>> Yes, I ran into that then ... >> >> I'm not sure it's okay to drop support for Server 2003 at this >> point, is it? > > Extended support for Server 2003 ended on July 14, 2015. That puts > it into the category - in my view - of 'we'll support it while we > can but if there are benefits to us of dropping support we will do > so' > >> Or, I guess we are okay if we drop APR support on Server 2003 ; >> NIO will still work just fine, right? > > Correct. Users on server 2003 could still use NIO. Ack. +1 for removal of multiple poller threads. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzUWvMACgkQHPApP6U8 pFg/vxAAtM9N6jV1NF9/adBzxdcLiJZ4OgYUKI41HDpWLwTnrAtjzO5OByY6Sots k7N8vNGIUVLQgPFQKP4iEzYgjfCGHAOpQ8eHy1Bnv0Y5bXshupU5RVUhiYptVniL eirGjoZbJHXcJ+2pz8vXpcbdysvTtHz2Y7OB3F5oqIC8rU4/idqS8wycFykAgoFQ cp+3U6ZzepcG7kzuTbne4HKCZJpOUPuRlXhVSGyxreqjgELzQhHkUErDOf/csSYm CJtwpC/WGGHY2PrVT5GwgicUfWsGbqdbk3Y4xpEUA6iAFa/NQRlntb0Si44fUn9K OsCfcQ26cjezJsM/3ZhfuuBnd9GztF2oLSPJUrlJTCg78TaeJ5Q92S4667tGsKc/ dtNcgxfbQXcZrnYbZT+2KdL6wyAEciArG9PG0JwWtaEz20k6Pz0aDetaYtUe/epE 7V63Rr8VsposYdrPhu4/bOfJQi5bqde4WBl2aUG+wCIq+nKM4I4rMKDt5vwn8uww KSUfQvJbPnt4uSSXX9v2ALd4GVVkKJ6vWaXYkxf2U3CRe3jyx1snset68NSoD8iF sSdeDTpgk5y4ae4xr0kq2DK2FaspEv0JoBmmubCGie0bUdeQ5GzdrUcLa7GtlRE9 V+laGqhz8whvT1Ks39HIpwZdSbk/iR2OrncwLTtP2CzWaZZrcdQ= =6Nuj -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Multi threaded accept and polling
On 09/05/2019 17:44, Christopher Schultz wrote: > Rémy and Mark, > > On 5/9/19 12:32, Rémy Maucherat wrote: >> On Thu, May 9, 2019 at 4:47 PM Mark Thomas >> wrote: > >>> On 09/05/2019 14:38, Rémy Maucherat wrote: >>> >>> >>> > +1 to hard-coding to a single acceptor thread and removing > the plumbing that supports more than that. Ok, done. >>> >>> Great. >>> So I suppose you prefer keeping the ability to have multiple poller >>> threads for NIO ? >>> >>> NIO defaults to 1 anyway. >>> >>> I agree with that multiple Poller threads is unlikely to offer a >>> performance benefit in any realistic scenario. >>> >>> APR only supported multiple Poller threads because of a Windows >>> XP / Server 2003 issue that limited poller size to 1024. Other >>> than that, comments in the APR code indicate a preference for a >>> single Poller. >>> > >> Yes, I ran into that then ... > > I'm not sure it's okay to drop support for Server 2003 at this point, > is it? Extended support for Server 2003 ended on July 14, 2015. That puts it into the category - in my view - of 'we'll support it while we can but if there are benefits to us of dropping support we will do so' > Or, I guess we are okay if we drop APR support on Server 2003 ; > NIO will still work just fine, right? Correct. Users on server 2003 could still use NIO. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Punishing bad clients with delays
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
What are the options we might have to "punish" an HTTP client that we
don't like for some reason?
Specifically, I'd like to be able to write a servlet that ties-up the
response to the client for a while for some bad behavior. For example,
maybe lots of authentication attempts or some other criteria. Maybe
even just a single bad authentication attempt.
I'm thinking of something along these lines:
public void doGet(...) {
...
if(shouldPunishClient(...)) {
request.setAttribute("delay-client", Boolean.TRUE);
return;
}
...
}
Or maybe even specify a time-out.
Then, Tomcat observes that the servlet or filter wants to put the
response into the penalty box and, instead of flushing the response
and (possibly) closing the connection, it just sits-around for a
while, keeping the connection open.
The poller usually waits for data to become available on either end of
the connection and pushes the bytes. How complicated would it be to
put connections into a queue where they wait some amount of time
before being flushed/closed/returned to the connection pool? In this
case, the only stimulus for taking action is the passage of time, not
arrival of data on a stream.
Any thoughts about how this could be done?
Clearly, a simple Thread.sleep() would do the trick in terms of just
making the client wait, but the point would be to make the client wait
without a performance impact on the server.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzUWrkACgkQHPApP6U8
pFg1rg/9Fe3hI2bup1VCz9MqM+ObSWQjXLJnaIsBfeZUX5p/QTz44A6sbvuwh392
tDlLMUXFUpNFuThVBT059Ypiwi8X80BCuQ313GQ4XP+AVEGrWig1cQ1MHekm2jGX
LUaREGPAG60KJXrcf8oeg+k+aXijQfwpEIjMBs1ssQT+9wKB8PZ5s8sVdxyFjZaQ
Gs54IjLVCfQBCKczOPqfPFyxtSjZX9xZsDk1dw3D912UXtYEph9oW6+8lFz9/vap
WnFn2WTPoGvwx7xMH+F+51CjGtfBTa7NEWmVWjpUzmmByMLhGAF/+1HrKtcxMbtt
xC5RDmSGbSmXlwDFHTOpGHtETUfJb/FpoBXD4S7S9vU9M/ltCsmaWprmg22d/nWu
dmWsg3V5CVMreP24b6bR2NuMkJ6qyZn1htFxm7maTEnASozNo8C7udVjj8iH9NY0
Rr51U1z7Dy8tl10Wp7wL0jvdK3uXl1qJki3rfsGHTOuBw2DP5apb9t7NaUYGAAX6
8BUNOnze1kJpB70Np6+an+i1Shps5et7yoPG26PShC2FzFYfLLmv5OcJFlmXq3zy
Y9h9V0UI34+LCc+Efzw63PP2FqINCMXOGrHpQHxFkQ3iVm2gM8Vt6mQcuHw8aXio
S6+0wA0tU8s0d4X6bWmHX1S0JA7CMX4oaeMRlrw0TRSdnC1uFiY=
=/xXV
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Multi threaded accept and polling
On Thu, May 9, 2019 at 6:44 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Rémy and Mark, > > On 5/9/19 12:32, Rémy Maucherat wrote: > > On Thu, May 9, 2019 at 4:47 PM Mark Thomas > > wrote: > > > >> On 09/05/2019 14:38, Rémy Maucherat wrote: > >> > >> > >> > +1 to hard-coding to a single acceptor thread and removing > the plumbing that supports more than that. > >>> > >>> Ok, done. > >> > >> Great. > >> > >>> So I suppose you prefer keeping the ability to have multiple > >>> poller > >> threads > >>> for NIO ? > >> > >> NIO defaults to 1 anyway. > >> > >> I agree with that multiple Poller threads is unlikely to offer a > >> performance benefit in any realistic scenario. > >> > >> APR only supported multiple Poller threads because of a Windows > >> XP / Server 2003 issue that limited poller size to 1024. Other > >> than that, comments in the APR code indicate a preference for a > >> single Poller. > >> > > > > Yes, I ran into that then ... > > I'm not sure it's okay to drop support for Server 2003 at this point, > is it? Or, I guess we are okay if we drop APR support on Server 2003 ; > NIO will still work just fine, right? > Since it's 100% independent and given the uncertain future of the APR connector, I don't plan to make any changes to APR. > > >> I've no objection to making a similar change to the > >> pollerThreadCount. > > > > Ok, so this is turning into a large refactoring. I'll put it up for > > review first, even though the testsuite looks ok (locally, so it > > means nothing I guess, haha). > > +1 :) > Rémy > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzUWNoACgkQHPApP6U8 > pFjBcBAAjTiY/fEs/EMzjsd+Q/AtUN6Bs+W86uRZPuK5pRzWNQuKoBVTFNU13bJ7 > 5dXybkDsQrTf3WfBJr68Pznkezr96cQmQmfN2g67hE/AeygHbd7Hn5pwQGMmJOAt > 5bOzTOqaKMYQvif81CUy7S4HCbx4qWXkLmJ7ypfJksvVO7UF/PpdFZKGRlrnkHXb > FzFO9W1ruCnsDrxMud94jbpMTyqCJN1DPu5ra/852UEivN3TKDfh1YeHe+lm190Q > Uff82ELzAQlhkJ8qkHW9xYszmBZmwydozJw86jtTQ+7c4+0RWKcxiUHWfz/W3rez > emy1co6gDJ/PNsz9br6InJHorv6SREBx4TH5F7hPfI6AoYO7nsWKlM5nLsB5P64k > aTK2E6sAOw7+mKIDVEzSraqX8E6KomRHyOfMLDZjRyT9nKP5dyQaRcCBOLfYLTqv > gqJBp7f+IZloSVsJYALmABF0mi/StUsqEan2Y7RFfgsJx6ZYVDQq+QzwXV8etqfK > zMZNPF9L7kUBouF3KAzmi1qlLrmFhBXQ1XGUiUnZAx6BWKmKu3JKLEb+wAe/znb2 > kLSuxgb8YY2PfPK4EGYv+QydM1nwWbyLnx6aVICzXTm4WaPSun8OTV8jdu1t44Kx > DDEFzP62Ayb3nn9rNlW2TPxXd52MHaWCVCvJk0Jre0ji+ES4TP0= > =XCp9 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
[GitHub] [tomcat] rmaucher opened a new pull request #163: Remove multiple pollers from NIO
rmaucher opened a new pull request #163: Remove multiple pollers from NIO URL: https://github.com/apache/tomcat/pull/163 NIO2 manages without it, so it should work fine overall. This allows removing a lot of complexity and disconnect between channel <-> wrapper <-> poller, as both now use a known shared poller. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 02/03: Fix Javadoc warning
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit e838da5109fdad1331cb3a6a51c3860b01ee9896
Author: Mark Thomas
AuthorDate: Thu May 9 20:29:35 2019 +0100
Fix Javadoc warning
---
java/org/apache/catalina/servlets/DefaultServlet.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/org/apache/catalina/servlets/DefaultServlet.java
b/java/org/apache/catalina/servlets/DefaultServlet.java
index 97f6b90..b5d2b14 100644
--- a/java/org/apache/catalina/servlets/DefaultServlet.java
+++ b/java/org/apache/catalina/servlets/DefaultServlet.java
@@ -2785,7 +2785,7 @@ public class DefaultServlet extends HttpServlet {
* @param resources The array to sort.
* @param order The ordering string.
*
- * @see {@link #getOrder(String)}
+ * @see #getOrder(String)
*/
public void sort(WebResource[] resources, String order) {
Comparator comparator = getComparator(order);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 01/03: Fix Javadoc warnings
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 97e7bfbbb492a337044adf377a1d1ee9b0f8be2e
Author: Mark Thomas
AuthorDate: Thu May 9 20:28:59 2019 +0100
Fix Javadoc warnings
---
java/org/apache/coyote/AbstractProtocol.java | 15 +++
java/org/apache/tomcat/util/net/AbstractEndpoint.java | 15 +++
2 files changed, 30 insertions(+)
diff --git a/java/org/apache/coyote/AbstractProtocol.java
b/java/org/apache/coyote/AbstractProtocol.java
index 4e35f43..6b93ef4 100644
--- a/java/org/apache/coyote/AbstractProtocol.java
+++ b/java/org/apache/coyote/AbstractProtocol.java
@@ -310,9 +310,24 @@ public abstract class AbstractProtocol implements
ProtocolHandler,
return endpoint.getConnectionCount();
}
+/**
+ * NO-OP.
+ *
+ * @param threadCount Unused
+ *
+ * @Deprecated Will be removed in Tomcat 10.
+ */
@Deprecated
public void setAcceptorThreadCount(int threadCount) {
}
+
+/**
+ * Always returns 1.
+ *
+ * @return Always 1.
+ *
+ * @Deprecated Will be removed in Tomcat 10.
+ */
@Deprecated
public int getAcceptorThreadCount() {
return 1;
diff --git a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
index a33e192..79d137e 100644
--- a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
@@ -406,8 +406,23 @@ public abstract class AbstractEndpoint {
*/
protected int acceptorThreadCount = 1;
+/**
+ * NO-OP.
+ *
+ * @param acceptorThreadCount Unused
+ *
+ * @Deprecated Will be removed in Tomcat 10.
+ */
@Deprecated
public void setAcceptorThreadCount(int acceptorThreadCount) {}
+
+/**
+ * Always returns 1.
+ *
+ * @return Always 1.
+ *
+ * @Deprecated Will be removed in Tomcat 10.
+ */
@Deprecated
public int getAcceptorThreadCount() { return 1; }
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated (659b28c -> cfc165d)
This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/tomcat.git. from 659b28c Avoid possible NPE on commit new 97e7bfb Fix Javadoc warnings new e838da5 Fix Javadoc warning new cfc165d Add @Deprecated to deprecated methods to silence IDE warnings The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: java/org/apache/catalina/servlets/DefaultServlet.java | 5 - java/org/apache/coyote/AbstractProtocol.java | 15 +++ java/org/apache/tomcat/util/net/AbstractEndpoint.java | 15 +++ 3 files changed, 34 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 03/03: Add @Deprecated to deprecated methods to silence IDE warnings
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit cfc165d667e7dda1389396b20d58ee06316340fb
Author: Mark Thomas
AuthorDate: Thu May 9 20:30:23 2019 +0100
Add @Deprecated to deprecated methods to silence IDE warnings
---
java/org/apache/catalina/servlets/DefaultServlet.java | 3 +++
1 file changed, 3 insertions(+)
diff --git a/java/org/apache/catalina/servlets/DefaultServlet.java
b/java/org/apache/catalina/servlets/DefaultServlet.java
index b5d2b14..86956fa 100644
--- a/java/org/apache/catalina/servlets/DefaultServlet.java
+++ b/java/org/apache/catalina/servlets/DefaultServlet.java
@@ -1574,6 +1574,7 @@ public class DefaultServlet extends HttpServlet {
*
* @deprecated Use {@link #render(HttpServletRequest, String, WebResource,
String)} instead
*/
+@Deprecated
protected InputStream render(String contextPath, WebResource resource,
String encoding)
throws IOException, ServletException {
@@ -1620,6 +1621,7 @@ public class DefaultServlet extends HttpServlet {
* @throws ServletException rendering error
* @deprecated Use {@link #render(HttpServletRequest, String, WebResource,
String)} instead
*/
+@Deprecated
protected InputStream renderXml(String contextPath, WebResource resource,
Source xsltSource,
String encoding)
throws ServletException, IOException
@@ -1774,6 +1776,7 @@ public class DefaultServlet extends HttpServlet {
*
* @deprecated Use {@link #renderHtml(HttpServletRequest, String,
WebResource, String)} instead
*/
+@Deprecated
protected InputStream renderHtml(String contextPath, WebResource resource,
String encoding)
throws IOException {
return renderHtml(null, contextPath, resource, encoding);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-trunk/builds/4322 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' triggered this build Build Source Stamp: [branch master] cfc165d667e7dda1389396b20d58ee06316340fb Blamelist: Mark Thomas BUILD FAILED: failed compile Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: Fix javadoc too.
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new df2424e Fix javadoc too.
df2424e is described below
commit df2424e0fa4c5cb7e2987e7b713c404d7c5a88e1
Author: remm
AuthorDate: Thu May 9 21:44:35 2019 +0200
Fix javadoc too.
---
java/org/apache/coyote/AbstractProtocol.java | 4 ++--
java/org/apache/tomcat/util/net/AbstractEndpoint.java | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/java/org/apache/coyote/AbstractProtocol.java
b/java/org/apache/coyote/AbstractProtocol.java
index 6b93ef4..939477b 100644
--- a/java/org/apache/coyote/AbstractProtocol.java
+++ b/java/org/apache/coyote/AbstractProtocol.java
@@ -315,7 +315,7 @@ public abstract class AbstractProtocol implements
ProtocolHandler,
*
* @param threadCount Unused
*
- * @Deprecated Will be removed in Tomcat 10.
+ * @deprecated Will be removed in Tomcat 10.
*/
@Deprecated
public void setAcceptorThreadCount(int threadCount) {
@@ -326,7 +326,7 @@ public abstract class AbstractProtocol implements
ProtocolHandler,
*
* @return Always 1.
*
- * @Deprecated Will be removed in Tomcat 10.
+ * @deprecated Will be removed in Tomcat 10.
*/
@Deprecated
public int getAcceptorThreadCount() {
diff --git a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
index 79d137e..bbe163d 100644
--- a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
@@ -411,7 +411,7 @@ public abstract class AbstractEndpoint {
*
* @param acceptorThreadCount Unused
*
- * @Deprecated Will be removed in Tomcat 10.
+ * @deprecated Will be removed in Tomcat 10.
*/
@Deprecated
public void setAcceptorThreadCount(int acceptorThreadCount) {}
@@ -421,7 +421,7 @@ public abstract class AbstractEndpoint {
*
* @return Always 1.
*
- * @Deprecated Will be removed in Tomcat 10.
+ * @deprecated Will be removed in Tomcat 10.
*/
@Deprecated
public int getAcceptorThreadCount() { return 1; }
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-trunk/builds/4323 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' triggered this build Build Source Stamp: [branch master] df2424e0fa4c5cb7e2987e7b713c404d7c5a88e1 Blamelist: remm Build succeeded! Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Make sure timeout elapses before calling a timeout
On 05/05/2019 09:37, r...@apache.org wrote: > This is an automated email from the ASF dual-hosted git repository. > > remm pushed a commit to branch master > in repository https://gitbox.apache.org/repos/asf/tomcat.git > > > The following commit(s) were added to refs/heads/master by this push: > new 6232d82 Make sure timeout elapses before calling a timeout > 6232d82 is described below > > commit 6232d82cc5db73e5da5392d6ec6d9d01ce65c85e > Author: remm > AuthorDate: Sun May 5 10:37:05 2019 +0200 > > Make sure timeout elapses before calling a timeout > > It seems there are extra stream notify as although 0 bytes have been > allocated only a few ms have passed when there is a failure. I think something else is going on here. I'm still trying to figure it out. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] farnulfo opened a new pull request #164: Create .travis.yml
farnulfo opened a new pull request #164: Create .travis.yml URL: https://github.com/apache/tomcat/pull/164 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] farnulfo closed pull request #164: Create .travis.yml
farnulfo closed pull request #164: Create .travis.yml URL: https://github.com/apache/tomcat/pull/164 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
