[Bug 66354] New: Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted two unwanted two ACLs
https://bz.apache.org/bugzilla/show_bug.cgi?id=66354 Bug ID: 66354 Summary: Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted two unwanted two ACLs Product: Tomcat 9 Version: 9.0.69 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Packaging Assignee: dev@tomcat.apache.org Reporter: nor...@sainet.or.jp Target Milestone: - Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted unwanted two ACLs. Repro at Tomcat9 directory on Admin Command Prompt (not Admin PowerShell). * Used Tomcat 9 zip-x86 distro. * Windows 7 x64. * Tomcat 9.0.69's bin\Tomcat9.exe is Apache Commons Daemon 1.3.2. > ren logs logs1 > md logs > icacls logs logs NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(M) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) BUILTIN\Administrators:(I)(OI)(CI)(F) BUILTIN\Users:(I)(OI)(CI)(M) > bin\tomcat9.exe //US/Tomcat9 > icacls logs logs NT AUTHORITY\LOCAL SERVICE:(RX,W) NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(M) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) BUILTIN\Administrators:(I)(OI)(CI)(F) BUILTIN\Users:(I)(OI)(CI)(M) > bin\tomcat9.exe //US/Tomcat9 > icacls logs logs NT AUTHORITY\LOCAL SERVICE:(RX,W) NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) NT AUTHORITY\LOCAL SERVICE:(RX,W) NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(M) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) BUILTIN\Administrators:(I)(OI)(CI)(F) BUILTIN\Users:(I)(OI)(CI)(M) > for /l %i in (1,0,1) do bin\tomcat9.exe //US/Tomcat9 : (...after 1000-2000 times...) [2022-11-18 17:46:20] [warn] [ 2456] Failed to grant service user 'NT AUTHORITY\LocalService' write permissions to log path '\logs' due to error '1340: The inherited access control list (ACL) or access control entry (ACE) could not be built.' : > icacls logs logs NT AUTHORITY\LOCAL SERVICE:(RX,W) NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) NT AUTHORITY\LOCAL SERVICE:(RX,W) NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) NT AUTHORITY\LOCAL SERVICE:(RX,W) NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) NT AUTHORITY\LOCAL SERVICE:(RX,W) NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) NT AUTHORITY\LOCAL SERVICE:(RX,W) : NT AUTHORITY\LOCAL SERVICE:(RX,W) NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(M) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) BUILTIN\Administrators:(I)(OI)(CI)(F) BUILTIN\Users:(I)(OI)(CI)(M) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66354] Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted two unwanted two ACLs
https://bz.apache.org/bugzilla/show_bug.cgi?id=66354 Norimasa Yamamoto changed: What|Removed |Added OS||Windows 7 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66354] Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted two unwanted two ACLs
https://bz.apache.org/bugzilla/show_bug.cgi?id=66354 Mark Thomas changed: What|Removed |Added OS||All Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Mark Thomas --- Please raise this issue with the Commons Daemon project https://issues.apache.org/jira/projects/DAEMON/issues -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66354] Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted two unwanted two ACLs
https://bz.apache.org/bugzilla/show_bug.cgi?id=66354 --- Comment #2 from Norimasa Yamamoto --- Yes I know, but... how to signup to ASF Jira? > Note that public signup for this Jira instance is disabled. > You must contact private@PROJECT_ID.apache.org mailing list > and provide your preferred username, display name and email address. private@PROJECT_ID.apache.org is invalid to send mail. I mailed to priv...@daemon.apache.org and priv...@commons.apache.org. after then, I got "not exists" from mailer-daemon. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Fix bug with HTTP/2 stream reset and active connection count
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 2362172583 Fix bug with HTTP/2 stream reset and active connection count
2362172583 is described below
commit 2362172583519ca388c9980fda82f8e2c18ec6fb
Author: Mark Thomas
AuthorDate: Fri Nov 18 11:07:17 2022 +
Fix bug with HTTP/2 stream reset and active connection count
When an HTTP/2 stream was reset, the current active stream count was not
reduced. If enough resets occurred on a connection, the current active
stream count limit was reached and no new streams could be created on
that connection.
---
.../coyote/http2/Http2AsyncUpgradeHandler.java | 4 ++
.../apache/coyote/http2/Http2UpgradeHandler.java | 4 ++
test/org/apache/coyote/http2/Http2TestBase.java| 22 +++---
.../coyote/http2/TestHttp2UpgradeHandler.java | 51 ++
webapps/docs/changelog.xml | 6 +++
5 files changed, 81 insertions(+), 6 deletions(-)
diff --git a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
index 9f4af14e24..ce230b7de5 100644
--- a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
@@ -151,7 +151,11 @@ public class Http2AsyncUpgradeHandler extends
Http2UpgradeHandler {
// order.
synchronized (sendResetLock) {
if (state != null) {
+boolean active = state.isActive();
state.sendReset();
+if (active) {
+activeRemoteStreamCount.decrementAndGet();
+}
}
socketWrapper.write(BlockingMode.SEMI_BLOCK,
protocol.getWriteTimeout(),
diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 8ead0b378d..8d402c64b9 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -599,7 +599,11 @@ class Http2UpgradeHandler extends AbstractStream
implements InternalHttpUpgradeH
socketWrapper.getLock().lock();
try {
if (state != null) {
+boolean active = state.isActive();
state.sendReset();
+if (active) {
+activeRemoteStreamCount.decrementAndGet();
+}
}
socketWrapper.write(true, rstFrame, 0, rstFrame.length);
socketWrapper.flush(true);
diff --git a/test/org/apache/coyote/http2/Http2TestBase.java
b/test/org/apache/coyote/http2/Http2TestBase.java
index ba11706257..301450011c 100644
--- a/test/org/apache/coyote/http2/Http2TestBase.java
+++ b/test/org/apache/coyote/http2/Http2TestBase.java
@@ -149,6 +149,11 @@ public abstract class Http2TestBase extends TomcatBaseTest
{
protected void validateHttp2InitialResponse() throws Exception {
+validateHttp2InitialResponse(200);
+}
+
+protected void validateHttp2InitialResponse(long maxConcurrentStreams)
throws Exception {
+
// - 101 response acts as acknowledgement of the HTTP2-Settings header
// Need to read 5 frames
// - settings (server settings - must be first)
@@ -162,7 +167,7 @@ public abstract class Http2TestBase extends TomcatBaseTest {
parser.readFrame();
parser.readFrame();
-Assert.assertEquals("0-Settings-[3]-[200]\n" +
+Assert.assertEquals("0-Settings-[3]-[" + maxConcurrentStreams + "]\n" +
"0-Settings-End\n" +
"0-Settings-Ack\n" +
"0-Ping-[0,0,0,0,0,0,0,1]\n" +
@@ -626,16 +631,21 @@ public abstract class Http2TestBase extends
TomcatBaseTest {
}
protected void enableHttp2(long maxConcurrentStreams, boolean tls) {
+enableHttp2(maxConcurrentStreams, tls, 1, 1, 25000, 5000,
5000);
+}
+
+protected void enableHttp2(long maxConcurrentStreams, boolean tls, long
readTimeout, long writeTimeout,
+long keepAliveTimeout, long streamReadTimout, long
streamWriteTimeout) {
Tomcat tomcat = getTomcatInstance();
Connector connector = tomcat.getConnector();
Assert.assertTrue(connector.setProperty("useAsyncIO",
Boolean.toString(useAsyncIO)));
http2Protocol = new UpgradableHttp2Protocol();
// Short timeouts for now. May need to increase these for CI systems.
-http2Protocol.setReadTimeout(1);
-http2Protocol.setWriteTimeout(1);
-http2Protocol.setKeepAliveTimeout(25000);
-http2Protocol.setStreamReadTimeout(5000);
-http2Protocol.setStreamWriteTimeout(5000);
+http2Protocol.setReadTimeout(readTimeout);
+http2Protocol.
[tomcat] branch 10.1.x updated: Fix bug with HTTP/2 stream reset and active connection count
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.1.x by this push:
new 700d7d96d3 Fix bug with HTTP/2 stream reset and active connection count
700d7d96d3 is described below
commit 700d7d96d3eed75a8cb0f345cad1c43a41019a1f
Author: Mark Thomas
AuthorDate: Fri Nov 18 11:07:17 2022 +
Fix bug with HTTP/2 stream reset and active connection count
When an HTTP/2 stream was reset, the current active stream count was not
reduced. If enough resets occurred on a connection, the current active
stream count limit was reached and no new streams could be created on
that connection.
---
.../coyote/http2/Http2AsyncUpgradeHandler.java | 4 ++
.../apache/coyote/http2/Http2UpgradeHandler.java | 4 ++
test/org/apache/coyote/http2/Http2TestBase.java| 22 +++---
.../coyote/http2/TestHttp2UpgradeHandler.java | 51 ++
webapps/docs/changelog.xml | 10 +
5 files changed, 85 insertions(+), 6 deletions(-)
diff --git a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
index 9f4af14e24..ce230b7de5 100644
--- a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
@@ -151,7 +151,11 @@ public class Http2AsyncUpgradeHandler extends
Http2UpgradeHandler {
// order.
synchronized (sendResetLock) {
if (state != null) {
+boolean active = state.isActive();
state.sendReset();
+if (active) {
+activeRemoteStreamCount.decrementAndGet();
+}
}
socketWrapper.write(BlockingMode.SEMI_BLOCK,
protocol.getWriteTimeout(),
diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 8ead0b378d..8d402c64b9 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -599,7 +599,11 @@ class Http2UpgradeHandler extends AbstractStream
implements InternalHttpUpgradeH
socketWrapper.getLock().lock();
try {
if (state != null) {
+boolean active = state.isActive();
state.sendReset();
+if (active) {
+activeRemoteStreamCount.decrementAndGet();
+}
}
socketWrapper.write(true, rstFrame, 0, rstFrame.length);
socketWrapper.flush(true);
diff --git a/test/org/apache/coyote/http2/Http2TestBase.java
b/test/org/apache/coyote/http2/Http2TestBase.java
index ba11706257..301450011c 100644
--- a/test/org/apache/coyote/http2/Http2TestBase.java
+++ b/test/org/apache/coyote/http2/Http2TestBase.java
@@ -149,6 +149,11 @@ public abstract class Http2TestBase extends TomcatBaseTest
{
protected void validateHttp2InitialResponse() throws Exception {
+validateHttp2InitialResponse(200);
+}
+
+protected void validateHttp2InitialResponse(long maxConcurrentStreams)
throws Exception {
+
// - 101 response acts as acknowledgement of the HTTP2-Settings header
// Need to read 5 frames
// - settings (server settings - must be first)
@@ -162,7 +167,7 @@ public abstract class Http2TestBase extends TomcatBaseTest {
parser.readFrame();
parser.readFrame();
-Assert.assertEquals("0-Settings-[3]-[200]\n" +
+Assert.assertEquals("0-Settings-[3]-[" + maxConcurrentStreams + "]\n" +
"0-Settings-End\n" +
"0-Settings-Ack\n" +
"0-Ping-[0,0,0,0,0,0,0,1]\n" +
@@ -626,16 +631,21 @@ public abstract class Http2TestBase extends
TomcatBaseTest {
}
protected void enableHttp2(long maxConcurrentStreams, boolean tls) {
+enableHttp2(maxConcurrentStreams, tls, 1, 1, 25000, 5000,
5000);
+}
+
+protected void enableHttp2(long maxConcurrentStreams, boolean tls, long
readTimeout, long writeTimeout,
+long keepAliveTimeout, long streamReadTimout, long
streamWriteTimeout) {
Tomcat tomcat = getTomcatInstance();
Connector connector = tomcat.getConnector();
Assert.assertTrue(connector.setProperty("useAsyncIO",
Boolean.toString(useAsyncIO)));
http2Protocol = new UpgradableHttp2Protocol();
// Short timeouts for now. May need to increase these for CI systems.
-http2Protocol.setReadTimeout(1);
-http2Protocol.setWriteTimeout(1);
-http2Protocol.setKeepAliveTimeout(25000);
-http2Protocol.setStreamReadTimeout(5000);
-http2Protocol.setStreamWriteTimeout(5000);
+http2Protocol.setReadTimeout(readTimeout);
+http2Pro
[tomcat] branch 9.0.x updated: Fix bug with HTTP/2 stream reset and active connection count
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new 97bfdd74aa Fix bug with HTTP/2 stream reset and active connection count
97bfdd74aa is described below
commit 97bfdd74aadbdd6eb9941b9e74b5a14777932377
Author: Mark Thomas
AuthorDate: Fri Nov 18 11:07:17 2022 +
Fix bug with HTTP/2 stream reset and active connection count
When an HTTP/2 stream was reset, the current active stream count was not
reduced. If enough resets occurred on a connection, the current active
stream count limit was reached and no new streams could be created on
that connection.
---
.../coyote/http2/Http2AsyncUpgradeHandler.java | 4 ++
.../apache/coyote/http2/Http2UpgradeHandler.java | 4 ++
test/org/apache/coyote/http2/Http2TestBase.java| 22 +++---
.../coyote/http2/TestHttp2UpgradeHandler.java | 51 ++
webapps/docs/changelog.xml | 10 +
5 files changed, 85 insertions(+), 6 deletions(-)
diff --git a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
index 817402b606..69d2501158 100644
--- a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
@@ -151,7 +151,11 @@ public class Http2AsyncUpgradeHandler extends
Http2UpgradeHandler {
// order.
synchronized (sendResetLock) {
if (state != null) {
+boolean active = state.isActive();
state.sendReset();
+if (active) {
+activeRemoteStreamCount.decrementAndGet();
+}
}
socketWrapper.write(BlockingMode.SEMI_BLOCK,
protocol.getWriteTimeout(),
diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index a3c0c54b15..646b825f19 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -593,7 +593,11 @@ class Http2UpgradeHandler extends AbstractStream
implements InternalHttpUpgradeH
// order.
synchronized (socketWrapper) {
if (state != null) {
+boolean active = state.isActive();
state.sendReset();
+if (active) {
+activeRemoteStreamCount.decrementAndGet();
+}
}
socketWrapper.write(true, rstFrame, 0, rstFrame.length);
socketWrapper.flush(true);
diff --git a/test/org/apache/coyote/http2/Http2TestBase.java
b/test/org/apache/coyote/http2/Http2TestBase.java
index 66f178b208..fc3ad89f77 100644
--- a/test/org/apache/coyote/http2/Http2TestBase.java
+++ b/test/org/apache/coyote/http2/Http2TestBase.java
@@ -147,6 +147,11 @@ public abstract class Http2TestBase extends TomcatBaseTest
{
protected void validateHttp2InitialResponse() throws Exception {
+validateHttp2InitialResponse(200);
+}
+
+protected void validateHttp2InitialResponse(long maxConcurrentStreams)
throws Exception {
+
// - 101 response acts as acknowledgement of the HTTP2-Settings header
// Need to read 5 frames
// - settings (server settings - must be first)
@@ -160,7 +165,7 @@ public abstract class Http2TestBase extends TomcatBaseTest {
parser.readFrame();
parser.readFrame();
-Assert.assertEquals("0-Settings-[3]-[200]\n" +
+Assert.assertEquals("0-Settings-[3]-[" + maxConcurrentStreams + "]\n" +
"0-Settings-End\n" +
"0-Settings-Ack\n" +
"0-Ping-[0,0,0,0,0,0,0,1]\n" +
@@ -596,16 +601,21 @@ public abstract class Http2TestBase extends
TomcatBaseTest {
}
protected void enableHttp2(long maxConcurrentStreams, boolean tls) {
+enableHttp2(maxConcurrentStreams, tls, 1, 1, 25000, 5000,
5000);
+}
+
+protected void enableHttp2(long maxConcurrentStreams, boolean tls, long
readTimeout, long writeTimeout,
+long keepAliveTimeout, long streamReadTimout, long
streamWriteTimeout) {
Tomcat tomcat = getTomcatInstance();
Connector connector = tomcat.getConnector();
Assert.assertTrue(connector.setProperty("useAsyncIO",
Boolean.toString(useAsyncIO)));
http2Protocol = new UpgradableHttp2Protocol();
// Short timeouts for now. May need to increase these for CI systems.
-http2Protocol.setReadTimeout(1);
-http2Protocol.setWriteTimeout(1);
-http2Protocol.setKeepAliveTimeout(25000);
-http2Protocol.setStreamReadTimeout(5000);
-http2Protocol.setStreamWriteTimeout(5000);
+http2Protocol.setReadTimeout(readTimeout);
+http2Pr
[tomcat] branch 8.5.x updated: Fix bug with HTTP/2 stream reset and active connection count
This is an automated email from the ASF dual-hosted git repository.
markt 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 75995d581e Fix bug with HTTP/2 stream reset and active connection count
75995d581e is described below
commit 75995d581e8b829174e7d9fb7fa4c22ebba1c6e8
Author: Mark Thomas
AuthorDate: Fri Nov 18 11:07:17 2022 +
Fix bug with HTTP/2 stream reset and active connection count
When an HTTP/2 stream was reset, the current active stream count was not
reduced. If enough resets occurred on a connection, the current active
stream count limit was reached and no new streams could be created on
that connection.
---
.../apache/coyote/http2/Http2UpgradeHandler.java | 4 ++
test/org/apache/coyote/http2/Http2TestBase.java| 22 +++---
.../coyote/http2/TestHttp2UpgradeHandler.java | 51 ++
webapps/docs/changelog.xml | 10 +
4 files changed, 81 insertions(+), 6 deletions(-)
diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index ce4bbc8ec8..ac858ba5be 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -588,7 +588,11 @@ class Http2UpgradeHandler extends AbstractStream
implements InternalHttpUpgradeH
// order.
synchronized (socketWrapper) {
if (state != null) {
+boolean active = state.isActive();
state.sendReset();
+if (active) {
+activeRemoteStreamCount.decrementAndGet();
+}
}
socketWrapper.write(true, rstFrame, 0, rstFrame.length);
socketWrapper.flush(true);
diff --git a/test/org/apache/coyote/http2/Http2TestBase.java
b/test/org/apache/coyote/http2/Http2TestBase.java
index 05b7992b05..e6f60a2f3a 100644
--- a/test/org/apache/coyote/http2/Http2TestBase.java
+++ b/test/org/apache/coyote/http2/Http2TestBase.java
@@ -127,6 +127,11 @@ public abstract class Http2TestBase extends TomcatBaseTest
{
protected void validateHttp2InitialResponse() throws Exception {
+validateHttp2InitialResponse(200);
+}
+
+protected void validateHttp2InitialResponse(long maxConcurrentStreams)
throws Exception {
+
// - 101 response acts as acknowledgement of the HTTP2-Settings header
// Need to read 5 frames
// - settings (server settings - must be first)
@@ -140,7 +145,7 @@ public abstract class Http2TestBase extends TomcatBaseTest {
parser.readFrame();
parser.readFrame();
-Assert.assertEquals("0-Settings-[3]-[200]\n" +
+Assert.assertEquals("0-Settings-[3]-[" + maxConcurrentStreams + "]\n" +
"0-Settings-End\n" +
"0-Settings-Ack\n" +
"0-Ping-[0,0,0,0,0,0,0,1]\n" +
@@ -576,15 +581,20 @@ public abstract class Http2TestBase extends
TomcatBaseTest {
}
protected void enableHttp2(long maxConcurrentStreams, boolean tls) {
+enableHttp2(maxConcurrentStreams, tls, 1, 1, 25000, 5000,
5000);
+}
+
+protected void enableHttp2(long maxConcurrentStreams, boolean tls, long
readTimeout, long writeTimeout,
+long keepAliveTimeout, long streamReadTimout, long
streamWriteTimeout) {
Tomcat tomcat = getTomcatInstance();
Connector connector = tomcat.getConnector();
http2Protocol = new UpgradableHttp2Protocol();
// Short timeouts for now. May need to increase these for CI systems.
-http2Protocol.setReadTimeout(1);
-http2Protocol.setWriteTimeout(1);
-http2Protocol.setKeepAliveTimeout(25000);
-http2Protocol.setStreamReadTimeout(5000);
-http2Protocol.setStreamWriteTimeout(5000);
+http2Protocol.setReadTimeout(readTimeout);
+http2Protocol.setWriteTimeout(writeTimeout);
+http2Protocol.setKeepAliveTimeout(keepAliveTimeout);
+http2Protocol.setStreamReadTimeout(streamReadTimout);
+http2Protocol.setStreamWriteTimeout(streamWriteTimeout);
http2Protocol.setMaxConcurrentStreams(maxConcurrentStreams);
connector.addUpgradeProtocol(http2Protocol);
if (tls) {
diff --git a/test/org/apache/coyote/http2/TestHttp2UpgradeHandler.java
b/test/org/apache/coyote/http2/TestHttp2UpgradeHandler.java
index f96895980a..b4565c7c72 100644
--- a/test/org/apache/coyote/http2/TestHttp2UpgradeHandler.java
+++ b/test/org/apache/coyote/http2/TestHttp2UpgradeHandler.java
@@ -186,4 +186,55 @@ public class TestHttp2UpgradeHandler extends Http2TestBase
{
, output.getTrace());
}
}
+
+
+@Test
+public void testActiveConnectionCountAndClientTimeout() throws Exception {
+
+enableHttp2(2, false, 1000
[Bug 66354] Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted two unwanted two ACLs
https://bz.apache.org/bugzilla/show_bug.cgi?id=66354 --- Comment #3 from Mark Thomas --- (In reply to Norimasa Yamamoto from comment #2) > Yes I know, but... how to signup to ASF Jira? > > > Note that public signup for this Jira instance is disabled. > > You must contact private@PROJECT_ID.apache.org mailing list > > and provide your preferred username, display name and email address. > > private@PROJECT_ID.apache.org is invalid to send mail. > I mailed to priv...@daemon.apache.org and priv...@commons.apache.org. > after then, I got "not exists" from mailer-daemon. I'll set you up with an account. Can I use you email as user name or do you prefer something else? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66354] Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted two unwanted two ACLs
https://bz.apache.org/bugzilla/show_bug.cgi?id=66354 --- Comment #4 from Norimasa Yamamoto --- (In reply to Mark Thomas from comment #3) > I'll set you up with an account. > Can I use you email as user name or do you prefer something else? Thank you! Please use my email as user name. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66354] Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted two unwanted two ACLs
https://bz.apache.org/bugzilla/show_bug.cgi?id=66354 --- Comment #5 from Mark Thomas --- (In reply to Norimasa Yamamoto from comment #4) > (In reply to Mark Thomas from comment #3) > > I'll set you up with an account. > > Can I use you email as user name or do you prefer something else? > > Thank you! > Please use my email as user name. Sorry - just found out I can't do that. I had to use "norimy". You should have received an email. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat doesn't gracefully close keep-alive connections
On 17/11/2022 19:39, M. Thiim wrote: Hi, We have observed that Tomcat doesn't gracefully close keep-alive connections. Tomcat waits for already started requests to complete, but once those are done, Tomcat will close all connections immediately, irrespective of any configured keepAliveTimeout. This causes problems for some HTTP clients, especially in Kubernetes-like environments when scaling down pods. Here, it can only work gracefully if the HTTP client who falls victim to an unexpectedly closed connection retries on a fresh connection, and it is not all clients that do this. I would think that an entirely graceful shutdown sequence, in the presence of keep-alive connections, would work like the following: 1) Server receives shutdown request 2) Server immediately stops accepting new connections (already happens) 3) Server completes all requests already in (already happens) 4) New behavior: If new requests come in on already established keep-alive connections those are processed, but a "Connection: close" is returned so the client knows this connection can no longer be used. So at most one more request can be processed on each of those existing connections. 5) New behavior: When all keep-alive connections are gone, shutdown proceeds. If there are still connections left after the keepAliveTimeout has passed, this means no requests can have been received on those during the shutdown period (otherwise they would have been closed in #4). And since Tomcat returned the keep-alive timeout value to the client when the connection was setup, the client should know that the connection is no longer usable. Therefore it is from this point safe for Tomcat to close those remaining connections. 6) Rest of server shutdown continues Seems a reasonable addition. It looks like extending the behaviour when gracefulStopAwaitMillis is set on the Service would work. gracefulStopAwaitMillis would need to be greater than or equal to the keep-alive timeout but we can document that as part of the patch. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Refactor context around implicit session
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 8cff3d4a24 Refactor context around implicit session
8cff3d4a24 is described below
commit 8cff3d4a24b541de6893a1fec38b1ad8cc68a598
Author: remm
AuthorDate: Fri Nov 18 14:50:31 2022 +0100
Refactor context around implicit session
Add additional comment on the usefulness to load the segment in another
session (in addition to not keeping a reference).
Tested with visual VM, reloading SSL configs and object counts in the
heap dump after full GCs.
Now waiting for more API changes ;)
---
.../util/net/openssl/panama/OpenSSLContext.java| 27 +++---
.../util/net/openssl/panama/OpenSSLEngine.java | 5 ++--
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
index fa336091a8..579bdec9f2 100644
---
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
+++
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
@@ -24,6 +24,7 @@ import java.lang.foreign.Arena;
import java.lang.foreign.FunctionDescriptor;
import java.lang.foreign.Linker;
import java.lang.foreign.MemorySegment;
+import java.lang.foreign.MemorySession;
import java.lang.foreign.SegmentAllocator;
import java.lang.foreign.ValueLayout;
import java.lang.invoke.MethodHandle;
@@ -174,6 +175,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
}
private final ContextState state;
+private final MemorySession contextMemorySession;
private final Cleanable cleanable;
private static String[] getCiphers(MemorySegment sslCtx) {
@@ -205,7 +207,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
this.sslHostConfig = certificate.getSSLHostConfig();
this.certificate = certificate;
-Arena contextMemorySession = Arena.openShared();
+contextMemorySession = MemorySession.implicit();
MemorySegment sslCtx = MemorySegment.NULL;
MemorySegment confCtx = MemorySegment.NULL;
@@ -329,7 +331,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
// Set int pem_password_cb(char *buf, int size, int rwflag, void
*u) callback
openSSLCallbackPassword =
Linker.nativeLinker().upcallStub(openSSLCallbackPasswordHandle,
-openSSLCallbackPasswordFunctionDescriptor,
contextMemorySession.session());
+openSSLCallbackPasswordFunctionDescriptor,
contextMemorySession);
SSL_CTX_set_default_passwd_cb(sslCtx, openSSLCallbackPassword);
alpn = (negotiableProtocols != null && negotiableProtocols.size()
> 0);
@@ -345,7 +347,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
} catch(Exception e) {
throw new SSLException(sm.getString("openssl.errorSSLCtxInit"), e);
} finally {
-state = new ContextState(contextMemorySession, sslCtx, confCtx,
negotiableProtocolsBytes);
+state = new ContextState(sslCtx, confCtx,
negotiableProtocolsBytes);
/*
* When an SSLHostConfig is replaced at runtime, it is not
possible to
* call destroy() on the associated OpenSSLContext since it is
likely
@@ -608,7 +610,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
// Set int verify_callback(int preverify_ok, X509_STORE_CTX
*x509_ctx) callback
var openSSLCallbackVerify =
Linker.nativeLinker().upcallStub(openSSLCallbackVerifyHandle,
-openSSLCallbackVerifyFunctionDescriptor,
state.contextMemorySession.session());
+openSSLCallbackVerifyFunctionDescriptor,
contextMemorySession);
// Leave this just in case but in Tomcat this is always set again
by the engine
SSL_CTX_set_verify(state.sslCtx, value, openSSLCallbackVerify);
@@ -618,7 +620,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
state.x509TrustManager = chooseTrustManager(tms);
var openSSLCallbackCertVerify =
Linker.nativeLinker().upcallStub(openSSLCallbackCertVerifyHandle,
-openSSLCallbackCertVerifyFunctionDescriptor,
state.contextMemorySession.session());
+openSSLCallbackCertVerifyFunctionDescriptor,
contextMemorySession);
SSL
[Bug 66354] Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted two unwanted two ACLs
https://bz.apache.org/bugzilla/show_bug.cgi?id=66354 --- Comment #6 from Norimasa Yamamoto --- Thank you for supporting. I‘ve copied this issue to ASF Jira (Commons Daemon proj.). https://issues.apache.org/jira/browse/DAEMON-450 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.84
On Thu, Nov 17, 2022 at 10:52 AM Mark Thomas wrote: > > On 17/11/2022 08:23, Han Li wrote: > > > > > >> 2022年11月17日 16:08，Mark Thomas 写道： > >> > >> On 17/11/2022 04:04, Han Li wrote: > >>> I think that I encounter a problem, shown below: > >>> org.apache.jasper.JasperException: Unable to compile class for JSP: > >>> An error occurred at line: [17] in the jsp file: [/jsp/include/foo.jsp] > >>> System cannot be resolved > >>> 14: See the License for the specific language governing permissions and > >>> 15: limitations under the License. > >>> 16: > >>> 17: --%><%= System.currentTimeMillis() %> > >>> Stacktrace: > >>> > >>> org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:102) > >>> > >>> org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:213) > >>> > >>> org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:589) > >>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:380) > >>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:350) > >>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) > >>> > >>> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:597) > >>> > >>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:398) > >>> > >>> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:383) > >>> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:331) > >>> javax.servlet.http.HttpServlet.service(HttpServlet.java:765) > >>> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > >>> > >>> org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilter(HttpHeaderSecurityFilter.java:126) > >>> > >>> org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109) > >>> Ant test show passes, but there are problems. (I downloaded 8.5.83 from > >>> the official website, then accessed example webapp > >>> and also have this problem). I don’t know JDT, but I tested again by > >>> upgrading ecj version to 4.25 and this > >>> problem was solved. > >> > >> I can't repeat this. > >> > >> I downloaded the 8.5.84 RC and then tested with Oracle JDK 1.7.0_80. The > >> JSP include example worked. > >> > >> I then cleared out the work directory, switched to Temurin JDK 11.0.17_08 > >> and tested the JSP include example. That worked too. > >> > >> I made no changes to the Eclipse compiler JAR. > >> > >> Can you provide the exact steps to recreate the issue from a clean 8.5.84 > >> download? > > > > There are no exact steps, just need to simply access this url: > > http://localhost:8080/examples/jsp/include/foo.jsp > > The Java version was the key. > > Eclispe JDT 4.6.3 can't compile JSPs under Java 17 as it can't read the > Java 17 class files. > > We can't update JDT as that is the latest version that works with Java 7 > and Tomcat 8.x has a (specification mandated) minimum Java version of 7. > > Updating the JDT locally, as you found, is the way to work around this > problem. Maybe we should add some conditional classloader construction hacks to better support this ? The problem will likely become more and more visible in the future (Tomcat 9 could be hit when/if JDT drops support for Java 8). Bootstrap.createClassLoader would be a spot to do it. Possible use cases: - Add a different JDT if on Java 7 for Tomcat 8.5, use the more up to date if on another one - Add Panama Java 17 JAR if on Java 17 - Add Panama Java 20 JAR if on Java 20 Rémy > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat doesn't gracefully close keep-alive connections
Hi Mark Great! I've actually made an experimental patch that fixes it, but it's perhaps not completely clean. To get the behavior the waiting needs to happen after the server has stopped accepting new connections, this seems to be the pause-phase. But the Http11Processoer rejects incoming requests during the pause phase (condition check in the while loop in the service() method and also further down in the method), so I had to change this behaviour as well (so it accepts requests but responds to them with Connection: Close). I don't know if this breaks some assumptions that it now continues to process requests in the pause phase. I also had to add a .waitForConnectionDrain() to the Connector class and to the protocol handler. Also, in order to avoid waiting for the full duration of the keepAliveTimeout in the cases when there's either no kept alive connections to begin with or where the server is able to close them earlier (due to new requests coming in that can be responded with Connection: Close, as would typically be the case in a busy system) I had to have a count on current number of connections. The getConnectionCount() in AbstractEndpoint.java seemed useful but there's catch: Its counting is based on the value of the connectionLimitLatch and this is specifically nulled out during the pause phase (I suppose because it also has the function of limiting connections), so the getConnectionCount() method returns -1 even if there are open connections. So I added a separate AtomicInteger that tracks the number of connections independently of the state and then changed getConnectionCount() to use this in the situations where the connectionLimitLatch is null. I can clean up and share the patch, but let me know if you think it should be done differently than described above. :-) Br, M. Thiim Den fre. 18. nov. 2022 kl. 14.34 skrev Mark Thomas : > On 17/11/2022 19:39, M. Thiim wrote: > > Hi, > > > > We have observed that Tomcat doesn't gracefully close > > keep-alive connections. Tomcat waits for already started requests to > > complete, but once those are done, Tomcat will close all connections > > immediately, irrespective of any configured keepAliveTimeout. This causes > > problems for some HTTP clients, especially in Kubernetes-like > environments > > when scaling down pods. Here, it can only work gracefully if the HTTP > > client who falls victim to an unexpectedly closed connection retries on a > > fresh connection, and it is not all clients that do this. > > > > I would think that an entirely graceful shutdown sequence, in the > presence > > of keep-alive connections, would work like the following: > > > > 1) Server receives shutdown request > > 2) Server immediately stops accepting new connections (already happens) > > 3) Server completes all requests already in (already happens) > > 4) New behavior: If new requests come in on already established > keep-alive > > connections those are processed, but a "Connection: close" is returned so > > the client knows this connection can no longer be used. So at most one > more > > request can be processed on each of those existing connections. > > 5) New behavior: When all keep-alive connections are gone, shutdown > > proceeds. If there are still connections left after the keepAliveTimeout > > has passed, this means no requests can have been received on those during > > the shutdown period (otherwise they would have been closed in #4). And > > since Tomcat returned the keep-alive timeout value to the client when the > > connection was setup, the client should know that the connection is no > > longer usable. Therefore it is from this point safe for Tomcat to close > > those remaining connections. > > 6) Rest of server shutdown continues > > Seems a reasonable addition. > > It looks like extending the behaviour when gracefulStopAwaitMillis is > set on the Service would work. > > gracefulStopAwaitMillis would need to be greater than or equal to the > keep-alive timeout but we can document that as part of the patch. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Release Apache Tomcat 8.5.84
On 16/11/2022 16:03, Christopher Schultz wrote: The proposed 8.5.84 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 8.5.84 (stable) Unit tests pass on Linux, MacOS and Windows. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat doesn't gracefully close keep-alive connections
PRs are always welcome. From the description provided, I think more use of the existing graceful shutdown could be made. I am also looking at whether a slightly broader refactoring is called for as there looks to be scope for better alignment between pause, stop and graceful stop. Mark On 18/11/2022 14:29, M. Thiim wrote: Hi Mark Great! I've actually made an experimental patch that fixes it, but it's perhaps not completely clean. To get the behavior the waiting needs to happen after the server has stopped accepting new connections, this seems to be the pause-phase. But the Http11Processoer rejects incoming requests during the pause phase (condition check in the while loop in the service() method and also further down in the method), so I had to change this behaviour as well (so it accepts requests but responds to them with Connection: Close). I don't know if this breaks some assumptions that it now continues to process requests in the pause phase. I also had to add a .waitForConnectionDrain() to the Connector class and to the protocol handler. Also, in order to avoid waiting for the full duration of the keepAliveTimeout in the cases when there's either no kept alive connections to begin with or where the server is able to close them earlier (due to new requests coming in that can be responded with Connection: Close, as would typically be the case in a busy system) I had to have a count on current number of connections. The getConnectionCount() in AbstractEndpoint.java seemed useful but there's catch: Its counting is based on the value of the connectionLimitLatch and this is specifically nulled out during the pause phase (I suppose because it also has the function of limiting connections), so the getConnectionCount() method returns -1 even if there are open connections. So I added a separate AtomicInteger that tracks the number of connections independently of the state and then changed getConnectionCount() to use this in the situations where the connectionLimitLatch is null. I can clean up and share the patch, but let me know if you think it should be done differently than described above. :-) Br, M. Thiim Den fre. 18. nov. 2022 kl. 14.34 skrev Mark Thomas : On 17/11/2022 19:39, M. Thiim wrote: Hi, We have observed that Tomcat doesn't gracefully close keep-alive connections. Tomcat waits for already started requests to complete, but once those are done, Tomcat will close all connections immediately, irrespective of any configured keepAliveTimeout. This causes problems for some HTTP clients, especially in Kubernetes-like environments when scaling down pods. Here, it can only work gracefully if the HTTP client who falls victim to an unexpectedly closed connection retries on a fresh connection, and it is not all clients that do this. I would think that an entirely graceful shutdown sequence, in the presence of keep-alive connections, would work like the following: 1) Server receives shutdown request 2) Server immediately stops accepting new connections (already happens) 3) Server completes all requests already in (already happens) 4) New behavior: If new requests come in on already established keep-alive connections those are processed, but a "Connection: close" is returned so the client knows this connection can no longer be used. So at most one more request can be processed on each of those existing connections. 5) New behavior: When all keep-alive connections are gone, shutdown proceeds. If there are still connections left after the keepAliveTimeout has passed, this means no requests can have been received on those during the shutdown period (otherwise they would have been closed in #4). And since Tomcat returned the keep-alive timeout value to the client when the connection was setup, the client should know that the connection is no longer usable. Therefore it is from this point safe for Tomcat to close those remaining connections. 6) Rest of server shutdown continues Seems a reasonable addition. It looks like extending the behaviour when gracefulStopAwaitMillis is set on the Service would work. gracefulStopAwaitMillis would need to be greater than or equal to the keep-alive timeout but we can document that as part of the patch. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat doesn't gracefully close keep-alive connections
I've just found the comment I missed the first time. This has already been implemented. You need to set the following: Connector bindOnInit="false" Service gracefulStopAwaitMillis="2" This assumes you are using the default keep-alive timeout of 20s. If not, adjust gracefulStopAwaitMillis accordingly. It needs to be at least as long as the keep-alive timeout. Mark On 18/11/2022 14:59, Mark Thomas wrote: PRs are always welcome. From the description provided, I think more use of the existing graceful shutdown could be made. I am also looking at whether a slightly broader refactoring is called for as there looks to be scope for better alignment between pause, stop and graceful stop. Mark On 18/11/2022 14:29, M. Thiim wrote: Hi Mark Great! I've actually made an experimental patch that fixes it, but it's perhaps not completely clean. To get the behavior the waiting needs to happen after the server has stopped accepting new connections, this seems to be the pause-phase. But the Http11Processoer rejects incoming requests during the pause phase (condition check in the while loop in the service() method and also further down in the method), so I had to change this behaviour as well (so it accepts requests but responds to them with Connection: Close). I don't know if this breaks some assumptions that it now continues to process requests in the pause phase. I also had to add a .waitForConnectionDrain() to the Connector class and to the protocol handler. Also, in order to avoid waiting for the full duration of the keepAliveTimeout in the cases when there's either no kept alive connections to begin with or where the server is able to close them earlier (due to new requests coming in that can be responded with Connection: Close, as would typically be the case in a busy system) I had to have a count on current number of connections. The getConnectionCount() in AbstractEndpoint.java seemed useful but there's catch: Its counting is based on the value of the connectionLimitLatch and this is specifically nulled out during the pause phase (I suppose because it also has the function of limiting connections), so the getConnectionCount() method returns -1 even if there are open connections. So I added a separate AtomicInteger that tracks the number of connections independently of the state and then changed getConnectionCount() to use this in the situations where the connectionLimitLatch is null. I can clean up and share the patch, but let me know if you think it should be done differently than described above. :-) Br, M. Thiim Den fre. 18. nov. 2022 kl. 14.34 skrev Mark Thomas : On 17/11/2022 19:39, M. Thiim wrote: Hi, We have observed that Tomcat doesn't gracefully close keep-alive connections. Tomcat waits for already started requests to complete, but once those are done, Tomcat will close all connections immediately, irrespective of any configured keepAliveTimeout. This causes problems for some HTTP clients, especially in Kubernetes-like environments when scaling down pods. Here, it can only work gracefully if the HTTP client who falls victim to an unexpectedly closed connection retries on a fresh connection, and it is not all clients that do this. I would think that an entirely graceful shutdown sequence, in the presence of keep-alive connections, would work like the following: 1) Server receives shutdown request 2) Server immediately stops accepting new connections (already happens) 3) Server completes all requests already in (already happens) 4) New behavior: If new requests come in on already established keep-alive connections those are processed, but a "Connection: close" is returned so the client knows this connection can no longer be used. So at most one more request can be processed on each of those existing connections. 5) New behavior: When all keep-alive connections are gone, shutdown proceeds. If there are still connections left after the keepAliveTimeout has passed, this means no requests can have been received on those during the shutdown period (otherwise they would have been closed in #4). And since Tomcat returned the keep-alive timeout value to the client when the connection was setup, the client should know that the connection is no longer usable. Therefore it is from this point safe for Tomcat to close those remaining connections. 6) Rest of server shutdown continues Seems a reasonable addition. It looks like extending the behaviour when gracefulStopAwaitMillis is set on the Service would work. gracefulStopAwaitMillis would need to be greater than or equal to the keep-alive timeout but we can document that as part of the patch. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr.
[tomcat] branch main updated: Improve the docs for bindOnInit
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new c955e1238a Improve the docs for bindOnInit
c955e1238a is described below
commit c955e1238a75d4d17d9fb70750c375bbb69fa7fa
Author: Mark Thomas
AuthorDate: Fri Nov 18 15:49:55 2022 +
Improve the docs for bindOnInit
---
java/org/apache/coyote/http11/Http11Processor.java | 12 ++--
webapps/docs/config/ajp.xml| 9 +
webapps/docs/config/http.xml | 9 +
webapps/docs/config/service.xml| 6 +++---
4 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/java/org/apache/coyote/http11/Http11Processor.java
b/java/org/apache/coyote/http11/Http11Processor.java
index c27ff911f4..b5f1153520 100644
--- a/java/org/apache/coyote/http11/Http11Processor.java
+++ b/java/org/apache/coyote/http11/Http11Processor.java
@@ -283,11 +283,11 @@ public class Http11Processor extends AbstractProcessor {
// parse headers.
prepareRequestProtocol();
-if (protocol.isPaused()) {
-// 503 - Service unavailable
-response.setStatus(503);
-setErrorState(ErrorState.CLOSE_CLEAN, null);
-} else {
+//if (protocol.isPaused()) {
+//// 503 - Service unavailable
+//response.setStatus(503);
+//setErrorState(ErrorState.CLOSE_CLEAN, null);
+//} else {
keptAlive = true;
// Set this every time in case limit has been changed via
JMX
request.getMimeHeaders().setLimit(protocol.getMaxHeaderCount());
@@ -302,7 +302,7 @@ public class Http11Processor extends AbstractProcessor {
if (!protocol.getDisableUploadTimeout()) {
socketWrapper.setReadTimeout(protocol.getConnectionUploadTimeout());
}
-}
+//}
} catch (IOException e) {
if (log.isDebugEnabled()) {
log.debug(sm.getString("http11processor.header.parse"), e);
diff --git a/webapps/docs/config/ajp.xml b/webapps/docs/config/ajp.xml
index c8b20ab573..0a3a260bf3 100644
--- a/webapps/docs/config/ajp.xml
+++ b/webapps/docs/config/ajp.xml
@@ -386,10 +386,11 @@
- Controls when the socket used by the connector is bound. By default it
- is bound when the connector is initiated and unbound when the connector
is
- destroyed. If set to false, the socket will be bound when
the
- connector is started and unbound when it is stopped.
+ Controls when the socket used by the connector is bound. If set to
+ true it is bound when the connector is initiated and unbound
+ when the connector is destroyed. If set to false, the socket
+ will be bound when the connector is started and unbound when it is
+ stopped. If not specified, the default is true.
diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml
index 306b5e084e..40afbfb8fd 100644
--- a/webapps/docs/config/http.xml
+++ b/webapps/docs/config/http.xml
@@ -351,10 +351,11 @@
- Controls when the socket used by the connector is bound. By default it
- is bound when the connector is initiated and unbound when the connector
is
- destroyed. If set to false, the socket will be bound when
the
- connector is started and unbound when it is stopped.
+ Controls when the socket used by the connector is bound. If set to
+ true it is bound when the connector is initiated and unbound
+ when the connector is destroyed. If set to false, the socket
+ will be bound when the connector is started and unbound when it is
+ stopped. If not specified, the default is true.
diff --git a/webapps/docs/config/service.xml b/webapps/docs/config/service.xml
index 5fd0acda8c..bcca17f1a8 100644
--- a/webapps/docs/config/service.xml
+++ b/webapps/docs/config/service.xml
@@ -85,9 +85,9 @@
The time to wait, in milliseconds, when stopping the Service for the
client connections to finish processing and close before the Service's
container hierarchy is stopped. The wait only applies to Connectors
- configured with a bindOnInit value of false.
- Any value of zero or less means there will be no wait. If not specified,
- the default value of zero will be used.
+ configured with a bindOnInit value of false
+ which is not the default. Any value of zero or less means there will be
no
+ wait. If not specified, the default value of zero will be used.
-
To unsubsc
[tomcat] branch 10.1.x updated: Improve the docs for bindOnInit
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.1.x by this push:
new 841cb9b0d4 Improve the docs for bindOnInit
841cb9b0d4 is described below
commit 841cb9b0d44202d43b4ada3437c1640d5989fc84
Author: Mark Thomas
AuthorDate: Fri Nov 18 15:49:55 2022 +
Improve the docs for bindOnInit
---
java/org/apache/coyote/http11/Http11Processor.java | 12 ++--
webapps/docs/config/ajp.xml| 9 +
webapps/docs/config/http.xml | 9 +
webapps/docs/config/service.xml| 6 +++---
4 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/java/org/apache/coyote/http11/Http11Processor.java
b/java/org/apache/coyote/http11/Http11Processor.java
index c27ff911f4..b5f1153520 100644
--- a/java/org/apache/coyote/http11/Http11Processor.java
+++ b/java/org/apache/coyote/http11/Http11Processor.java
@@ -283,11 +283,11 @@ public class Http11Processor extends AbstractProcessor {
// parse headers.
prepareRequestProtocol();
-if (protocol.isPaused()) {
-// 503 - Service unavailable
-response.setStatus(503);
-setErrorState(ErrorState.CLOSE_CLEAN, null);
-} else {
+//if (protocol.isPaused()) {
+//// 503 - Service unavailable
+//response.setStatus(503);
+//setErrorState(ErrorState.CLOSE_CLEAN, null);
+//} else {
keptAlive = true;
// Set this every time in case limit has been changed via
JMX
request.getMimeHeaders().setLimit(protocol.getMaxHeaderCount());
@@ -302,7 +302,7 @@ public class Http11Processor extends AbstractProcessor {
if (!protocol.getDisableUploadTimeout()) {
socketWrapper.setReadTimeout(protocol.getConnectionUploadTimeout());
}
-}
+//}
} catch (IOException e) {
if (log.isDebugEnabled()) {
log.debug(sm.getString("http11processor.header.parse"), e);
diff --git a/webapps/docs/config/ajp.xml b/webapps/docs/config/ajp.xml
index c8b20ab573..0a3a260bf3 100644
--- a/webapps/docs/config/ajp.xml
+++ b/webapps/docs/config/ajp.xml
@@ -386,10 +386,11 @@
- Controls when the socket used by the connector is bound. By default it
- is bound when the connector is initiated and unbound when the connector
is
- destroyed. If set to false, the socket will be bound when
the
- connector is started and unbound when it is stopped.
+ Controls when the socket used by the connector is bound. If set to
+ true it is bound when the connector is initiated and unbound
+ when the connector is destroyed. If set to false, the socket
+ will be bound when the connector is started and unbound when it is
+ stopped. If not specified, the default is true.
diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml
index cf33dff577..5b9fc6c941 100644
--- a/webapps/docs/config/http.xml
+++ b/webapps/docs/config/http.xml
@@ -351,10 +351,11 @@
- Controls when the socket used by the connector is bound. By default it
- is bound when the connector is initiated and unbound when the connector
is
- destroyed. If set to false, the socket will be bound when
the
- connector is started and unbound when it is stopped.
+ Controls when the socket used by the connector is bound. If set to
+ true it is bound when the connector is initiated and unbound
+ when the connector is destroyed. If set to false, the socket
+ will be bound when the connector is started and unbound when it is
+ stopped. If not specified, the default is true.
diff --git a/webapps/docs/config/service.xml b/webapps/docs/config/service.xml
index 5fd0acda8c..bcca17f1a8 100644
--- a/webapps/docs/config/service.xml
+++ b/webapps/docs/config/service.xml
@@ -85,9 +85,9 @@
The time to wait, in milliseconds, when stopping the Service for the
client connections to finish processing and close before the Service's
container hierarchy is stopped. The wait only applies to Connectors
- configured with a bindOnInit value of false.
- Any value of zero or less means there will be no wait. If not specified,
- the default value of zero will be used.
+ configured with a bindOnInit value of false
+ which is not the default. Any value of zero or less means there will be
no
+ wait. If not specified, the default value of zero will be used.
-
To uns
[tomcat] branch 9.0.x updated: Improve the docs for bindOnInit
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new 2908b4931a Improve the docs for bindOnInit
2908b4931a is described below
commit 2908b4931a9b1e545dde169eddefd3f04800896b
Author: Mark Thomas
AuthorDate: Fri Nov 18 15:49:55 2022 +
Improve the docs for bindOnInit
---
java/org/apache/coyote/http11/Http11Processor.java | 12 ++--
webapps/docs/config/ajp.xml| 9 +
webapps/docs/config/http.xml | 9 +
webapps/docs/config/service.xml| 6 +++---
4 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/java/org/apache/coyote/http11/Http11Processor.java
b/java/org/apache/coyote/http11/Http11Processor.java
index 3ed86daeb2..83fbbf4e7c 100644
--- a/java/org/apache/coyote/http11/Http11Processor.java
+++ b/java/org/apache/coyote/http11/Http11Processor.java
@@ -282,11 +282,11 @@ public class Http11Processor extends AbstractProcessor {
// parse headers.
prepareRequestProtocol();
-if (protocol.isPaused()) {
-// 503 - Service unavailable
-response.setStatus(503);
-setErrorState(ErrorState.CLOSE_CLEAN, null);
-} else {
+//if (protocol.isPaused()) {
+//// 503 - Service unavailable
+//response.setStatus(503);
+//setErrorState(ErrorState.CLOSE_CLEAN, null);
+//} else {
keptAlive = true;
// Set this every time in case limit has been changed via
JMX
request.getMimeHeaders().setLimit(protocol.getMaxHeaderCount());
@@ -301,7 +301,7 @@ public class Http11Processor extends AbstractProcessor {
if (!protocol.getDisableUploadTimeout()) {
socketWrapper.setReadTimeout(protocol.getConnectionUploadTimeout());
}
-}
+//}
} catch (IOException e) {
if (log.isDebugEnabled()) {
log.debug(sm.getString("http11processor.header.parse"), e);
diff --git a/webapps/docs/config/ajp.xml b/webapps/docs/config/ajp.xml
index 505ee56b50..82df320332 100644
--- a/webapps/docs/config/ajp.xml
+++ b/webapps/docs/config/ajp.xml
@@ -380,10 +380,11 @@
- Controls when the socket used by the connector is bound. By default it
- is bound when the connector is initiated and unbound when the connector
is
- destroyed. If set to false, the socket will be bound when
the
- connector is started and unbound when it is stopped.
+ Controls when the socket used by the connector is bound. If set to
+ true it is bound when the connector is initiated and unbound
+ when the connector is destroyed. If set to false, the socket
+ will be bound when the connector is started and unbound when it is
+ stopped. If not specified, the default is true.
diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml
index 019e859796..f9b8468f69 100644
--- a/webapps/docs/config/http.xml
+++ b/webapps/docs/config/http.xml
@@ -353,10 +353,11 @@
- Controls when the socket used by the connector is bound. By default it
- is bound when the connector is initiated and unbound when the connector
is
- destroyed. If set to false, the socket will be bound when
the
- connector is started and unbound when it is stopped.
+ Controls when the socket used by the connector is bound. If set to
+ true it is bound when the connector is initiated and unbound
+ when the connector is destroyed. If set to false, the socket
+ will be bound when the connector is started and unbound when it is
+ stopped. If not specified, the default is true.
diff --git a/webapps/docs/config/service.xml b/webapps/docs/config/service.xml
index 5fd0acda8c..bcca17f1a8 100644
--- a/webapps/docs/config/service.xml
+++ b/webapps/docs/config/service.xml
@@ -85,9 +85,9 @@
The time to wait, in milliseconds, when stopping the Service for the
client connections to finish processing and close before the Service's
container hierarchy is stopped. The wait only applies to Connectors
- configured with a bindOnInit value of false.
- Any value of zero or less means there will be no wait. If not specified,
- the default value of zero will be used.
+ configured with a bindOnInit value of false
+ which is not the default. Any value of zero or less means there will be
no
+ wait. If not specified, the default value of zero will be used.
-
To unsub
[tomcat] branch main updated: Revert accidental commit
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new f8bf4920ba Revert accidental commit
f8bf4920ba is described below
commit f8bf4920ba05f867f5cb2e7eade4a4e8a790f0c7
Author: Mark Thomas
AuthorDate: Fri Nov 18 15:51:43 2022 +
Revert accidental commit
---
java/org/apache/coyote/http11/Http11Processor.java | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/java/org/apache/coyote/http11/Http11Processor.java
b/java/org/apache/coyote/http11/Http11Processor.java
index b5f1153520..c27ff911f4 100644
--- a/java/org/apache/coyote/http11/Http11Processor.java
+++ b/java/org/apache/coyote/http11/Http11Processor.java
@@ -283,11 +283,11 @@ public class Http11Processor extends AbstractProcessor {
// parse headers.
prepareRequestProtocol();
-//if (protocol.isPaused()) {
-//// 503 - Service unavailable
-//response.setStatus(503);
-//setErrorState(ErrorState.CLOSE_CLEAN, null);
-//} else {
+if (protocol.isPaused()) {
+// 503 - Service unavailable
+response.setStatus(503);
+setErrorState(ErrorState.CLOSE_CLEAN, null);
+} else {
keptAlive = true;
// Set this every time in case limit has been changed via
JMX
request.getMimeHeaders().setLimit(protocol.getMaxHeaderCount());
@@ -302,7 +302,7 @@ public class Http11Processor extends AbstractProcessor {
if (!protocol.getDisableUploadTimeout()) {
socketWrapper.setReadTimeout(protocol.getConnectionUploadTimeout());
}
-//}
+}
} catch (IOException e) {
if (log.isDebugEnabled()) {
log.debug(sm.getString("http11processor.header.parse"), e);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 10.1.x updated: Revert accidental commit
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.1.x by this push:
new 32752096ae Revert accidental commit
32752096ae is described below
commit 32752096aed5e9ae4db526e3204964c508f1a306
Author: Mark Thomas
AuthorDate: Fri Nov 18 15:51:43 2022 +
Revert accidental commit
---
java/org/apache/coyote/http11/Http11Processor.java | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/java/org/apache/coyote/http11/Http11Processor.java
b/java/org/apache/coyote/http11/Http11Processor.java
index b5f1153520..c27ff911f4 100644
--- a/java/org/apache/coyote/http11/Http11Processor.java
+++ b/java/org/apache/coyote/http11/Http11Processor.java
@@ -283,11 +283,11 @@ public class Http11Processor extends AbstractProcessor {
// parse headers.
prepareRequestProtocol();
-//if (protocol.isPaused()) {
-//// 503 - Service unavailable
-//response.setStatus(503);
-//setErrorState(ErrorState.CLOSE_CLEAN, null);
-//} else {
+if (protocol.isPaused()) {
+// 503 - Service unavailable
+response.setStatus(503);
+setErrorState(ErrorState.CLOSE_CLEAN, null);
+} else {
keptAlive = true;
// Set this every time in case limit has been changed via
JMX
request.getMimeHeaders().setLimit(protocol.getMaxHeaderCount());
@@ -302,7 +302,7 @@ public class Http11Processor extends AbstractProcessor {
if (!protocol.getDisableUploadTimeout()) {
socketWrapper.setReadTimeout(protocol.getConnectionUploadTimeout());
}
-//}
+}
} catch (IOException e) {
if (log.isDebugEnabled()) {
log.debug(sm.getString("http11processor.header.parse"), e);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: Revert accidental commit
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new 93d678369e Revert accidental commit
93d678369e is described below
commit 93d678369ee166fd238f628a8e59d0d4ecd2baea
Author: Mark Thomas
AuthorDate: Fri Nov 18 15:51:43 2022 +
Revert accidental commit
---
java/org/apache/coyote/http11/Http11Processor.java | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/java/org/apache/coyote/http11/Http11Processor.java
b/java/org/apache/coyote/http11/Http11Processor.java
index 83fbbf4e7c..3ed86daeb2 100644
--- a/java/org/apache/coyote/http11/Http11Processor.java
+++ b/java/org/apache/coyote/http11/Http11Processor.java
@@ -282,11 +282,11 @@ public class Http11Processor extends AbstractProcessor {
// parse headers.
prepareRequestProtocol();
-//if (protocol.isPaused()) {
-//// 503 - Service unavailable
-//response.setStatus(503);
-//setErrorState(ErrorState.CLOSE_CLEAN, null);
-//} else {
+if (protocol.isPaused()) {
+// 503 - Service unavailable
+response.setStatus(503);
+setErrorState(ErrorState.CLOSE_CLEAN, null);
+} else {
keptAlive = true;
// Set this every time in case limit has been changed via
JMX
request.getMimeHeaders().setLimit(protocol.getMaxHeaderCount());
@@ -301,7 +301,7 @@ public class Http11Processor extends AbstractProcessor {
if (!protocol.getDisableUploadTimeout()) {
socketWrapper.setReadTimeout(protocol.getConnectionUploadTimeout());
}
-//}
+}
} catch (IOException e) {
if (log.isDebugEnabled()) {
log.debug(sm.getString("http11processor.header.parse"), e);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: Improve the docs for bindOnInit
This is an automated email from the ASF dual-hosted git repository. markt 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 3e2142e0b7 Improve the docs for bindOnInit 3e2142e0b7 is described below commit 3e2142e0b79ebc1108c51c07576c8b1aee9b5a24 Author: Mark Thomas AuthorDate: Fri Nov 18 15:49:55 2022 + Improve the docs for bindOnInit --- webapps/docs/config/ajp.xml | 9 + webapps/docs/config/http.xml| 9 + webapps/docs/config/service.xml | 6 +++--- 3 files changed, 13 insertions(+), 11 deletions(-) diff --git a/webapps/docs/config/ajp.xml b/webapps/docs/config/ajp.xml index 12424c548a..6af5c81fad 100644 --- a/webapps/docs/config/ajp.xml +++ b/webapps/docs/config/ajp.xml @@ -371,10 +371,11 @@ - Controls when the socket used by the connector is bound. By default it - is bound when the connector is initiated and unbound when the connector is - destroyed. If set to false, the socket will be bound when the - connector is started and unbound when it is stopped. + Controls when the socket used by the connector is bound. If set to + true it is bound when the connector is initiated and unbound + when the connector is destroyed. If set to false, the socket + will be bound when the connector is started and unbound when it is + stopped. If not specified, the default is true. diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml index ac528d896d..93dc3db61c 100644 --- a/webapps/docs/config/http.xml +++ b/webapps/docs/config/http.xml @@ -352,10 +352,11 @@ - Controls when the socket used by the connector is bound. By default it - is bound when the connector is initiated and unbound when the connector is - destroyed. If set to false, the socket will be bound when the - connector is started and unbound when it is stopped. + Controls when the socket used by the connector is bound. If set to + true it is bound when the connector is initiated and unbound + when the connector is destroyed. If set to false, the socket + will be bound when the connector is started and unbound when it is + stopped. If not specified, the default is true. diff --git a/webapps/docs/config/service.xml b/webapps/docs/config/service.xml index 5fd0acda8c..bcca17f1a8 100644 --- a/webapps/docs/config/service.xml +++ b/webapps/docs/config/service.xml @@ -85,9 +85,9 @@ The time to wait, in milliseconds, when stopping the Service for the client connections to finish processing and close before the Service's container hierarchy is stopped. The wait only applies to Connectors - configured with a bindOnInit value of false. - Any value of zero or less means there will be no wait. If not specified, - the default value of zero will be used. + configured with a bindOnInit value of false + which is not the default. Any value of zero or less means there will be no + wait. If not specified, the default value of zero will be used. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 01/03: Next iteration of the Servlet spec currently planned to be 6.1
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat.git commit 570c2e6aea3d2cb150a543111c7527c1b5be800c Author: Mark Thomas AuthorDate: Fri Nov 18 16:09:02 2022 + Next iteration of the Servlet spec currently planned to be 6.1 --- build.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/build.xml b/build.xml index ba3757240d..92dc34cab8 100644 --- a/build.xml +++ b/build.xml @@ -57,8 +57,8 @@ - - + + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 02/03: Formatting, no functional change.
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 76ec06a960884034267f6af625c7c29b840d8485
Author: Mark Thomas
AuthorDate: Fri Nov 18 16:10:58 2022 +
Formatting, no functional change.
---
.../apache/catalina/core/StandardHostValve.java| 43 +++---
1 file changed, 14 insertions(+), 29 deletions(-)
diff --git a/java/org/apache/catalina/core/StandardHostValve.java
b/java/org/apache/catalina/core/StandardHostValve.java
index 76c4171f34..75ae889a95 100644
--- a/java/org/apache/catalina/core/StandardHostValve.java
+++ b/java/org/apache/catalina/core/StandardHostValve.java
@@ -209,27 +209,22 @@ final class StandardHostValve extends ValveBase {
}
if (errorPage != null && response.isErrorReportRequired()) {
response.setAppCommitted(false);
-request.setAttribute(RequestDispatcher.ERROR_STATUS_CODE,
- Integer.valueOf(statusCode));
+request.setAttribute(RequestDispatcher.ERROR_STATUS_CODE,
Integer.valueOf(statusCode));
String message = response.getMessage();
if (message == null) {
message = "";
}
request.setAttribute(RequestDispatcher.ERROR_MESSAGE, message);
-request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
-errorPage.getLocation());
-request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
-DispatcherType.ERROR);
+request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
errorPage.getLocation());
+request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
DispatcherType.ERROR);
Wrapper wrapper = request.getWrapper();
if (wrapper != null) {
-request.setAttribute(RequestDispatcher.ERROR_SERVLET_NAME,
- wrapper.getName());
+request.setAttribute(RequestDispatcher.ERROR_SERVLET_NAME,
wrapper.getName());
}
-request.setAttribute(RequestDispatcher.ERROR_REQUEST_URI,
- request.getRequestURI());
+request.setAttribute(RequestDispatcher.ERROR_REQUEST_URI,
request.getRequestURI());
if (custom(request, response, errorPage)) {
response.setErrorReported();
try {
@@ -255,8 +250,7 @@ final class StandardHostValve extends ValveBase {
* @param throwable The exception that occurred (which possibly wraps
* a root cause exception
*/
-protected void throwable(Request request, Response response,
- Throwable throwable) {
+protected void throwable(Request request, Response response, Throwable
throwable) {
Context context = request.getContext();
if (context == null) {
return;
@@ -274,9 +268,7 @@ final class StandardHostValve extends ValveBase {
// If this is an aborted request from a client just log it and return
if (realError instanceof ClientAbortException ) {
if (log.isDebugEnabled()) {
-log.debug
-(sm.getString("standardHost.clientAbort",
-realError.getCause().getMessage()));
+log.debug(sm.getString("standardHost.clientAbort",
realError.getCause().getMessage()));
}
return;
}
@@ -289,25 +281,18 @@ final class StandardHostValve extends ValveBase {
if (errorPage != null) {
if (response.setErrorReported()) {
response.setAppCommitted(false);
-request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
-errorPage.getLocation());
-request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
-DispatcherType.ERROR);
+request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
errorPage.getLocation());
+request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
DispatcherType.ERROR);
request.setAttribute(RequestDispatcher.ERROR_STATUS_CODE,
Integer.valueOf(HttpServletResponse.SC_INTERNAL_SERVER_ERROR));
-request.setAttribute(RequestDispatcher.ERROR_MESSAGE,
- throwable.getMessage());
-request.setAttribute(RequestDispatcher.ERROR_EXCEPTION,
- realError);
+request.setAttribute(RequestDispatcher.ERROR_MESSAGE,
throwable.getMessage());
+request.setAttribute(RequestDispatcher.ERROR_EXCEPTION,
realError);
Wrapper wrapper = request.getWrapper();
if (wrapper != null) {
-request.setAttribute(RequestDispatcher.ERROR_SERVLET_NAME,
- wrapper.
[tomcat] 03/03: Add support for jakarta.servlet.error.query_string on error dispatches
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit c3e7054284aafd054e86f9ceccb19c9dd7aac69a
Author: Mark Thomas
AuthorDate: Fri Nov 18 16:15:11 2022 +
Add support for jakarta.servlet.error.query_string on error dispatches
---
java/jakarta/servlet/RequestDispatcher.java | 8
java/org/apache/catalina/core/StandardHostValve.java | 2 ++
webapps/docs/changelog.xml | 4
3 files changed, 14 insertions(+)
diff --git a/java/jakarta/servlet/RequestDispatcher.java
b/java/jakarta/servlet/RequestDispatcher.java
index 0c94b00921..190d3099fb 100644
--- a/java/jakarta/servlet/RequestDispatcher.java
+++ b/java/jakarta/servlet/RequestDispatcher.java
@@ -213,6 +213,14 @@ public interface RequestDispatcher {
*/
public static final String ERROR_REQUEST_URI =
"jakarta.servlet.error.request_uri";
+/**
+ * The name of the request attribute under which the query string for
request whose processing caused the error is
+ * propagated during an error dispatch
+ *
+ * @since Servlet 6.1
+ */
+static final String ERROR_QUERY_STRING =
"jakarta.servlet.error.query_string";
+
/**
* The name of the request attribute that should be set by the container
* when custom error-handling servlet or JSP page is invoked. The value of
diff --git a/java/org/apache/catalina/core/StandardHostValve.java
b/java/org/apache/catalina/core/StandardHostValve.java
index 75ae889a95..8e0c5b283f 100644
--- a/java/org/apache/catalina/core/StandardHostValve.java
+++ b/java/org/apache/catalina/core/StandardHostValve.java
@@ -225,6 +225,7 @@ final class StandardHostValve extends ValveBase {
request.setAttribute(RequestDispatcher.ERROR_SERVLET_NAME,
wrapper.getName());
}
request.setAttribute(RequestDispatcher.ERROR_REQUEST_URI,
request.getRequestURI());
+request.setAttribute(RequestDispatcher.ERROR_QUERY_STRING,
request.getQueryString());
if (custom(request, response, errorPage)) {
response.setErrorReported();
try {
@@ -292,6 +293,7 @@ final class StandardHostValve extends ValveBase {
request.setAttribute(RequestDispatcher.ERROR_SERVLET_NAME,
wrapper.getName());
}
request.setAttribute(RequestDispatcher.ERROR_REQUEST_URI,
request.getRequestURI());
+request.setAttribute(RequestDispatcher.ERROR_QUERY_STRING,
request.getQueryString());
request.setAttribute(RequestDispatcher.ERROR_EXCEPTION_TYPE,
realError.getClass());
if (custom(request, response, errorPage)) {
try {
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 7f4ec93b79..7a64f324c3 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -162,6 +162,10 @@
the Servlet context so that it actually reflects what is used during
authentication. (remm)
+
+Add support for the new attribute for error dispatches
+jakarta.servlet.error.query_string. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated (f8bf4920ba -> c3e7054284)
This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch main in repository https://gitbox.apache.org/repos/asf/tomcat.git from f8bf4920ba Revert accidental commit new 570c2e6aea Next iteration of the Servlet spec currently planned to be 6.1 new 76ec06a960 Formatting, no functional change. new c3e7054284 Add support for jakarta.servlet.error.query_string on error dispatches 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: build.xml | 4 +- java/jakarta/servlet/RequestDispatcher.java| 8 .../apache/catalina/core/StandardHostValve.java| 45 -- webapps/docs/changelog.xml | 4 ++ 4 files changed, 30 insertions(+), 31 deletions(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 10.1.x updated: Formatting, no functional change.
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.1.x by this push:
new 0fb8c17e43 Formatting, no functional change.
0fb8c17e43 is described below
commit 0fb8c17e434091b862134603145e9e441abd895a
Author: Mark Thomas
AuthorDate: Fri Nov 18 16:10:58 2022 +
Formatting, no functional change.
---
.../apache/catalina/core/StandardHostValve.java| 43 +++---
1 file changed, 14 insertions(+), 29 deletions(-)
diff --git a/java/org/apache/catalina/core/StandardHostValve.java
b/java/org/apache/catalina/core/StandardHostValve.java
index 76c4171f34..75ae889a95 100644
--- a/java/org/apache/catalina/core/StandardHostValve.java
+++ b/java/org/apache/catalina/core/StandardHostValve.java
@@ -209,27 +209,22 @@ final class StandardHostValve extends ValveBase {
}
if (errorPage != null && response.isErrorReportRequired()) {
response.setAppCommitted(false);
-request.setAttribute(RequestDispatcher.ERROR_STATUS_CODE,
- Integer.valueOf(statusCode));
+request.setAttribute(RequestDispatcher.ERROR_STATUS_CODE,
Integer.valueOf(statusCode));
String message = response.getMessage();
if (message == null) {
message = "";
}
request.setAttribute(RequestDispatcher.ERROR_MESSAGE, message);
-request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
-errorPage.getLocation());
-request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
-DispatcherType.ERROR);
+request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
errorPage.getLocation());
+request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
DispatcherType.ERROR);
Wrapper wrapper = request.getWrapper();
if (wrapper != null) {
-request.setAttribute(RequestDispatcher.ERROR_SERVLET_NAME,
- wrapper.getName());
+request.setAttribute(RequestDispatcher.ERROR_SERVLET_NAME,
wrapper.getName());
}
-request.setAttribute(RequestDispatcher.ERROR_REQUEST_URI,
- request.getRequestURI());
+request.setAttribute(RequestDispatcher.ERROR_REQUEST_URI,
request.getRequestURI());
if (custom(request, response, errorPage)) {
response.setErrorReported();
try {
@@ -255,8 +250,7 @@ final class StandardHostValve extends ValveBase {
* @param throwable The exception that occurred (which possibly wraps
* a root cause exception
*/
-protected void throwable(Request request, Response response,
- Throwable throwable) {
+protected void throwable(Request request, Response response, Throwable
throwable) {
Context context = request.getContext();
if (context == null) {
return;
@@ -274,9 +268,7 @@ final class StandardHostValve extends ValveBase {
// If this is an aborted request from a client just log it and return
if (realError instanceof ClientAbortException ) {
if (log.isDebugEnabled()) {
-log.debug
-(sm.getString("standardHost.clientAbort",
-realError.getCause().getMessage()));
+log.debug(sm.getString("standardHost.clientAbort",
realError.getCause().getMessage()));
}
return;
}
@@ -289,25 +281,18 @@ final class StandardHostValve extends ValveBase {
if (errorPage != null) {
if (response.setErrorReported()) {
response.setAppCommitted(false);
-request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
-errorPage.getLocation());
-request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
-DispatcherType.ERROR);
+request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
errorPage.getLocation());
+request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
DispatcherType.ERROR);
request.setAttribute(RequestDispatcher.ERROR_STATUS_CODE,
Integer.valueOf(HttpServletResponse.SC_INTERNAL_SERVER_ERROR));
-request.setAttribute(RequestDispatcher.ERROR_MESSAGE,
- throwable.getMessage());
-request.setAttribute(RequestDispatcher.ERROR_EXCEPTION,
- realError);
+request.setAttribute(RequestDispatcher.ERROR_MESSAGE,
throwable.getMessage());
+request.setAttribute(RequestDispatcher.ERROR_EXCEPTION,
realError);
Wrapper wrapper = request.getWrapper();
[tomcat] branch 9.0.x updated: Formatting, no functional change.
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new 3720b3d6cc Formatting, no functional change.
3720b3d6cc is described below
commit 3720b3d6cca6488f9001946ffc8f1ca0e0b508dd
Author: Mark Thomas
AuthorDate: Fri Nov 18 16:10:58 2022 +
Formatting, no functional change.
---
.../apache/catalina/core/StandardHostValve.java| 43 +++---
1 file changed, 14 insertions(+), 29 deletions(-)
diff --git a/java/org/apache/catalina/core/StandardHostValve.java
b/java/org/apache/catalina/core/StandardHostValve.java
index 0383d592b5..9f7ebd13de 100644
--- a/java/org/apache/catalina/core/StandardHostValve.java
+++ b/java/org/apache/catalina/core/StandardHostValve.java
@@ -225,27 +225,22 @@ final class StandardHostValve extends ValveBase {
}
if (errorPage != null && response.isErrorReportRequired()) {
response.setAppCommitted(false);
-request.setAttribute(RequestDispatcher.ERROR_STATUS_CODE,
- Integer.valueOf(statusCode));
+request.setAttribute(RequestDispatcher.ERROR_STATUS_CODE,
Integer.valueOf(statusCode));
String message = response.getMessage();
if (message == null) {
message = "";
}
request.setAttribute(RequestDispatcher.ERROR_MESSAGE, message);
-request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
-errorPage.getLocation());
-request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
-DispatcherType.ERROR);
+request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
errorPage.getLocation());
+request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
DispatcherType.ERROR);
Wrapper wrapper = request.getWrapper();
if (wrapper != null) {
-request.setAttribute(RequestDispatcher.ERROR_SERVLET_NAME,
- wrapper.getName());
+request.setAttribute(RequestDispatcher.ERROR_SERVLET_NAME,
wrapper.getName());
}
-request.setAttribute(RequestDispatcher.ERROR_REQUEST_URI,
- request.getRequestURI());
+request.setAttribute(RequestDispatcher.ERROR_REQUEST_URI,
request.getRequestURI());
if (custom(request, response, errorPage)) {
response.setErrorReported();
try {
@@ -271,8 +266,7 @@ final class StandardHostValve extends ValveBase {
* @param throwable The exception that occurred (which possibly wraps
* a root cause exception
*/
-protected void throwable(Request request, Response response,
- Throwable throwable) {
+protected void throwable(Request request, Response response, Throwable
throwable) {
Context context = request.getContext();
if (context == null) {
return;
@@ -290,9 +284,7 @@ final class StandardHostValve extends ValveBase {
// If this is an aborted request from a client just log it and return
if (realError instanceof ClientAbortException ) {
if (log.isDebugEnabled()) {
-log.debug
-(sm.getString("standardHost.clientAbort",
-realError.getCause().getMessage()));
+log.debug(sm.getString("standardHost.clientAbort",
realError.getCause().getMessage()));
}
return;
}
@@ -305,25 +297,18 @@ final class StandardHostValve extends ValveBase {
if (errorPage != null) {
if (response.setErrorReported()) {
response.setAppCommitted(false);
-request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
-errorPage.getLocation());
-request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
-DispatcherType.ERROR);
+request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
errorPage.getLocation());
+request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
DispatcherType.ERROR);
request.setAttribute(RequestDispatcher.ERROR_STATUS_CODE,
Integer.valueOf(HttpServletResponse.SC_INTERNAL_SERVER_ERROR));
-request.setAttribute(RequestDispatcher.ERROR_MESSAGE,
- throwable.getMessage());
-request.setAttribute(RequestDispatcher.ERROR_EXCEPTION,
- realError);
+request.setAttribute(RequestDispatcher.ERROR_MESSAGE,
throwable.getMessage());
+request.setAttribute(RequestDispatcher.ERROR_EXCEPTION,
realError);
Wrapper wrapper = request.getWrapper();
[tomcat] branch 8.5.x updated: Formatting, no functional change.
This is an automated email from the ASF dual-hosted git repository.
markt 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 1f5898c840 Formatting, no functional change.
1f5898c840 is described below
commit 1f5898c840e7dbf5137e212f914cddbaa40b8062
Author: Mark Thomas
AuthorDate: Fri Nov 18 16:10:58 2022 +
Formatting, no functional change.
---
.../apache/catalina/core/StandardHostValve.java| 43 +++---
1 file changed, 14 insertions(+), 29 deletions(-)
diff --git a/java/org/apache/catalina/core/StandardHostValve.java
b/java/org/apache/catalina/core/StandardHostValve.java
index 0383d592b5..9f7ebd13de 100644
--- a/java/org/apache/catalina/core/StandardHostValve.java
+++ b/java/org/apache/catalina/core/StandardHostValve.java
@@ -225,27 +225,22 @@ final class StandardHostValve extends ValveBase {
}
if (errorPage != null && response.isErrorReportRequired()) {
response.setAppCommitted(false);
-request.setAttribute(RequestDispatcher.ERROR_STATUS_CODE,
- Integer.valueOf(statusCode));
+request.setAttribute(RequestDispatcher.ERROR_STATUS_CODE,
Integer.valueOf(statusCode));
String message = response.getMessage();
if (message == null) {
message = "";
}
request.setAttribute(RequestDispatcher.ERROR_MESSAGE, message);
-request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
-errorPage.getLocation());
-request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
-DispatcherType.ERROR);
+request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
errorPage.getLocation());
+request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
DispatcherType.ERROR);
Wrapper wrapper = request.getWrapper();
if (wrapper != null) {
-request.setAttribute(RequestDispatcher.ERROR_SERVLET_NAME,
- wrapper.getName());
+request.setAttribute(RequestDispatcher.ERROR_SERVLET_NAME,
wrapper.getName());
}
-request.setAttribute(RequestDispatcher.ERROR_REQUEST_URI,
- request.getRequestURI());
+request.setAttribute(RequestDispatcher.ERROR_REQUEST_URI,
request.getRequestURI());
if (custom(request, response, errorPage)) {
response.setErrorReported();
try {
@@ -271,8 +266,7 @@ final class StandardHostValve extends ValveBase {
* @param throwable The exception that occurred (which possibly wraps
* a root cause exception
*/
-protected void throwable(Request request, Response response,
- Throwable throwable) {
+protected void throwable(Request request, Response response, Throwable
throwable) {
Context context = request.getContext();
if (context == null) {
return;
@@ -290,9 +284,7 @@ final class StandardHostValve extends ValveBase {
// If this is an aborted request from a client just log it and return
if (realError instanceof ClientAbortException ) {
if (log.isDebugEnabled()) {
-log.debug
-(sm.getString("standardHost.clientAbort",
-realError.getCause().getMessage()));
+log.debug(sm.getString("standardHost.clientAbort",
realError.getCause().getMessage()));
}
return;
}
@@ -305,25 +297,18 @@ final class StandardHostValve extends ValveBase {
if (errorPage != null) {
if (response.setErrorReported()) {
response.setAppCommitted(false);
-request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
-errorPage.getLocation());
-request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
-DispatcherType.ERROR);
+request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
errorPage.getLocation());
+request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,
DispatcherType.ERROR);
request.setAttribute(RequestDispatcher.ERROR_STATUS_CODE,
Integer.valueOf(HttpServletResponse.SC_INTERNAL_SERVER_ERROR));
-request.setAttribute(RequestDispatcher.ERROR_MESSAGE,
- throwable.getMessage());
-request.setAttribute(RequestDispatcher.ERROR_EXCEPTION,
- realError);
+request.setAttribute(RequestDispatcher.ERROR_MESSAGE,
throwable.getMessage());
+request.setAttribute(RequestDispatcher.ERROR_EXCEPTION,
realError);
Wrapper wrapper = request.getWrapper();
[tomcat] branch main updated: Additional change required to support new error dispatch attribute
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 511d7256e5 Additional change required to support new error dispatch
attribute
511d7256e5 is described below
commit 511d7256e566fe5deef724bd9b90e911fe3241ce
Author: Mark Thomas
AuthorDate: Fri Nov 18 16:49:48 2022 +
Additional change required to support new error dispatch attribute
---
java/org/apache/jasper/runtime/PageContextImpl.java | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/java/org/apache/jasper/runtime/PageContextImpl.java
b/java/org/apache/jasper/runtime/PageContextImpl.java
index d2d7e90692..e3388f0aa7 100644
--- a/java/org/apache/jasper/runtime/PageContextImpl.java
+++ b/java/org/apache/jasper/runtime/PageContextImpl.java
@@ -595,10 +595,9 @@ public class PageContextImpl extends PageContext {
request.setAttribute(PageContext.EXCEPTION, t);
request.setAttribute(RequestDispatcher.ERROR_STATUS_CODE,
Integer.valueOf(HttpServletResponse.SC_INTERNAL_SERVER_ERROR));
-request.setAttribute(RequestDispatcher.ERROR_REQUEST_URI,
-((HttpServletRequest) request).getRequestURI());
-request.setAttribute(RequestDispatcher.ERROR_SERVLET_NAME,
-config.getServletName());
+request.setAttribute(RequestDispatcher.ERROR_REQUEST_URI,
((HttpServletRequest) request).getRequestURI());
+request.setAttribute(RequestDispatcher.ERROR_QUERY_STRING,
((HttpServletRequest) request).getQueryString());
+request.setAttribute(RequestDispatcher.ERROR_SERVLET_NAME,
config.getServletName());
try {
forward(errorPageURL);
} catch (IllegalStateException ise) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat doesn't gracefully close keep-alive connections
Hi Mark, thanks, I just tried this. It does cause the server to insert a 20 second delay on shutdown and I get this message in the log: 18-Nov-2022 18:16:29.777 INFO [main] org.apache.coyote.AbstractProtocol.awaitConnectionsClose Waiting [20,000] milliseconds for existing connections to ["http-nio-8080"] to complete and close. The server keeps responding to further requests on the established connections, but it also sends back headers as if in non-shutdown mode: Keep-Alive: timeout=20 Connection: keep-alive Thereby informing the client of the full 20 sec. keepalive timeout, making it think it can keep using the connection - so the client ends up getting the same error just with a 20 second delay... In fact, the server even accepts completely new connections during the graceful shutdown period period. Br, M. Thiim Den fre. 18. nov. 2022 kl. 14.34 skrev Mark Thomas : > On 17/11/2022 19:39, M. Thiim wrote: > > Hi, > > > > We have observed that Tomcat doesn't gracefully close > > keep-alive connections. Tomcat waits for already started requests to > > complete, but once those are done, Tomcat will close all connections > > immediately, irrespective of any configured keepAliveTimeout. This causes > > problems for some HTTP clients, especially in Kubernetes-like > environments > > when scaling down pods. Here, it can only work gracefully if the HTTP > > client who falls victim to an unexpectedly closed connection retries on a > > fresh connection, and it is not all clients that do this. > > > > I would think that an entirely graceful shutdown sequence, in the > presence > > of keep-alive connections, would work like the following: > > > > 1) Server receives shutdown request > > 2) Server immediately stops accepting new connections (already happens) > > 3) Server completes all requests already in (already happens) > > 4) New behavior: If new requests come in on already established > keep-alive > > connections those are processed, but a "Connection: close" is returned so > > the client knows this connection can no longer be used. So at most one > more > > request can be processed on each of those existing connections. > > 5) New behavior: When all keep-alive connections are gone, shutdown > > proceeds. If there are still connections left after the keepAliveTimeout > > has passed, this means no requests can have been received on those during > > the shutdown period (otherwise they would have been closed in #4). And > > since Tomcat returned the keep-alive timeout value to the client when the > > connection was setup, the client should know that the connection is no > > longer usable. Therefore it is from this point safe for Tomcat to close > > those remaining connections. > > 6) Rest of server shutdown continues > > Seems a reasonable addition. > > It looks like extending the behaviour when gracefulStopAwaitMillis is > set on the Service would work. > > gracefulStopAwaitMillis would need to be greater than or equal to the > keep-alive timeout but we can document that as part of the patch. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Tomcat doesn't gracefully close keep-alive connections
Please read the rest of the thread. On 18/11/2022 17:24, M. Thiim wrote: Hi Mark, thanks, I just tried this. It does cause the server to insert a 20 second delay on shutdown and I get this message in the log: 18-Nov-2022 18:16:29.777 INFO [main] org.apache.coyote.AbstractProtocol.awaitConnectionsClose Waiting [20,000] milliseconds for existing connections to ["http-nio-8080"] to complete and close. The server keeps responding to further requests on the established connections, but it also sends back headers as if in non-shutdown mode: Keep-Alive: timeout=20 Connection: keep-alive Thereby informing the client of the full 20 sec. keepalive timeout, making it think it can keep using the connection - so the client ends up getting the same error just with a 20 second delay... In fact, the server even accepts completely new connections during the graceful shutdown period period. Br, M. Thiim Den fre. 18. nov. 2022 kl. 14.34 skrev Mark Thomas : On 17/11/2022 19:39, M. Thiim wrote: Hi, We have observed that Tomcat doesn't gracefully close keep-alive connections. Tomcat waits for already started requests to complete, but once those are done, Tomcat will close all connections immediately, irrespective of any configured keepAliveTimeout. This causes problems for some HTTP clients, especially in Kubernetes-like environments when scaling down pods. Here, it can only work gracefully if the HTTP client who falls victim to an unexpectedly closed connection retries on a fresh connection, and it is not all clients that do this. I would think that an entirely graceful shutdown sequence, in the presence of keep-alive connections, would work like the following: 1) Server receives shutdown request 2) Server immediately stops accepting new connections (already happens) 3) Server completes all requests already in (already happens) 4) New behavior: If new requests come in on already established keep-alive connections those are processed, but a "Connection: close" is returned so the client knows this connection can no longer be used. So at most one more request can be processed on each of those existing connections. 5) New behavior: When all keep-alive connections are gone, shutdown proceeds. If there are still connections left after the keepAliveTimeout has passed, this means no requests can have been received on those during the shutdown period (otherwise they would have been closed in #4). And since Tomcat returned the keep-alive timeout value to the client when the connection was setup, the client should know that the connection is no longer usable. Therefore it is from this point safe for Tomcat to close those remaining connections. 6) Rest of server shutdown continues Seems a reasonable addition. It looks like extending the behaviour when gracefulStopAwaitMillis is set on the Service would work. gracefulStopAwaitMillis would need to be greater than or equal to the keep-alive timeout but we can document that as part of the patch. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Update ErrorData for new error dispatch attribute
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 41258a7455 Update ErrorData for new error dispatch attribute
41258a7455 is described below
commit 41258a7455291e5eb6e0ffefcb5cfffcbbd29b37
Author: Mark Thomas
AuthorDate: Fri Nov 18 17:36:24 2022 +
Update ErrorData for new error dispatch attribute
---
java/jakarta/servlet/jsp/ErrorData.java | 35 +++
java/jakarta/servlet/jsp/PageContext.java | 10 -
webapps/docs/changelog.xml| 6 ++
3 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/java/jakarta/servlet/jsp/ErrorData.java
b/java/jakarta/servlet/jsp/ErrorData.java
index 7ab0f12b67..ca7d610522 100644
--- a/java/jakarta/servlet/jsp/ErrorData.java
+++ b/java/jakarta/servlet/jsp/ErrorData.java
@@ -31,6 +31,7 @@ public final class ErrorData {
private final int statusCode;
private final String uri;
private final String servletName;
+private final String queryString;
/**
* Creates a new ErrorData object.
@@ -43,13 +44,37 @@ public final class ErrorData {
*The request URI
* @param servletName
*The name of the servlet invoked
+ *
+ * @deprecated Use {#link {@link ErrorData#ErrorData(Throwable, int,
String,
+ * String, String)}
*/
+@Deprecated(since = "4.0", forRemoval = true)
public ErrorData(Throwable throwable, int statusCode, String uri,
String servletName) {
+this(throwable, statusCode, uri, servletName, null);
+}
+
+/**
+ * Creates a new ErrorData object.
+ *
+ * @param throwable
+ *The Throwable that is the cause of the error
+ * @param statusCode
+ *The status code of the error
+ * @param uri
+ *The request URI
+ * @param servletName
+ *The name of the servlet invoked
+ * @param queryString
+ *The request query string
+ */
+public ErrorData(Throwable throwable, int statusCode, String uri,
+String servletName, String queryString) {
this.throwable = throwable;
this.statusCode = statusCode;
this.uri = uri;
this.servletName = servletName;
+this.queryString = queryString;
}
/**
@@ -87,4 +112,14 @@ public final class ErrorData {
public String getServletName() {
return this.servletName;
}
+
+/**
+ * Returns the request query string or {@code null} if the request had no
+ * query string.
+ *
+ * @return The request query string
+ */
+public String getQueryString() {
+return this.queryString;
+}
}
diff --git a/java/jakarta/servlet/jsp/PageContext.java
b/java/jakarta/servlet/jsp/PageContext.java
index 391aa3372f..806721f333 100644
--- a/java/jakarta/servlet/jsp/PageContext.java
+++ b/java/jakarta/servlet/jsp/PageContext.java
@@ -521,13 +521,11 @@ public abstract class PageContext
}
return new ErrorData(
-(Throwable)getRequest().getAttribute(
-RequestDispatcher.ERROR_EXCEPTION),
+
(Throwable)getRequest().getAttribute(RequestDispatcher.ERROR_EXCEPTION),
status,
-(String)getRequest().getAttribute(
-RequestDispatcher.ERROR_REQUEST_URI),
-(String)getRequest().getAttribute(
-RequestDispatcher.ERROR_SERVLET_NAME)
+
(String)getRequest().getAttribute(RequestDispatcher.ERROR_REQUEST_URI),
+
(String)getRequest().getAttribute(RequestDispatcher.ERROR_SERVLET_NAME),
+
(String)getRequest().getAttribute(RequestDispatcher.ERROR_QUERY_STRING)
);
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 7a64f324c3..cf0c9c7f4d 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -219,6 +219,12 @@
66325: Fix concurrency issue in evaluation of expression
language containing lambda expressions. (markt)
+
+Update the ErrorData class in the JSP API to align with
the
+recent changes in the Jakarta Pages specification to support the new
+error dispatch attribute
+jakarta.servlet.error.query_string.
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Plans for Tomcat 11 milestone releases
Hi all, It is still very in the Jakarta EE 11 development process but we already have some changes in the main branch. Therefore I intend to start producing milestone releases from the December release round. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat doesn't gracefully close keep-alive connections
Hi Mark, sorry I'm not sure what you mean by "read the rest of the thread"... My "I just tried this..." was in response to your suggestion of using the bindOnInit and gracefulStopAwaitMillis parameters. Thx! Den fre. 18. nov. 2022 kl. 18.35 skrev Mark Thomas : > Please read the rest of the thread. > > On 18/11/2022 17:24, M. Thiim wrote: > > Hi Mark, > > > > thanks, I just tried this. It does cause the server to insert a 20 second > > delay on shutdown and I get this message in the log: > > > > 18-Nov-2022 18:16:29.777 INFO [main] > > org.apache.coyote.AbstractProtocol.awaitConnectionsClose Waiting [20,000] > > milliseconds for existing connections to ["http-nio-8080"] to complete > and > > close. > > > > The server keeps responding to further requests on the > > established connections, but it also sends back headers as if in > > non-shutdown mode: > > > > Keep-Alive: timeout=20 > > Connection: keep-alive > > > > Thereby informing the client of the full 20 sec. keepalive timeout, > making > > it think it can keep using the connection - so the client ends up getting > > the same error just with a 20 second delay... In fact, the server even > > accepts completely new connections during the graceful shutdown period > > period. > > > > Br, M. Thiim > > > > Den fre. 18. nov. 2022 kl. 14.34 skrev Mark Thomas : > > > >> On 17/11/2022 19:39, M. Thiim wrote: > >>> Hi, > >>> > >>> We have observed that Tomcat doesn't gracefully close > >>> keep-alive connections. Tomcat waits for already started requests to > >>> complete, but once those are done, Tomcat will close all connections > >>> immediately, irrespective of any configured keepAliveTimeout. This > causes > >>> problems for some HTTP clients, especially in Kubernetes-like > >> environments > >>> when scaling down pods. Here, it can only work gracefully if the HTTP > >>> client who falls victim to an unexpectedly closed connection retries > on a > >>> fresh connection, and it is not all clients that do this. > >>> > >>> I would think that an entirely graceful shutdown sequence, in the > >> presence > >>> of keep-alive connections, would work like the following: > >>> > >>> 1) Server receives shutdown request > >>> 2) Server immediately stops accepting new connections (already happens) > >>> 3) Server completes all requests already in (already happens) > >>> 4) New behavior: If new requests come in on already established > >> keep-alive > >>> connections those are processed, but a "Connection: close" is returned > so > >>> the client knows this connection can no longer be used. So at most one > >> more > >>> request can be processed on each of those existing connections. > >>> 5) New behavior: When all keep-alive connections are gone, shutdown > >>> proceeds. If there are still connections left after the > keepAliveTimeout > >>> has passed, this means no requests can have been received on those > during > >>> the shutdown period (otherwise they would have been closed in #4). And > >>> since Tomcat returned the keep-alive timeout value to the client when > the > >>> connection was setup, the client should know that the connection is no > >>> longer usable. Therefore it is from this point safe for Tomcat to close > >>> those remaining connections. > >>> 6) Rest of server shutdown continues > >> > >> Seems a reasonable addition. > >> > >> It looks like extending the behaviour when gracefulStopAwaitMillis is > >> set on the Service would work. > >> > >> gracefulStopAwaitMillis would need to be greater than or equal to the > >> keep-alive timeout but we can document that as part of the patch. > >> > >> Mark > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Tomcat doesn't gracefully close keep-alive connections
On 18/11/2022 17:40, M. Thiim wrote: Hi Mark, sorry I'm not sure what you mean by "read the rest of the thread"... My "I just tried this..." was in response to your suggestion of using the bindOnInit and gracefulStopAwaitMillis parameters. Thx! The behaviour you describe is consistent with bindOnInit="true". It needs to be false for this to work. Mark Den fre. 18. nov. 2022 kl. 18.35 skrev Mark Thomas : Please read the rest of the thread. On 18/11/2022 17:24, M. Thiim wrote: Hi Mark, thanks, I just tried this. It does cause the server to insert a 20 second delay on shutdown and I get this message in the log: 18-Nov-2022 18:16:29.777 INFO [main] org.apache.coyote.AbstractProtocol.awaitConnectionsClose Waiting [20,000] milliseconds for existing connections to ["http-nio-8080"] to complete and close. The server keeps responding to further requests on the established connections, but it also sends back headers as if in non-shutdown mode: Keep-Alive: timeout=20 Connection: keep-alive Thereby informing the client of the full 20 sec. keepalive timeout, making it think it can keep using the connection - so the client ends up getting the same error just with a 20 second delay... In fact, the server even accepts completely new connections during the graceful shutdown period period. Br, M. Thiim Den fre. 18. nov. 2022 kl. 14.34 skrev Mark Thomas : On 17/11/2022 19:39, M. Thiim wrote: Hi, We have observed that Tomcat doesn't gracefully close keep-alive connections. Tomcat waits for already started requests to complete, but once those are done, Tomcat will close all connections immediately, irrespective of any configured keepAliveTimeout. This causes problems for some HTTP clients, especially in Kubernetes-like environments when scaling down pods. Here, it can only work gracefully if the HTTP client who falls victim to an unexpectedly closed connection retries on a fresh connection, and it is not all clients that do this. I would think that an entirely graceful shutdown sequence, in the presence of keep-alive connections, would work like the following: 1) Server receives shutdown request 2) Server immediately stops accepting new connections (already happens) 3) Server completes all requests already in (already happens) 4) New behavior: If new requests come in on already established keep-alive connections those are processed, but a "Connection: close" is returned so the client knows this connection can no longer be used. So at most one more request can be processed on each of those existing connections. 5) New behavior: When all keep-alive connections are gone, shutdown proceeds. If there are still connections left after the keepAliveTimeout has passed, this means no requests can have been received on those during the shutdown period (otherwise they would have been closed in #4). And since Tomcat returned the keep-alive timeout value to the client when the connection was setup, the client should know that the connection is no longer usable. Therefore it is from this point safe for Tomcat to close those remaining connections. 6) Rest of server shutdown continues Seems a reasonable addition. It looks like extending the behaviour when gracefulStopAwaitMillis is set on the Service would work. gracefulStopAwaitMillis would need to be greater than or equal to the keep-alive timeout but we can document that as part of the patch. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat doesn't gracefully close keep-alive connections
Hi Mark, ahh missed that - I just tried, you are right, it seems to give exactly what we want... closing connections on next incoming request when possible and otherwise waiting for the shutdown to complete. Thanks a lot and have a nice weekend. - M Den fre. 18. nov. 2022 kl. 18.49 skrev Mark Thomas : > On 18/11/2022 17:40, M. Thiim wrote: > > Hi Mark, sorry I'm not sure what you mean by "read the rest of the > > thread"... My "I just tried this..." was in response to your suggestion > of > > using the bindOnInit and gracefulStopAwaitMillis parameters. Thx! > > The behaviour you describe is consistent with bindOnInit="true". It > needs to be false for this to work. > > Mark > > > > > > > > > > Den fre. 18. nov. 2022 kl. 18.35 skrev Mark Thomas : > > > >> Please read the rest of the thread. > >> > >> On 18/11/2022 17:24, M. Thiim wrote: > >>> Hi Mark, > >>> > >>> thanks, I just tried this. It does cause the server to insert a 20 > second > >>> delay on shutdown and I get this message in the log: > >>> > >>> 18-Nov-2022 18:16:29.777 INFO [main] > >>> org.apache.coyote.AbstractProtocol.awaitConnectionsClose Waiting > [20,000] > >>> milliseconds for existing connections to ["http-nio-8080"] to complete > >> and > >>> close. > >>> > >>> The server keeps responding to further requests on the > >>> established connections, but it also sends back headers as if in > >>> non-shutdown mode: > >>> > >>> Keep-Alive: timeout=20 > >>> Connection: keep-alive > >>> > >>> Thereby informing the client of the full 20 sec. keepalive timeout, > >> making > >>> it think it can keep using the connection - so the client ends up > getting > >>> the same error just with a 20 second delay... In fact, the server even > >>> accepts completely new connections during the graceful shutdown period > >>> period. > >>> > >>> Br, M. Thiim > >>> > >>> Den fre. 18. nov. 2022 kl. 14.34 skrev Mark Thomas : > >>> > On 17/11/2022 19:39, M. Thiim wrote: > > Hi, > > > > We have observed that Tomcat doesn't gracefully close > > keep-alive connections. Tomcat waits for already started requests to > > complete, but once those are done, Tomcat will close all connections > > immediately, irrespective of any configured keepAliveTimeout. This > >> causes > > problems for some HTTP clients, especially in Kubernetes-like > environments > > when scaling down pods. Here, it can only work gracefully if the HTTP > > client who falls victim to an unexpectedly closed connection retries > >> on a > > fresh connection, and it is not all clients that do this. > > > > I would think that an entirely graceful shutdown sequence, in the > presence > > of keep-alive connections, would work like the following: > > > > 1) Server receives shutdown request > > 2) Server immediately stops accepting new connections (already > happens) > > 3) Server completes all requests already in (already happens) > > 4) New behavior: If new requests come in on already established > keep-alive > > connections those are processed, but a "Connection: close" is > returned > >> so > > the client knows this connection can no longer be used. So at most > one > more > > request can be processed on each of those existing connections. > > 5) New behavior: When all keep-alive connections are gone, shutdown > > proceeds. If there are still connections left after the > >> keepAliveTimeout > > has passed, this means no requests can have been received on those > >> during > > the shutdown period (otherwise they would have been closed in #4). > And > > since Tomcat returned the keep-alive timeout value to the client when > >> the > > connection was setup, the client should know that the connection is > no > > longer usable. Therefore it is from this point safe for Tomcat to > close > > those remaining connections. > > 6) Rest of server shutdown continues > > Seems a reasonable addition. > > It looks like extending the behaviour when gracefulStopAwaitMillis is > set on the Service would work. > > gracefulStopAwaitMillis would need to be greater than or equal to the > keep-alive timeout but we can document that as part of the patch. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > >>> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Release Apache Tomcat 8.5.84
Han, On 11/17/22 05:28, Han Li wrote: 2022年11月17日 17:52，Mark Thomas 写道： On 17/11/2022 08:23, Han Li wrote: 2022年11月17日 16:08，Mark Thomas 写道： On 17/11/2022 04:04, Han Li wrote: I think that I encounter a problem, shown below: org.apache.jasper.JasperException: Unable to compile class for JSP: An error occurred at line: [17] in the jsp file: [/jsp/include/foo.jsp] System cannot be resolved 14: See the License for the specific language governing permissions and 15: limitations under the License. 16: 17: --%><%= System.currentTimeMillis() %> Stacktrace: org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:102) org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:213) org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:589) org.apache.jasper.compiler.Compiler.compile(Compiler.java:380) org.apache.jasper.compiler.Compiler.compile(Compiler.java:350) org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:597) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:398) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:383) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:331) javax.servlet.http.HttpServlet.service(HttpServlet.java:765) org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilter(HttpHeaderSecurityFilter.java:126) org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109) Ant test show passes, but there are problems. (I downloaded 8.5.83 from the official website, then accessed example webapp and also have this problem). I don’t know JDT, but I tested again by upgrading ecj version to 4.25 and this problem was solved. I can't repeat this. I downloaded the 8.5.84 RC and then tested with Oracle JDK 1.7.0_80. The JSP include example worked. I then cleared out the work directory, switched to Temurin JDK 11.0.17_08 and tested the JSP include example. That worked too. I made no changes to the Eclipse compiler JAR. Can you provide the exact steps to recreate the issue from a clean 8.5.84 download? There are no exact steps, just need to simply access this url: http://localhost:8080/examples/jsp/include/foo.jsp The Java version was the key. Eclispe JDT 4.6.3 can't compile JSPs under Java 17 as it can't read the Java 17 class files. We can't update JDT as that is the latest version that works with Java 7 and Tomcat 8.x has a (specification mandated) minimum Java version of 7. Updating the JDT locally, as you found, is the way to work around this problem. Got it. In that case, I think we need to mark the upper limit of JDK version on documentation for 8.5.x. +1 I think we should update the web site to include a note that there is actually a "qualified upper limit" on the Java version supported by Tomcat 8.5.x out of the box, but you can manually-upgrade jdt to version N which is compatible with both Tomcat 8.5.x and Java 17. I don't think this issue imperils this release, though. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat doesn't gracefully close keep-alive connections
Mark, On 11/18/22 10:38, Mark Thomas wrote: I've just found the comment I missed the first time. This has already been implemented. You need to set the following: Connector bindOnInit="false" Service gracefulStopAwaitMillis="2" This assumes you are using the default keep-alive timeout of 20s. If not, adjust gracefulStopAwaitMillis accordingly. It needs to be at least as long as the keep-alive timeout. Should we cross-check these two configuration items and issue WARNING at startup if gracefulStopAwaitMillis < keepAliveTimeout? -chris On 18/11/2022 14:59, Mark Thomas wrote: PRs are always welcome. From the description provided, I think more use of the existing graceful shutdown could be made. I am also looking at whether a slightly broader refactoring is called for as there looks to be scope for better alignment between pause, stop and graceful stop. Mark On 18/11/2022 14:29, M. Thiim wrote: Hi Mark Great! I've actually made an experimental patch that fixes it, but it's perhaps not completely clean. To get the behavior the waiting needs to happen after the server has stopped accepting new connections, this seems to be the pause-phase. But the Http11Processoer rejects incoming requests during the pause phase (condition check in the while loop in the service() method and also further down in the method), so I had to change this behaviour as well (so it accepts requests but responds to them with Connection: Close). I don't know if this breaks some assumptions that it now continues to process requests in the pause phase. I also had to add a .waitForConnectionDrain() to the Connector class and to the protocol handler. Also, in order to avoid waiting for the full duration of the keepAliveTimeout in the cases when there's either no kept alive connections to begin with or where the server is able to close them earlier (due to new requests coming in that can be responded with Connection: Close, as would typically be the case in a busy system) I had to have a count on current number of connections. The getConnectionCount() in AbstractEndpoint.java seemed useful but there's catch: Its counting is based on the value of the connectionLimitLatch and this is specifically nulled out during the pause phase (I suppose because it also has the function of limiting connections), so the getConnectionCount() method returns -1 even if there are open connections. So I added a separate AtomicInteger that tracks the number of connections independently of the state and then changed getConnectionCount() to use this in the situations where the connectionLimitLatch is null. I can clean up and share the patch, but let me know if you think it should be done differently than described above. :-) Br, M. Thiim Den fre. 18. nov. 2022 kl. 14.34 skrev Mark Thomas : On 17/11/2022 19:39, M. Thiim wrote: Hi, We have observed that Tomcat doesn't gracefully close keep-alive connections. Tomcat waits for already started requests to complete, but once those are done, Tomcat will close all connections immediately, irrespective of any configured keepAliveTimeout. This causes problems for some HTTP clients, especially in Kubernetes-like environments when scaling down pods. Here, it can only work gracefully if the HTTP client who falls victim to an unexpectedly closed connection retries on a fresh connection, and it is not all clients that do this. I would think that an entirely graceful shutdown sequence, in the presence of keep-alive connections, would work like the following: 1) Server receives shutdown request 2) Server immediately stops accepting new connections (already happens) 3) Server completes all requests already in (already happens) 4) New behavior: If new requests come in on already established keep-alive connections those are processed, but a "Connection: close" is returned so the client knows this connection can no longer be used. So at most one more request can be processed on each of those existing connections. 5) New behavior: When all keep-alive connections are gone, shutdown proceeds. If there are still connections left after the keepAliveTimeout has passed, this means no requests can have been received on those during the shutdown period (otherwise they would have been closed in #4). And since Tomcat returned the keep-alive timeout value to the client when the connection was setup, the client should know that the connection is no longer usable. Therefore it is from this point safe for Tomcat to close those remaining connections. 6) Rest of server shutdown continues Seems a reasonable addition. It looks like extending the behaviour when gracefulStopAwaitMillis is set on the Service would work. gracefulStopAwaitMillis would need to be greater than or equal to the keep-alive timeout but we can document that as part of the patch. Mark - To unsubscribe, e-mail: dev-unsubscr...@t
[GitHub] [tomcat-maven-plugin] JLLeitschuh opened a new pull request, #39: [SECURITY] Fix Temporary File Information Disclosure Vulnerability
JLLeitschuh opened a new pull request, #39:
URL: https://github.com/apache/tomcat-maven-plugin/pull/39
# Security Vulnerability Fix
This pull request fixes a Temporary File Information Disclosure
Vulnerability, which existed in this project.
## Preamble
The system temporary directory is shared between all users on most unix-like
systems (not MacOS, or Windows). Thus, code interacting with the system
temporary directory must be careful about file interactions in this directory,
and must ensure that the correct file posix permissions are set.
This PR was generated because a call to `File.createTempFile(..)` was
detected in this repository in a way that makes this project vulnerable to
local information disclosure.
With the default uname configuration, `File.createTempFile(..)` creates a
file with the permissions `-rw-r--r--`. This means that any other user on the
system can read the contents of this file.
### Impact
Information in this file is visible to other local users, allowing a
malicious actor co-resident on the same machine to view potentially sensitive
files.
Other Examples
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) -
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) -
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) -
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) -
netty/netty
# The Fix
The fix has been to convert the logic above to use the following API that
was introduced in Java 1.7.
```java
File tmpDir = Files.createTempFile("temp dir").toFile();
```
The API both creates the file securely, ie. with a random, non-conflicting
name, with file permissions that only allow the currently executing user to
read or write the contents of this file.
By default, `Files.createTempFile("temp dir")` will create a file with the
permissions `-rw---`, which only allows the user that created the file to
view/write the file contents.
# :arrow_right: Vulnerability Disclosure :arrow_left:
:wave: Vulnerability disclosure is a super important part of the
vulnerability handling process and should not be skipped! This may be
completely new to you, and that's okay, I'm here to assist!
First question, do we need to perform vulnerability disclosure? It depends!
1. Is the vulnerable code only in tests or example code? No disclosure
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability
disclosure is probably required!
## Vulnerability Disclosure How-To
You have a few options options to perform vulnerability disclosure. However,
I'd like to suggest the following 2 options:
1. Request a CVE number from GitHub by creating a repository-level [GitHub
Security
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
This has the advantage that, if you provide sufficient information, GitHub
will automatically generate Dependabot alerts for your downstream consumers,
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
## Detecting this and Future Vulnerabilities
This vulnerability was automatically detected by GitHub's CodeQL using this
[CodeQL
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
You can automatically detect future vulnerabilities like this by enabling
the free (for open-source) [GitHub
Action](https://github.com/github/codeql-action).
I'm not an employee of GitHub, I'm simply an open-source security researcher.
## Source
This contribution was automatically generated with an
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to
bring this security fix to your repository.
The source code that generated this PR can be found here:
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
## Opting-Out
If you'd like to opt-out of future automated security vulnerability fixes
like this, please consider adding a file called
`.github/GH-ROBOTS.txt` to your repository with the line:
```
User-agent: JLLeitschuh/security-research
Disallow: *
```
This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt)
format for future contributions.
Alternatively, if this project is no longer actively maintained, consider
[archiving](https://help.github.com/en/github/creating-cloning-
svn commit: r1905391 - in /tomcat/site/trunk: docs/presentations.html xdocs/presentations.xml
Author: huxing
Date: Sat Nov 19 06:03:22 2022
New Revision: 1905391
URL: http://svn.apache.org/viewvc?rev=1905391&view=rev
Log:
Add ApacheCon Asia 2022 slides
Modified:
tomcat/site/trunk/docs/presentations.html
tomcat/site/trunk/xdocs/presentations.xml
Modified: tomcat/site/trunk/docs/presentations.html
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/presentations.html?rev=1905391&r1=1905390&r2=1905391&view=diff
==
--- tomcat/site/trunk/docs/presentations.html (original)
+++ tomcat/site/trunk/docs/presentations.html Sat Nov 19 06:03:22 2022
@@ -66,32 +66,32 @@ li.targeted {
State of the Cat - Mark Thomas,
-slides,
+https://people.apache.org/~huxing/acasia2022/Mark-Thomas-State-of-the-Cat.pdf";>slides,
https://www.youtube.com/watch?v=Sun8EF0jTZk";>video
Design and implementation of application graceful shutdown based on Tomcat
- Zihao Rao,
-slides,
+https://people.apache.org/~huxing/acasia2022/Zihao-Rao-Design-and-implementation-of-application-graceful-shutdown-based-on-Tomcat.pdf";>slides,
https://www.youtube.com/watch?v=lnp51wz4PlQ";>video (Chinese)
Extending Valves in Tomcat - Dennis Jacob,
-slides,
+https://people.apache.org/~huxing/acasia2022/Dennis-Jacob-Extending-Valves-in-Tomcat.pdf";>slides,
https://www.youtube.com/watch?v=Jmw-d0kyZ_4";>video
The application practice of Tomcat in Kuaishou - Yang Song,
-slides,
+https://people.apache.org/~huxing/acasia2022/Yang%20Song-The-application-practice-of-Tomcat-in-Kuaishou.pdf";>slides,
https://www.youtube.com/watch?v=40hRY00TbV8";>video (Chinese)
Jakarta EE - Mark Thomas,
-slides,
+https://people.apache.org/~huxing/acasia2022/Mark-Thomas-Jakarta-EE.pdf";>slides,
https://www.youtube.com/watch?v=C0y3w8yBeWg";>video
How we use and optimize Tomcat at Alibaba - Huxing Zhang,
-slides,
+https://people.apache.org/~huxing/acasia2022/Huxing-Zhang-How-we-use-and-optimize-Tomcat-at-Alibaba.pdf";>slides,
https://www.youtube.com/watch?v=LTMSjzgyNb8";>video
Modified: tomcat/site/trunk/xdocs/presentations.xml
URL:
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/presentations.xml?rev=1905391&r1=1905390&r2=1905391&view=diff
==
--- tomcat/site/trunk/xdocs/presentations.xml (original)
+++ tomcat/site/trunk/xdocs/presentations.xml Sat Nov 19 06:03:22 2022
@@ -74,32 +74,32 @@ li.targeted {
State of the Cat - Mark Thomas,
-slides,
+https://people.apache.org/~huxing/acasia2022/Mark-Thomas-State-of-the-Cat.pdf";>slides,
https://www.youtube.com/watch?v=Sun8EF0jTZk";>video
Design and implementation of application graceful shutdown based on Tomcat
- Zihao Rao,
-slides,
+https://people.apache.org/~huxing/acasia2022/Zihao-Rao-Design-and-implementation-of-application-graceful-shutdown-based-on-Tomcat.pdf";>slides,
https://www.youtube.com/watch?v=lnp51wz4PlQ";>video (Chinese)
Extending Valves in Tomcat - Dennis Jacob,
-slides,
+https://people.apache.org/~huxing/acasia2022/Dennis-Jacob-Extending-Valves-in-Tomcat.pdf";>slides,
https://www.youtube.com/watch?v=Jmw-d0kyZ_4";>video
The application practice of Tomcat in Kuaishou - Yang Song,
-slides,
+https://people.apache.org/~huxing/acasia2022/Yang%20Song-The-application-practice-of-Tomcat-in-Kuaishou.pdf";>slides,
https://www.youtube.com/watch?v=40hRY00TbV8";>video (Chinese)
Jakarta EE - Mark Thomas,
-slides,
+https://people.apache.org/~huxing/acasia2022/Mark-Thomas-Jakarta-EE.pdf";>slides,
https://www.youtube.com/watch?v=C0y3w8yBeWg";>video
How we use and optimize Tomcat at Alibaba - Huxing Zhang,
-slides,
+https://people.apache.org/~huxing/acasia2022/Huxing-Zhang-How-we-use-and-optimize-Tomcat-at-Alibaba.pdf";>slides,
https://www.youtube.com/watch?v=LTMSjzgyNb8";>video
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
