[Bug 65780] CoyoteOutputStream should never throw NullPointerException after AsyncContext.complete() is called
https://bz.apache.org/bugzilla/show_bug.cgi?id=65780 Remy Maucherat changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Remy Maucherat --- 1. Can you provide the NPE stack trace ? 2. No. isReady means that the write call will not block, not that it will return without an error of some sort. -- 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: Deadlock in unit tests for TC 8.5.73 on Solaris using zulu 1.8.0_312-b07
Hi Rainer, Thanks for finding this. It isn't something I have seen in my testing. I think this is something that needs to be fixed before the January set of releases. From the stack trace, it looks like the root cause is locks being obtained in an inconsistent order - a classic deadlock. I haven't looked at the code or the history yet so I am not sure if this is the direct result of a recent change or if another change has just made this easier to trigger. I plan to look at this today. Mark On 01/01/2022 19:07, Rainer Jung wrote: Hi hi, I am running the unit tests for TC 8.5.73 plus few post-release patches on Solaris 10 Sparc with various Java 8 JVMs. I noticed one deadlock when running on Zulu 8.58.0.13-CA-solaris (build 1.8.0_312-b07). Maybe it is a sporadic deadlock and could also happen on the 1.8.0 variations, but I could not yet check that. I did not notice such a deadlock on 5 Linux distributions on which I also ran all unit tests with a variety of JVMs, including the Zulu one. Due to the logs the deadlock happens in org.apache.coyote.http2.TestCancelledUpload, but org.apache.coyote.http2.TestFlowControl runs concurrently at the same time (zwo test threads). Test methods are testCancelledRequest rwsp. testNotFound. The stacks are: Found one Java-level deadlock: = "http-nio-127.0.0.1-auto-1-exec-7": waiting to lock monitor 0x000100f99508 (object 0x41a99b40, a org.apache.coyote.http2.StreamStateMachine), which is held by "http-nio-127.0.0.1-auto-1-exec-5" "http-nio-127.0.0.1-auto-1-exec-5": waiting to lock monitor 0x0001002da838 (object 0x42015548, a org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper), which is held by "http-nio-127.0.0.1-auto-1-exec-7" Java stack information for the threads listed above: === "http-nio-127.0.0.1-auto-1-exec-7": at org.apache.coyote.http2.StreamStateMachine.checkFrameType(StreamStateMachine.java:125) - waiting to lock <0x41a99b40> (a org.apache.coyote.http2.StreamStateMachine) at org.apache.coyote.http2.AbstractNonZeroStream.checkState(AbstractNonZeroStream.java:144) at org.apache.coyote.http2.Http2UpgradeHandler.startRequestBodyFrame(Http2UpgradeHandler.java:1641) at org.apache.coyote.http2.Http2Parser.readDataFrame(Http2Parser.java:168) at org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:95) at org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:69) at org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:340) at org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:60) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:59) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:849) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1677) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) - locked <0x42015548> (a org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper) at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) "http-nio-127.0.0.1-auto-1-exec-5": at org.apache.coyote.http2.Http2UpgradeHandler.sendStreamReset(Http2UpgradeHandler.java:558) - waiting to lock <0x42015548> (a org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper) at org.apache.coyote.http2.Stream.close(Stream.java:623) - locked <0x41a99b40> (a org.apache.coyote.http2.StreamStateMachine) at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:85) - locked <0x41ac4888> (a org.apache.coyote.http2.StreamProcessor) at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35) at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) I am attaching the detailed log from the start of the test cases until the last line that was logged for either of the two deadlocked threads. Note that unit testing proceeds for test thread 1 until the remaining tests are done. Only testing on thread 2 stopps due to the deadlock. I will kill the process now
Re: [tomcat] branch 10.0.x updated: Update Eclipse JDT from 4.20 to 4.22
It seems JDT 4.22 contains Java 11 compiled classes:
compile:
...
[javac]
/shared/build/dev/tomcat/git/10.0.x/java/org/apache/jasper/compiler/JDTCompiler.java:40:
error: cannot access IProblem
[javac] import org.eclipse.jdt.core.compiler.IProblem;
[javac] ^
[javac] bad class file:
/path/to/ecj-4.22/ecj-4.22.jar(org/eclipse/jdt/core/compiler/IProblem.class)
[javac] class file has wrong version 55.0, should be 52.0
[javac] Please remove or make sure it appears in the correct
subdirectory of the classpath.
Best regards,
Rainer
Am 02.01.2022 um 17:08 schrieb ma...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.0.x by this push:
new d08f3d9 Update Eclipse JDT from 4.20 to 4.22
d08f3d9 is described below
commit d08f3d9a3126867cfc787626a2dc0295261016d3
Author: Mark Thomas
AuthorDate: Sun Jan 2 16:02:32 2022 +
Update Eclipse JDT from 4.20 to 4.22
---
build.properties.default| 12 ++--
res/ide-support/eclipse/eclipse.classpath | 2 +-
res/ide-support/idea/tomcat.iml | 2 +-
res/ide-support/netbeans/nb-tomcat-build.properties | 2 +-
res/ide-support/netbeans/project.xml| 2 +-
res/maven/tomcat-jasper.pom | 2 +-
webapps/docs/changelog.xml | 3 +++
7 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/build.properties.default b/build.properties.default
index 3d55063..60d1598 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -137,15 +137,15 @@
wsdl4j-lib.loc=${base-maven.loc}/wsdl4j/wsdl4j/${wsdl4j-lib.version}/wsdl4j-${ws
# - Eclipse JDT, version 4.7 or later -#
# See
https://cwiki.apache.org/confluence/display/TOMCAT/Managing+Tomcat%27s+Dependency+on+the+Eclipse+JDT+Core+Batch+Compiler
#
-# Checksum is from "SHA512 Checksums for 4.20" link at
-# https://download.eclipse.org/eclipse/downloads/drops4/R-4.20-202106111600/
-#
https://download.eclipse.org/eclipse/downloads/drops4/R-4.20-202106111600/checksum/eclipse-4.20-SUMSSHA512
+# Checksum is from "SHA512 Checksums for 4.22" link at
+# https://download.eclipse.org/eclipse/downloads/drops4/R-4.22-202111241800/
+#
https://download.eclipse.org/eclipse/downloads/drops4/R-4.22-202111241800/checksum/eclipse-4.22-SUMSSHA512
#
-jdt.version=4.20
-jdt.release=R-4.20-202106111600
+jdt.version=4.22
+jdt.release=R-4.22-202111241800
jdt.checksum.enabled=true
jdt.checksum.algorithm=SHA-512
-jdt.checksum.value=ab441acf5551a7dc81c353eaccb3b3df9e89a48987294d19e39acdb83a5b640fcdff7414cee29f5b96eaa8826647f1d5323e185018fe33a64c402d69c73c9158
+jdt.checksum.value=a014bbedd96b31576bb2b28ad16ac23edc15b59833ac810409fd42834ac6081b695167903bec0fa98d614031aeb863b3de28697d4636f23b2c47ffd93f443aae
jdt.home=${base.path}/ecj-${jdt.version}
jdt.jar=${jdt.home}/ecj-${jdt.version}.jar
# The download will be moved to the archive area eventually. We are taking
care of that in advance.
diff --git a/res/ide-support/eclipse/eclipse.classpath
b/res/ide-support/eclipse/eclipse.classpath
index cc24716..b081ec5 100644
--- a/res/ide-support/eclipse/eclipse.classpath
+++ b/res/ide-support/eclipse/eclipse.classpath
@@ -24,7 +24,7 @@
-
+
diff --git a/res/ide-support/idea/tomcat.iml b/res/ide-support/idea/tomcat.iml
index a77a639..6e6a29a 100644
--- a/res/ide-support/idea/tomcat.iml
+++ b/res/ide-support/idea/tomcat.iml
@@ -68,7 +68,7 @@
-
+
diff --git a/res/ide-support/netbeans/nb-tomcat-build.properties
b/res/ide-support/netbeans/nb-tomcat-build.properties
index 65b5205..c1c5039 100644
--- a/res/ide-support/netbeans/nb-tomcat-build.properties
+++ b/res/ide-support/netbeans/nb-tomcat-build.properties
@@ -37,7 +37,7 @@ nb-test.io-method=org.apache.coyote.http11.Http11NioProtocol
# it is not possible to retrieve the classpaths from the build to
# use in the NetBeans targets, so they must be explicitly declared
-nb-test.classpath=${test.classes}:${tomcat.build}/webapps/examples/WEB-INF/classes:${base.path}/junit-4.13/junit-4.13.jar:${base.path}/easymock-4.3/easymock-4.3.jar:${base.path}/objenesis-3.2/objenesis-3.2.jar:${base.path}/cglib-3.3.0/cglib-nodep-3.3.0.jar:${base.path}/hamcrest-2.2/hamcrest-2.2.jar:${base.path}/ecj-4.20/ecj-4.20.jar:${tomcat.classes}
+nb-test.classpath=${test.classes}:${tomcat.build}/webapps/examples/WEB-INF/classes:${base.path}/junit-4.13/junit-4.13.jar:${base.path}/easymock-4.3/easymock-4.3.jar:${base.path}/objenesis-3.2/objenesis-3.2.jar:${base.path}/cglib-3.3.0/cglib-nodep-3.3.0.jar:${base.path}/hamcrest-2.2/hamcrest-2.2.jar:${base.path}/ecj-4.22/ecj-4.22.jar:${
Re: [tomcat] branch 10.0.x updated: Update Eclipse JDT from 4.20 to 4.22
For reference: this is probably the ticket about moving JDT (and ECJ) to
Java 11:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=572389
And this is the parallel mail discussion:
https://www.eclipse.org/lists/eclipse-dev/msg11703.html
If we roll back the change for TC 10.0 and 9, there is also the later
change about JSP compilation for Java 17/18 that was depeding on the ECJ
update.
Regards,
Rainer
Am 03.01.2022 um 11:28 schrieb Rainer Jung:
It seems JDT 4.22 contains Java 11 compiled classes:
compile:
...
[javac]
/shared/build/dev/tomcat/git/10.0.x/java/org/apache/jasper/compiler/JDTCompiler.java:40:
error: cannot access IProblem
[javac] import org.eclipse.jdt.core.compiler.IProblem;
[javac] ^
[javac] bad class file:
/path/to/ecj-4.22/ecj-4.22.jar(org/eclipse/jdt/core/compiler/IProblem.class)
[javac] class file has wrong version 55.0, should be 52.0
[javac] Please remove or make sure it appears in the correct
subdirectory of the classpath.
Best regards,
Rainer
Am 02.01.2022 um 17:08 schrieb ma...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.0.x by this push:
new d08f3d9 Update Eclipse JDT from 4.20 to 4.22
d08f3d9 is described below
commit d08f3d9a3126867cfc787626a2dc0295261016d3
Author: Mark Thomas
AuthorDate: Sun Jan 2 16:02:32 2022 +
Update Eclipse JDT from 4.20 to 4.22
---
build.properties.default | 12 ++--
res/ide-support/eclipse/eclipse.classpath | 2 +-
res/ide-support/idea/tomcat.iml | 2 +-
res/ide-support/netbeans/nb-tomcat-build.properties | 2 +-
res/ide-support/netbeans/project.xml | 2 +-
res/maven/tomcat-jasper.pom | 2 +-
webapps/docs/changelog.xml | 3 +++
7 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/build.properties.default b/build.properties.default
index 3d55063..60d1598 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -137,15 +137,15 @@
wsdl4j-lib.loc=${base-maven.loc}/wsdl4j/wsdl4j/${wsdl4j-lib.version}/wsdl4j-${ws
# - Eclipse JDT, version 4.7 or later -#
# See
https://cwiki.apache.org/confluence/display/TOMCAT/Managing+Tomcat%27s+Dependency+on+the+Eclipse+JDT+Core+Batch+Compiler
#
-# Checksum is from "SHA512 Checksums for 4.20" link at
-#
https://download.eclipse.org/eclipse/downloads/drops4/R-4.20-202106111600/
-#
https://download.eclipse.org/eclipse/downloads/drops4/R-4.20-202106111600/checksum/eclipse-4.20-SUMSSHA512
+# Checksum is from "SHA512 Checksums for 4.22" link at
+#
https://download.eclipse.org/eclipse/downloads/drops4/R-4.22-202111241800/
+#
https://download.eclipse.org/eclipse/downloads/drops4/R-4.22-202111241800/checksum/eclipse-4.22-SUMSSHA512
#
-jdt.version=4.20
-jdt.release=R-4.20-202106111600
+jdt.version=4.22
+jdt.release=R-4.22-202111241800
jdt.checksum.enabled=true
jdt.checksum.algorithm=SHA-512
-jdt.checksum.value=ab441acf5551a7dc81c353eaccb3b3df9e89a48987294d19e39acdb83a5b640fcdff7414cee29f5b96eaa8826647f1d5323e185018fe33a64c402d69c73c9158
+jdt.checksum.value=a014bbedd96b31576bb2b28ad16ac23edc15b59833ac810409fd42834ac6081b695167903bec0fa98d614031aeb863b3de28697d4636f23b2c47ffd93f443aae
jdt.home=${base.path}/ecj-${jdt.version}
jdt.jar=${jdt.home}/ecj-${jdt.version}.jar
# The download will be moved to the archive area eventually. We are
taking care of that in advance.
diff --git a/res/ide-support/eclipse/eclipse.classpath
b/res/ide-support/eclipse/eclipse.classpath
index cc24716..b081ec5 100644
--- a/res/ide-support/eclipse/eclipse.classpath
+++ b/res/ide-support/eclipse/eclipse.classpath
@@ -24,7 +24,7 @@
path="TOMCAT_LIBS_BASE/jaxrpc-1.1-rc4/geronimo-spec-jaxrpc-1.1-rc4.jar"/>
path="TOMCAT_LIBS_BASE/wsdl4j-1.6.3/wsdl4j-1.6.3.jar"/>
- path="TOMCAT_LIBS_BASE/ecj-4.20/ecj-4.20.jar"/>
+ path="TOMCAT_LIBS_BASE/ecj-4.22/ecj-4.22.jar"/>
path="TOMCAT_LIBS_BASE/easymock-4.3/easymock-4.3.jar"/>
path="TOMCAT_LIBS_BASE/hamcrest-2.2/hamcrest-2.2.jar"/>
path="TOMCAT_LIBS_BASE/cglib-3.3.0/cglib-nodep-3.3.0.jar"/>
diff --git a/res/ide-support/idea/tomcat.iml
b/res/ide-support/idea/tomcat.iml
index a77a639..6e6a29a 100644
--- a/res/ide-support/idea/tomcat.iml
+++ b/res/ide-support/idea/tomcat.iml
@@ -68,7 +68,7 @@
- url="jar://$TOMCAT_BUILD_LIBS$/ecj-4.20/ecj-4.20.jar!/" />
+ url="jar://$TOMCAT_BUILD_LIBS$/ecj-4.22/ecj-4.22.jar!/" />
diff --git a/res/ide-support/netbeans/nb-tomcat-build.properties
b/res/ide-support/netbeans/nb-tomcat-build.properties
index 65b5205..c1c5039 100644
--- a/res/ide-support/netbean
Re: Deadlock in unit tests for TC 8.5.73 on Solaris using zulu 1.8.0_312-b07
On 03/01/2022 09:45, Mark Thomas wrote: Hi Rainer, Thanks for finding this. It isn't something I have seen in my testing. I think this is something that needs to be fixed before the January set of releases. From the stack trace, it looks like the root cause is locks being obtained in an inconsistent order - a classic deadlock. I haven't looked at the code or the history yet so I am not sure if this is the direct result of a recent change or if another change has just made this easier to trigger. I plan to look at this today. This change and the back-ports appear to be the trigger for this deadlock: https://github.com/apache/tomcat/commit/5782322afd31adf98b72288f99965c6811dcdcdd Mark Mark On 01/01/2022 19:07, Rainer Jung wrote: Hi hi, I am running the unit tests for TC 8.5.73 plus few post-release patches on Solaris 10 Sparc with various Java 8 JVMs. I noticed one deadlock when running on Zulu 8.58.0.13-CA-solaris (build 1.8.0_312-b07). Maybe it is a sporadic deadlock and could also happen on the 1.8.0 variations, but I could not yet check that. I did not notice such a deadlock on 5 Linux distributions on which I also ran all unit tests with a variety of JVMs, including the Zulu one. Due to the logs the deadlock happens in org.apache.coyote.http2.TestCancelledUpload, but org.apache.coyote.http2.TestFlowControl runs concurrently at the same time (zwo test threads). Test methods are testCancelledRequest rwsp. testNotFound. The stacks are: Found one Java-level deadlock: = "http-nio-127.0.0.1-auto-1-exec-7": waiting to lock monitor 0x000100f99508 (object 0x41a99b40, a org.apache.coyote.http2.StreamStateMachine), which is held by "http-nio-127.0.0.1-auto-1-exec-5" "http-nio-127.0.0.1-auto-1-exec-5": waiting to lock monitor 0x0001002da838 (object 0x42015548, a org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper), which is held by "http-nio-127.0.0.1-auto-1-exec-7" Java stack information for the threads listed above: === "http-nio-127.0.0.1-auto-1-exec-7": at org.apache.coyote.http2.StreamStateMachine.checkFrameType(StreamStateMachine.java:125) - waiting to lock <0x41a99b40> (a org.apache.coyote.http2.StreamStateMachine) at org.apache.coyote.http2.AbstractNonZeroStream.checkState(AbstractNonZeroStream.java:144) at org.apache.coyote.http2.Http2UpgradeHandler.startRequestBodyFrame(Http2UpgradeHandler.java:1641) at org.apache.coyote.http2.Http2Parser.readDataFrame(Http2Parser.java:168) at org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:95) at org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:69) at org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:340) at org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:60) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:59) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:849) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1677) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) - locked <0x42015548> (a org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper) at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) "http-nio-127.0.0.1-auto-1-exec-5": at org.apache.coyote.http2.Http2UpgradeHandler.sendStreamReset(Http2UpgradeHandler.java:558) - waiting to lock <0x42015548> (a org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper) at org.apache.coyote.http2.Stream.close(Stream.java:623) - locked <0x41a99b40> (a org.apache.coyote.http2.StreamStateMachine) at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:85) - locked <0x41ac4888> (a org.apache.coyote.http2.StreamProcessor) at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35) at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) I am attaching the detailed log from the start of the test cases until the last line that was logged for
Re: Deadlock in unit tests for TC 8.5.73 on Solaris using zulu 1.8.0_312-b07
Thanks Marc.
In the meantime, I can also say, that it happens for TC 8.5 using JSSE
or OpenSSL and NIO or NIO2. I did not try APR.
Unfortunately I can still reproduce on TC 8.5 even without the sync
patch you mentioned below. The code curretly under test has:
diff --git a/java/org/apache/coyote/http2/Stream.java
b/java/org/apache/coyote/http2/Stream.java
index fffd2403e8..196cd5b85c 100644
--- a/java/org/apache/coyote/http2/Stream.java
+++ b/java/org/apache/coyote/http2/Stream.java
@@ -614,14 +614,8 @@ class Stream extends AbstractNonZeroStream
implements HeaderEmitter {
log.debug(sm.getString("stream.reset.send",
getConnectionId(), getIdAsString(),
se.getError()));
}
-// Sync ensures that if the call to sendReset()
triggers resets
-// in other threads, that the RST frame associated with
this
-// thread is sent before the RST frames associated with
those
-// threads.
-synchronized (state) {
-state.sendReset();
-handler.sendStreamReset(se);
-}
+state.sendReset();
+handler.sendStreamReset(se);
cancelAllocationRequests();
if (inputBuffer != null) {
inputBuffer.swallowUnread();
But: For TC 10.0 I could not reproduce as easily, even not with the
original sync code in place. I stopped after 20 attempts without
deadlock, but will try longer for TC 10 and also TC 9 later today.
Thanks and regards,
Rainer
Am 03.01.2022 um 11:55 schrieb Mark Thomas:
On 03/01/2022 09:45, Mark Thomas wrote:
Hi Rainer,
Thanks for finding this. It isn't something I have seen in my testing.
I think this is something that needs to be fixed before the January
set of releases.
From the stack trace, it looks like the root cause is locks being
obtained in an inconsistent order - a classic deadlock.
I haven't looked at the code or the history yet so I am not sure if
this is the direct result of a recent change or if another change has
just made this easier to trigger. I plan to look at this today.
This change and the back-ports appear to be the trigger for this deadlock:
https://github.com/apache/tomcat/commit/5782322afd31adf98b72288f99965c6811dcdcdd
Mark
Mark
On 01/01/2022 19:07, Rainer Jung wrote:
Hi hi,
I am running the unit tests for TC 8.5.73 plus few post-release
patches on Solaris 10 Sparc with various Java 8 JVMs. I noticed one
deadlock when running on Zulu 8.58.0.13-CA-solaris (build
1.8.0_312-b07). Maybe it is a sporadic deadlock and could also happen
on the 1.8.0 variations, but I could not yet check that. I did not
notice such a deadlock on 5 Linux distributions on which I also ran
all unit tests with a variety of JVMs, including the Zulu one.
Due to the logs the deadlock happens in
org.apache.coyote.http2.TestCancelledUpload, but
org.apache.coyote.http2.TestFlowControl runs concurrently at the same
time (zwo test threads). Test methods are testCancelledRequest rwsp.
testNotFound.
The stacks are:
Found one Java-level deadlock:
=
"http-nio-127.0.0.1-auto-1-exec-7":
waiting to lock monitor 0x000100f99508 (object
0x41a99b40, a org.apache.coyote.http2.StreamStateMachine),
which is held by "http-nio-127.0.0.1-auto-1-exec-5"
"http-nio-127.0.0.1-auto-1-exec-5":
waiting to lock monitor 0x0001002da838 (object
0x42015548, a
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper),
which is held by "http-nio-127.0.0.1-auto-1-exec-7"
Java stack information for the threads listed above:
===
"http-nio-127.0.0.1-auto-1-exec-7":
at
org.apache.coyote.http2.StreamStateMachine.checkFrameType(StreamStateMachine.java:125)
- waiting to lock <0x41a99b40> (a
org.apache.coyote.http2.StreamStateMachine)
at
org.apache.coyote.http2.AbstractNonZeroStream.checkState(AbstractNonZeroStream.java:144)
at
org.apache.coyote.http2.Http2UpgradeHandler.startRequestBodyFrame(Http2UpgradeHandler.java:1641)
at
org.apache.coyote.http2.Http2Parser.readDataFrame(Http2Parser.java:168)
at
org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:95)
at
org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:69)
at
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:340)
at
org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:60)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:59)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:849)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1677)
[tomcat] branch 10.0.x updated (d039b4c -> 9e3fc44)
This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch 10.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git. from d039b4c Version updates new 37cc27f Revert ECJ update as 4.22 requires Java 11. new 9e3fc44 Fix Java 17 compilation after revert of ECJ update The 2 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.properties.default| 15 +-- java/org/apache/jasper/compiler/JDTCompiler.java| 12 +--- res/ide-support/eclipse/eclipse.classpath | 2 +- res/ide-support/idea/tomcat.iml | 2 +- res/ide-support/netbeans/nb-tomcat-build.properties | 2 +- res/ide-support/netbeans/project.xml| 2 +- res/maven/tomcat-jasper.pom | 2 +- webapps/docs/changelog.xml | 3 --- 8 files changed, 23 insertions(+), 17 deletions(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 02/02: Fix Java 17 compilation after revert of ECJ update
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 9e3fc447ab73303c1b65dfc7f11e8e2f76956441
Author: Mark Thomas
AuthorDate: Mon Jan 3 11:18:47 2022 +
Fix Java 17 compilation after revert of ECJ update
---
java/org/apache/jasper/compiler/JDTCompiler.java | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/java/org/apache/jasper/compiler/JDTCompiler.java
b/java/org/apache/jasper/compiler/JDTCompiler.java
index 69c6e05..2e361f2 100644
--- a/java/org/apache/jasper/compiler/JDTCompiler.java
+++ b/java/org/apache/jasper/compiler/JDTCompiler.java
@@ -312,7 +312,10 @@ public class JDTCompiler extends
org.apache.jasper.compiler.Compiler {
} else if(opt.equals("16")) {
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_16);
} else if(opt.equals("17")) {
-settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_17);
+// Constant not available in latest ECJ version that runs on
+// Java 8.
+// This is checked against the actual version below.
+settings.put(CompilerOptions.OPTION_Source, "17");
} else if (opt.equals("18")) {
// Constant not available in latest ECJ version shipped with
// Tomcat. May be supported in a snapshot build.
@@ -377,8 +380,11 @@ public class JDTCompiler extends
org.apache.jasper.compiler.Compiler {
settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_16);
settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_16);
} else if(opt.equals("17")) {
-settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_17);
-settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_17);
+// Constant not available in latest ECJ version that runs on
+// Java 8.
+// This is checked against the actual version below.
+settings.put(CompilerOptions.OPTION_TargetPlatform, "17");
+settings.put(CompilerOptions.OPTION_Compliance, "17");
} else if (opt.equals("18")) {
// Constant not available in latest ECJ version shipped with
// Tomcat. May be supported in a snapshot build.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 01/02: Revert ECJ update as 4.22 requires Java 11.
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 37cc27f1e8ceaeb298f07cc20722a99f5dd58a81
Author: Mark Thomas
AuthorDate: Mon Jan 3 11:11:53 2022 +
Revert ECJ update as 4.22 requires Java 11.
ECJ 4.20 is the last version that supports Java 8
---
build.properties.default| 15 +--
res/ide-support/eclipse/eclipse.classpath | 2 +-
res/ide-support/idea/tomcat.iml | 2 +-
res/ide-support/netbeans/nb-tomcat-build.properties | 2 +-
res/ide-support/netbeans/project.xml| 2 +-
res/maven/tomcat-jasper.pom | 2 +-
webapps/docs/changelog.xml | 3 ---
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/build.properties.default b/build.properties.default
index fbdb325..109263d 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -137,15 +137,18 @@
wsdl4j-lib.loc=${base-maven.loc}/wsdl4j/wsdl4j/${wsdl4j-lib.version}/wsdl4j-${ws
# - Eclipse JDT, version 4.7 or later -#
# See
https://cwiki.apache.org/confluence/display/TOMCAT/Managing+Tomcat%27s+Dependency+on+the+Eclipse+JDT+Core+Batch+Compiler
#
-# Checksum is from "SHA512 Checksums for 4.22" link at
-# https://download.eclipse.org/eclipse/downloads/drops4/R-4.22-202111241800/
-#
https://download.eclipse.org/eclipse/downloads/drops4/R-4.22-202111241800/checksum/eclipse-4.22-SUMSSHA512
+# 4.20 is the latest release that runs on Java 8
+# Later versions can be used but the official builds need to use 4.20
#
-jdt.version=4.22
-jdt.release=R-4.22-202111241800
+# Checksum is from "SHA512 Checksums for 4.20" link at
+# https://download.eclipse.org/eclipse/downloads/drops4/R-4.20-202106111600/
+#
https://download.eclipse.org/eclipse/downloads/drops4/R-4.20-202106111600/checksum/eclipse-4.20-SUMSSHA512
+#
+jdt.version=4.20
+jdt.release=R-4.20-202106111600
jdt.checksum.enabled=true
jdt.checksum.algorithm=SHA-512
-jdt.checksum.value=a014bbedd96b31576bb2b28ad16ac23edc15b59833ac810409fd42834ac6081b695167903bec0fa98d614031aeb863b3de28697d4636f23b2c47ffd93f443aae
+jdt.checksum.value=ab441acf5551a7dc81c353eaccb3b3df9e89a48987294d19e39acdb83a5b640fcdff7414cee29f5b96eaa8826647f1d5323e185018fe33a64c402d69c73c9158
jdt.home=${base.path}/ecj-${jdt.version}
jdt.jar=${jdt.home}/ecj-${jdt.version}.jar
# The download will be moved to the archive area eventually. We are taking
care of that in advance.
diff --git a/res/ide-support/eclipse/eclipse.classpath
b/res/ide-support/eclipse/eclipse.classpath
index 074a01d..7c33850 100644
--- a/res/ide-support/eclipse/eclipse.classpath
+++ b/res/ide-support/eclipse/eclipse.classpath
@@ -24,7 +24,7 @@
-
+
diff --git a/res/ide-support/idea/tomcat.iml b/res/ide-support/idea/tomcat.iml
index 5be2060..c4dd47b 100644
--- a/res/ide-support/idea/tomcat.iml
+++ b/res/ide-support/idea/tomcat.iml
@@ -68,7 +68,7 @@
-
+
diff --git a/res/ide-support/netbeans/nb-tomcat-build.properties
b/res/ide-support/netbeans/nb-tomcat-build.properties
index c1c5039..65b5205 100644
--- a/res/ide-support/netbeans/nb-tomcat-build.properties
+++ b/res/ide-support/netbeans/nb-tomcat-build.properties
@@ -37,7 +37,7 @@ nb-test.io-method=org.apache.coyote.http11.Http11NioProtocol
# it is not possible to retrieve the classpaths from the build to
# use in the NetBeans targets, so they must be explicitly declared
-nb-test.classpath=${test.classes}:${tomcat.build}/webapps/examples/WEB-INF/classes:${base.path}/junit-4.13/junit-4.13.jar:${base.path}/easymock-4.3/easymock-4.3.jar:${base.path}/objenesis-3.2/objenesis-3.2.jar:${base.path}/cglib-3.3.0/cglib-nodep-3.3.0.jar:${base.path}/hamcrest-2.2/hamcrest-2.2.jar:${base.path}/ecj-4.22/ecj-4.22.jar:${tomcat.classes}
+nb-test.classpath=${test.classes}:${tomcat.build}/webapps/examples/WEB-INF/classes:${base.path}/junit-4.13/junit-4.13.jar:${base.path}/easymock-4.3/easymock-4.3.jar:${base.path}/objenesis-3.2/objenesis-3.2.jar:${base.path}/cglib-3.3.0/cglib-nodep-3.3.0.jar:${base.path}/hamcrest-2.2/hamcrest-2.2.jar:${base.path}/ecj-4.20/ecj-4.20.jar:${tomcat.classes}
# Extra properties used by the Tomcat project additional NetBeans targets.
diff --git a/res/ide-support/netbeans/project.xml
b/res/ide-support/netbeans/project.xml
index 1d3c25b..68a060e 100644
--- a/res/ide-support/netbeans/project.xml
+++ b/res/ide-support/netbeans/project.xml
@@ -178,7 +178,7 @@
-->
java
-${base.path}/jaxrpc-1.1-rc4/geronimo-spec-jaxrpc-1.1-rc4.jar:${base.path}/wsdl4j-1.6.3/wsdl4j-1.6.3.jar:${base.path}/ecj-4.22/ecj-4.22.jar:${base.path}/bnd-6.1.0/biz.aQute.bnd-6.1.0.jar:${base.path}/migration-1.0.0/jakartaee-migration-1.0.0-shaded.jar:${ant.includes
Re: [tomcat] branch 10.0.x updated: Update Eclipse JDT from 4.20 to 4.22
On Mon, Jan 3, 2022 at 11:53 AM Rainer Jung wrote:
>
> For reference: this is probably the ticket about moving JDT (and ECJ) to
> Java 11:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=572389
>
> And this is the parallel mail discussion:
>
> https://www.eclipse.org/lists/eclipse-dev/msg11703.html
>
> If we roll back the change for TC 10.0 and 9, there is also the later
> change about JSP compilation for Java 17/18 that was depeding on the ECJ
> update.
Well, this is a big problem since we plan to support Tomcat 9 for a
very long time and there's now no way to update JDT :(
Any ideas ?
Rémy
> Regards,
>
> Rainer
>
> Am 03.01.2022 um 11:28 schrieb Rainer Jung:
> > It seems JDT 4.22 contains Java 11 compiled classes:
> >
> > compile:
> > ...
> > [javac]
> > /shared/build/dev/tomcat/git/10.0.x/java/org/apache/jasper/compiler/JDTCompiler.java:40:
> > error: cannot access IProblem
> > [javac] import org.eclipse.jdt.core.compiler.IProblem;
> > [javac] ^
> > [javac] bad class file:
> > /path/to/ecj-4.22/ecj-4.22.jar(org/eclipse/jdt/core/compiler/IProblem.class)
> >
> > [javac] class file has wrong version 55.0, should be 52.0
> > [javac] Please remove or make sure it appears in the correct
> > subdirectory of the classpath.
> >
> > Best regards,
> >
> > Rainer
> >
> > Am 02.01.2022 um 17:08 schrieb ma...@apache.org:
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> markt pushed a commit to branch 10.0.x
> >> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >>
> >>
> >> The following commit(s) were added to refs/heads/10.0.x by this push:
> >> new d08f3d9 Update Eclipse JDT from 4.20 to 4.22
> >> d08f3d9 is described below
> >>
> >> commit d08f3d9a3126867cfc787626a2dc0295261016d3
> >> Author: Mark Thomas
> >> AuthorDate: Sun Jan 2 16:02:32 2022 +
> >>
> >> Update Eclipse JDT from 4.20 to 4.22
> >> ---
> >> build.properties.default| 12 ++--
> >> res/ide-support/eclipse/eclipse.classpath | 2 +-
> >> res/ide-support/idea/tomcat.iml | 2 +-
> >> res/ide-support/netbeans/nb-tomcat-build.properties | 2 +-
> >> res/ide-support/netbeans/project.xml| 2 +-
> >> res/maven/tomcat-jasper.pom | 2 +-
> >> webapps/docs/changelog.xml | 3 +++
> >> 7 files changed, 14 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/build.properties.default b/build.properties.default
> >> index 3d55063..60d1598 100644
> >> --- a/build.properties.default
> >> +++ b/build.properties.default
> >> @@ -137,15 +137,15 @@
> >> wsdl4j-lib.loc=${base-maven.loc}/wsdl4j/wsdl4j/${wsdl4j-lib.version}/wsdl4j-${ws
> >>
> >> # - Eclipse JDT, version 4.7 or later -#
> >> # See
> >> https://cwiki.apache.org/confluence/display/TOMCAT/Managing+Tomcat%27s+Dependency+on+the+Eclipse+JDT+Core+Batch+Compiler
> >>
> >> #
> >> -# Checksum is from "SHA512 Checksums for 4.20" link at
> >> -#
> >> https://download.eclipse.org/eclipse/downloads/drops4/R-4.20-202106111600/
> >>
> >> -#
> >> https://download.eclipse.org/eclipse/downloads/drops4/R-4.20-202106111600/checksum/eclipse-4.20-SUMSSHA512
> >>
> >> +# Checksum is from "SHA512 Checksums for 4.22" link at
> >> +#
> >> https://download.eclipse.org/eclipse/downloads/drops4/R-4.22-202111241800/
> >>
> >> +#
> >> https://download.eclipse.org/eclipse/downloads/drops4/R-4.22-202111241800/checksum/eclipse-4.22-SUMSSHA512
> >>
> >> #
> >> -jdt.version=4.20
> >> -jdt.release=R-4.20-202106111600
> >> +jdt.version=4.22
> >> +jdt.release=R-4.22-202111241800
> >> jdt.checksum.enabled=true
> >> jdt.checksum.algorithm=SHA-512
> >> -jdt.checksum.value=ab441acf5551a7dc81c353eaccb3b3df9e89a48987294d19e39acdb83a5b640fcdff7414cee29f5b96eaa8826647f1d5323e185018fe33a64c402d69c73c9158
> >>
> >> +jdt.checksum.value=a014bbedd96b31576bb2b28ad16ac23edc15b59833ac810409fd42834ac6081b695167903bec0fa98d614031aeb863b3de28697d4636f23b2c47ffd93f443aae
> >>
> >> jdt.home=${base.path}/ecj-${jdt.version}
> >> jdt.jar=${jdt.home}/ecj-${jdt.version}.jar
> >> # The download will be moved to the archive area eventually. We are
> >> taking care of that in advance.
> >> diff --git a/res/ide-support/eclipse/eclipse.classpath
> >> b/res/ide-support/eclipse/eclipse.classpath
> >> index cc24716..b081ec5 100644
> >> --- a/res/ide-support/eclipse/eclipse.classpath
> >> +++ b/res/ide-support/eclipse/eclipse.classpath
> >> @@ -24,7 +24,7 @@
> >>
> >>>> path="TOMCAT_LIBS_BASE/jaxrpc-1.1-rc4/geronimo-spec-jaxrpc-1.1-rc4.jar"/>
> >>>> path="TOMCAT_LIBS_BASE/wsdl4j-1.6.3/wsdl4j-1.6.3.jar"/>
> >> - >> path="TOMCAT_LIBS_BASE/ecj-4.20/ecj-4.20.jar"/>
> >> + >> path="TOMCAT_LIBS_BASE/ecj-4.22/ecj-4.22.jar"/>
> >>>> path="TOMCAT_LIBS_BASE/easymock-4.3/easymock-4.3.jar"/>
> >>>> path="TOMCAT_LIBS_BASE/hamcrest-2.2/h
[tomcat] branch 9.0.x updated (4da1ceb -> ea57ae9)
This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch 9.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git. from 4da1ceb Version updates new 0017e33 Revert ECJ update as 4.22 requires Java 11. new ea57ae9 Fix Java 17 compilation after revert of ECJ update The 2 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.properties.default| 15 +-- java/org/apache/jasper/compiler/JDTCompiler.java| 12 +--- res/ide-support/eclipse/eclipse.classpath | 2 +- res/ide-support/idea/tomcat.iml | 2 +- res/ide-support/netbeans/nb-tomcat-build.properties | 2 +- res/ide-support/netbeans/project.xml| 2 +- res/maven/tomcat-jasper.pom | 2 +- webapps/docs/changelog.xml | 3 --- 8 files changed, 23 insertions(+), 17 deletions(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 02/02: Fix Java 17 compilation after revert of ECJ update
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
commit ea57ae94edfd12319a4bf8f88d38bb0f469a7d07
Author: Mark Thomas
AuthorDate: Mon Jan 3 11:23:34 2022 +
Fix Java 17 compilation after revert of ECJ update
---
java/org/apache/jasper/compiler/JDTCompiler.java | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/java/org/apache/jasper/compiler/JDTCompiler.java
b/java/org/apache/jasper/compiler/JDTCompiler.java
index 69c6e05..2e361f2 100644
--- a/java/org/apache/jasper/compiler/JDTCompiler.java
+++ b/java/org/apache/jasper/compiler/JDTCompiler.java
@@ -312,7 +312,10 @@ public class JDTCompiler extends
org.apache.jasper.compiler.Compiler {
} else if(opt.equals("16")) {
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_16);
} else if(opt.equals("17")) {
-settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_17);
+// Constant not available in latest ECJ version that runs on
+// Java 8.
+// This is checked against the actual version below.
+settings.put(CompilerOptions.OPTION_Source, "17");
} else if (opt.equals("18")) {
// Constant not available in latest ECJ version shipped with
// Tomcat. May be supported in a snapshot build.
@@ -377,8 +380,11 @@ public class JDTCompiler extends
org.apache.jasper.compiler.Compiler {
settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_16);
settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_16);
} else if(opt.equals("17")) {
-settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_17);
-settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_17);
+// Constant not available in latest ECJ version that runs on
+// Java 8.
+// This is checked against the actual version below.
+settings.put(CompilerOptions.OPTION_TargetPlatform, "17");
+settings.put(CompilerOptions.OPTION_Compliance, "17");
} else if (opt.equals("18")) {
// Constant not available in latest ECJ version shipped with
// Tomcat. May be supported in a snapshot build.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 01/02: Revert ECJ update as 4.22 requires Java 11.
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
commit 0017e3331636773418083a98767a7259e22394a0
Author: Mark Thomas
AuthorDate: Mon Jan 3 11:20:52 2022 +
Revert ECJ update as 4.22 requires Java 11.
ECJ 4.20 is the last version that supports Java 8
---
build.properties.default| 15 +--
res/ide-support/eclipse/eclipse.classpath | 2 +-
res/ide-support/idea/tomcat.iml | 2 +-
res/ide-support/netbeans/nb-tomcat-build.properties | 2 +-
res/ide-support/netbeans/project.xml| 2 +-
res/maven/tomcat-jasper.pom | 2 +-
webapps/docs/changelog.xml | 3 ---
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/build.properties.default b/build.properties.default
index 150ebbc..5229029 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -137,15 +137,18 @@
wsdl4j-lib.loc=${base-maven.loc}/wsdl4j/wsdl4j/${wsdl4j-lib.version}/wsdl4j-${ws
# - Eclipse JDT, version 4.7 or later -#
# See
https://cwiki.apache.org/confluence/display/TOMCAT/Managing+Tomcat%27s+Dependency+on+the+Eclipse+JDT+Core+Batch+Compiler
#
-# Checksum is from "SHA512 Checksums for 4.22" link at
-# https://download.eclipse.org/eclipse/downloads/drops4/R-4.22-202111241800/
-#
https://download.eclipse.org/eclipse/downloads/drops4/R-4.22-202111241800/checksum/eclipse-4.22-SUMSSHA512
+# 4.20 is the latest release that runs on Java 8
+# Later versions can be used but the official builds need to use 4.20
#
-jdt.version=4.22
-jdt.release=R-4.22-202111241800
+# Checksum is from "SHA512 Checksums for 4.20" link at
+# https://download.eclipse.org/eclipse/downloads/drops4/R-4.20-202106111600/
+#
https://download.eclipse.org/eclipse/downloads/drops4/R-4.20-202106111600/checksum/eclipse-4.20-SUMSSHA512
+#
+jdt.version=4.20
+jdt.release=R-4.20-202106111600
jdt.checksum.enabled=true
jdt.checksum.algorithm=SHA-512
-jdt.checksum.value=a014bbedd96b31576bb2b28ad16ac23edc15b59833ac810409fd42834ac6081b695167903bec0fa98d614031aeb863b3de28697d4636f23b2c47ffd93f443aae
+jdt.checksum.value=ab441acf5551a7dc81c353eaccb3b3df9e89a48987294d19e39acdb83a5b640fcdff7414cee29f5b96eaa8826647f1d5323e185018fe33a64c402d69c73c9158
jdt.home=${base.path}/ecj-${jdt.version}
jdt.jar=${jdt.home}/ecj-${jdt.version}.jar
# The download will be moved to the archive area eventually. We are taking
care of that in advance.
diff --git a/res/ide-support/eclipse/eclipse.classpath
b/res/ide-support/eclipse/eclipse.classpath
index c9557cc..e690a8e 100644
--- a/res/ide-support/eclipse/eclipse.classpath
+++ b/res/ide-support/eclipse/eclipse.classpath
@@ -24,7 +24,7 @@
-
+
diff --git a/res/ide-support/idea/tomcat.iml b/res/ide-support/idea/tomcat.iml
index 5910f1d..a4268e6 100644
--- a/res/ide-support/idea/tomcat.iml
+++ b/res/ide-support/idea/tomcat.iml
@@ -68,7 +68,7 @@
-
+
diff --git a/res/ide-support/netbeans/nb-tomcat-build.properties
b/res/ide-support/netbeans/nb-tomcat-build.properties
index c1c5039..65b5205 100644
--- a/res/ide-support/netbeans/nb-tomcat-build.properties
+++ b/res/ide-support/netbeans/nb-tomcat-build.properties
@@ -37,7 +37,7 @@ nb-test.io-method=org.apache.coyote.http11.Http11NioProtocol
# it is not possible to retrieve the classpaths from the build to
# use in the NetBeans targets, so they must be explicitly declared
-nb-test.classpath=${test.classes}:${tomcat.build}/webapps/examples/WEB-INF/classes:${base.path}/junit-4.13/junit-4.13.jar:${base.path}/easymock-4.3/easymock-4.3.jar:${base.path}/objenesis-3.2/objenesis-3.2.jar:${base.path}/cglib-3.3.0/cglib-nodep-3.3.0.jar:${base.path}/hamcrest-2.2/hamcrest-2.2.jar:${base.path}/ecj-4.22/ecj-4.22.jar:${tomcat.classes}
+nb-test.classpath=${test.classes}:${tomcat.build}/webapps/examples/WEB-INF/classes:${base.path}/junit-4.13/junit-4.13.jar:${base.path}/easymock-4.3/easymock-4.3.jar:${base.path}/objenesis-3.2/objenesis-3.2.jar:${base.path}/cglib-3.3.0/cglib-nodep-3.3.0.jar:${base.path}/hamcrest-2.2/hamcrest-2.2.jar:${base.path}/ecj-4.20/ecj-4.20.jar:${tomcat.classes}
# Extra properties used by the Tomcat project additional NetBeans targets.
diff --git a/res/ide-support/netbeans/project.xml
b/res/ide-support/netbeans/project.xml
index d4737f8..acb514a 100644
--- a/res/ide-support/netbeans/project.xml
+++ b/res/ide-support/netbeans/project.xml
@@ -178,7 +178,7 @@
-->
java
-${base.path}/jaxrpc-1.1-rc4/geronimo-spec-jaxrpc-1.1-rc4.jar:${base.path}/wsdl4j-1.6.3/wsdl4j-1.6.3.jar:${base.path}/ecj-4.22/ecj-4.22.jar:${base.path}/bnd-6.1.0/biz.aQute.bnd-6.1.0.jar:${ant.includes}/
+${base.path}/jaxrpc-1.1-rc4/geronimo-spec-jaxrp
Re: [tomcat] branch 10.0.x updated: Update Eclipse JDT from 4.20 to 4.22
On 03/01/2022 11:20, Rémy Maucherat wrote: On Mon, Jan 3, 2022 at 11:53 AM Rainer Jung wrote: For reference: this is probably the ticket about moving JDT (and ECJ) to Java 11: https://bugs.eclipse.org/bugs/show_bug.cgi?id=572389 And this is the parallel mail discussion: https://www.eclipse.org/lists/eclipse-dev/msg11703.html If we roll back the change for TC 10.0 and 9, there is also the later change about JSP compilation for Java 17/18 that was depeding on the ECJ update. Well, this is a big problem since we plan to support Tomcat 9 for a very long time and there's now no way to update JDT :( Any ideas ? I think we have options. JDT bugs that affect JSP compilation are rare as are security bugs. On that basis, the likelihood of an update being required is low. Tomcat 8.5.x has been stuck on ECJ 4.6.3 (last Java 7 version) since 2017 and that hasn't been an issue so far. I don't think we have said Tomcat 9.10.x etc will continue to have Java 8 as a minimum. It is the Java EE 8 API we are looking to retain and while java EE 8 does specify Java 8 as a minimum I think we have a case - in terms of extended support - to update that if we need a newer version of Java in order to update a dependency we need to update. Users always have the option of replacing the ECJ JAR that ships with Tomcat with a new (or older) version. Whatever we decide to do as the default, users will always have the option to use a different ECJ JAR. Actually, using an older version might be tricky as we use the newer constants but if we keep that in mind for 9.10.x onwards we could ship with a newer ECJ and leave the option open for users to downgrade. Sort of related, I am wondering about the build environment. We have seen an issue with downstream building with Java 11 and there are difficulties building 8.5.x particularly with a clean install of the latest publicly available Java 7. What about switching all versions to building with Java 11 and using the release compilation option to set the appropriate Java API to build against? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Deadlock in unit tests for TC 8.5.73 on Solaris using zulu 1.8.0_312-b07
On 03/01/2022 11:17, Rainer Jung wrote:
Thanks Marc.
In the meantime, I can also say, that it happens for TC 8.5 using JSSE
or OpenSSL and NIO or NIO2. I did not try APR.
Unfortunately I can still reproduce on TC 8.5 even without the sync
patch you mentioned below.
Drat. Can you post the stack trace for the deadlock you see in that
case? Just to save me trying to recreate it.
Thanks,
Mark
The code currently under test has:
diff --git a/java/org/apache/coyote/http2/Stream.java
b/java/org/apache/coyote/http2/Stream.java
index fffd2403e8..196cd5b85c 100644
--- a/java/org/apache/coyote/http2/Stream.java
+++ b/java/org/apache/coyote/http2/Stream.java
@@ -614,14 +614,8 @@ class Stream extends AbstractNonZeroStream
implements HeaderEmitter {
log.debug(sm.getString("stream.reset.send",
getConnectionId(), getIdAsString(),
se.getError()));
}
- // Sync ensures that if the call to sendReset()
triggers resets
- // in other threads, that the RST frame associated with
this
- // thread is sent before the RST frames associated with
those
- // threads.
- synchronized (state) {
- state.sendReset();
- handler.sendStreamReset(se);
- }
+ state.sendReset();
+ handler.sendStreamReset(se);
cancelAllocationRequests();
if (inputBuffer != null) {
inputBuffer.swallowUnread();
But: For TC 10.0 I could not reproduce as easily, even not with the
original sync code in place. I stopped after 20 attempts without
deadlock, but will try longer for TC 10 and also TC 9 later today.
Thanks and regards,
Rainer
Am 03.01.2022 um 11:55 schrieb Mark Thomas:
On 03/01/2022 09:45, Mark Thomas wrote:
Hi Rainer,
Thanks for finding this. It isn't something I have seen in my
testing. I think this is something that needs to be fixed before the
January set of releases.
From the stack trace, it looks like the root cause is locks being
obtained in an inconsistent order - a classic deadlock.
I haven't looked at the code or the history yet so I am not sure if
this is the direct result of a recent change or if another change has
just made this easier to trigger. I plan to look at this today.
This change and the back-ports appear to be the trigger for this
deadlock:
https://github.com/apache/tomcat/commit/5782322afd31adf98b72288f99965c6811dcdcdd
Mark
Mark
On 01/01/2022 19:07, Rainer Jung wrote:
Hi hi,
I am running the unit tests for TC 8.5.73 plus few post-release
patches on Solaris 10 Sparc with various Java 8 JVMs. I noticed one
deadlock when running on Zulu 8.58.0.13-CA-solaris (build
1.8.0_312-b07). Maybe it is a sporadic deadlock and could also
happen on the 1.8.0 variations, but I could not yet check that. I
did not notice such a deadlock on 5 Linux distributions on which I
also ran all unit tests with a variety of JVMs, including the Zulu one.
Due to the logs the deadlock happens in
org.apache.coyote.http2.TestCancelledUpload, but
org.apache.coyote.http2.TestFlowControl runs concurrently at the
same time (zwo test threads). Test methods are testCancelledRequest
rwsp. testNotFound.
The stacks are:
Found one Java-level deadlock:
=
"http-nio-127.0.0.1-auto-1-exec-7":
waiting to lock monitor 0x000100f99508 (object
0x41a99b40, a org.apache.coyote.http2.StreamStateMachine),
which is held by "http-nio-127.0.0.1-auto-1-exec-5"
"http-nio-127.0.0.1-auto-1-exec-5":
waiting to lock monitor 0x0001002da838 (object
0x42015548, a
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper),
which is held by "http-nio-127.0.0.1-auto-1-exec-7"
Java stack information for the threads listed above:
===
"http-nio-127.0.0.1-auto-1-exec-7":
at
org.apache.coyote.http2.StreamStateMachine.checkFrameType(StreamStateMachine.java:125)
- waiting to lock <0x41a99b40> (a
org.apache.coyote.http2.StreamStateMachine)
at
org.apache.coyote.http2.AbstractNonZeroStream.checkState(AbstractNonZeroStream.java:144)
at
org.apache.coyote.http2.Http2UpgradeHandler.startRequestBodyFrame(Http2UpgradeHandler.java:1641)
at
org.apache.coyote.http2.Http2Parser.readDataFrame(Http2Parser.java:168)
at
org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:95)
at
org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:69)
at
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:340)
at
org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:60)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:59)
at
or
Re: Deadlock in unit tests for TC 8.5.73 on Solaris using zulu 1.8.0_312-b07
Am 03.01.2022 um 12:33 schrieb Mark Thomas: On 03/01/2022 11:17, Rainer Jung wrote: Thanks Marc. In the meantime, I can also say, that it happens for TC 8.5 using JSSE or OpenSSL and NIO or NIO2. I did not try APR. Unfortunately I can still reproduce on TC 8.5 even without the sync patch you mentioned below. Drat. Can you post the stack trace for the deadlock you see in that case? Just to save me trying to recreate it. Thanks, Mark Double checking revealed: although I did compile the new class the test ran with the unpatched one, line numbers in the stacks showed line 621 which is the synchronized line in the original Stream.java. Sorry for the confiusion. So you asuumption is confirmed, that that change triggers it. Will try with TC 9 original head code next. Thanks and regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Deadlock in unit tests for TC 8.5.73 on Solaris using zulu 1.8.0_312-b07
On 03/01/2022 13:05, Rainer Jung wrote:
Am 03.01.2022 um 12:33 schrieb Mark Thomas:
On 03/01/2022 11:17, Rainer Jung wrote:
Thanks Marc.
In the meantime, I can also say, that it happens for TC 8.5 using
JSSE or OpenSSL and NIO or NIO2. I did not try APR.
Unfortunately I can still reproduce on TC 8.5 even without the sync
patch you mentioned below.
Drat. Can you post the stack trace for the deadlock you see in that
case? Just to save me trying to recreate it.
Thanks,
Mark
Double checking revealed: although I did compile the new class the test
ran with the unpatched one, line numbers in the stacks showed line 621
which is the synchronized line in the original Stream.java. Sorry for
the confiusion. So you asuumption is confirmed, that that change
triggers it.
Good news. Thanks for the update.
Will try with TC 9 original head code next.
I think you'll need to run with useAsyncIO="false" to be able to trigger
this on 9.0.x.
I can reproduce this with a debugger on 8.5.x and I think I have a
possible fix. If you replace:
synchronized (state) { ...
with
synchronized (this) { ...
can you still trigger the deadlock on 8.5.x?
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Deadlock in unit tests for TC 8.5.73 on Solaris using zulu 1.8.0_312-b07
Am 03.01.2022 um 15:00 schrieb Mark Thomas:
On 03/01/2022 13:05, Rainer Jung wrote:
Am 03.01.2022 um 12:33 schrieb Mark Thomas:
On 03/01/2022 11:17, Rainer Jung wrote:
Thanks Marc.
In the meantime, I can also say, that it happens for TC 8.5 using
JSSE or OpenSSL and NIO or NIO2. I did not try APR.
Unfortunately I can still reproduce on TC 8.5 even without the sync
patch you mentioned below.
Drat. Can you post the stack trace for the deadlock you see in that
case? Just to save me trying to recreate it.
Thanks,
Mark
Double checking revealed: although I did compile the new class the
test ran with the unpatched one, line numbers in the stacks showed
line 621 which is the synchronized line in the original Stream.java.
Sorry for the confiusion. So you asuumption is confirmed, that that
change triggers it.
Good news. Thanks for the update.
Will try with TC 9 original head code next.
I think you'll need to run with useAsyncIO="false" to be able to trigger
this on 9.0.x.
I can reproduce this with a debugger on 8.5.x and I think I have a
possible fix. If you replace:
synchronized (state) { ...
with
synchronized (this) { ...
can you still trigger the deadlock on 8.5.x?
Mark
Unfortunately it seems the deadlock has just moved:
Found one Java-level deadlock:
=
"http-nio-127.0.0.1-auto-1-exec-6":
waiting to lock monitor 0x000100d2f5e8 (object
0x41f8a898, a
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper),
which is held by "http-nio-127.0.0.1-auto-1-exec-4"
"http-nio-127.0.0.1-auto-1-exec-4":
waiting to lock monitor 0x000100d31e78 (object
0x41b11e48, a org.apache.coyote.http2.Stream),
which is held by "http-nio-127.0.0.1-auto-1-exec-6"
Java stack information for the threads listed above:
===
"http-nio-127.0.0.1-auto-1-exec-6":
at
org.apache.coyote.http2.Http2UpgradeHandler.sendStreamReset(Http2UpgradeHandler.java:558)
- waiting to lock <0x41f8a898> (a
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper)
at org.apache.coyote.http2.Stream.close(Stream.java:623)
- locked <0x41b11e48> (a org.apache.coyote.http2.Stream)
at
org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:85)
- locked <0x41b3c008> (a
org.apache.coyote.http2.StreamProcessor)
at
org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
"http-nio-127.0.0.1-auto-1-exec-4":
at org.apache.coyote.http2.Stream.close(Stream.java:622)
- waiting to lock <0x41b11e48> (a
org.apache.coyote.http2.Stream)
at
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:350)
at
org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:60)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:59)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:849)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1677)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
- locked <0x41f8a898> (a
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
Found 1 deadlock.
My current Stream.java looks like this:
617 // Sync ensures that if the call to sendReset()
triggers resets
618 // in other threads, that the RST frame associated
with this
619 // thread is sent before the RST frames associated
with those
620 // threads.
621 synchronized (this) {
622 state.sendReset();
623 handler.sendStreamReset(se);
624 }
625 cancelAllocationRequests();
626 if (inputBuffer != null) {
627 inputBuffer.swallowUnread();
628 }
% git diff
diff --git a/java/org/apache/coyote/http2/Stream.java
b/java/org/apache/coyote/http2/Stream.java
index fffd2403e8..16a64bd6c5 100644
--- a/java/org/apache/coyote/http2/Stream.java
+++ b/java/org/apache/coyote/http2/Str
Re: Deadlock in unit tests for TC 8.5.73 on Solaris using zulu 1.8.0_312-b07
On 03/01/2022 14:20, Rainer Jung wrote: Unfortunately it seems the deadlock has just moved: Thanks for the quick turn-around. I'll continue looking for a fix for this. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: BZ65757: Fix forgotten test case
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 e2c2d39 BZ65757: Fix forgotten test case
e2c2d39 is described below
commit e2c2d39ba7fc232badecb9e4d4ca252b780419ab
Author: remm
AuthorDate: Mon Jan 3 16:05:22 2022 +0100
BZ65757: Fix forgotten test case
Dispaching in the servlet container when using non blocking IO needs
better thread identification. Otherwise, the container could see a
container thread and believe it doesn't need an explicit notification,
while actually the thread was simply running another request (so no
async post process).
---
java/org/apache/catalina/connector/CoyoteAdapter.java| 2 ++
java/org/apache/catalina/connector/InputBuffer.java | 3 +--
java/org/apache/coyote/Request.java | 16 +++-
java/org/apache/coyote/Response.java | 2 +-
.../apache/catalina/nonblocking/TestNonBlockingAPI.java | 4 +---
5 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/java/org/apache/catalina/connector/CoyoteAdapter.java
b/java/org/apache/catalina/connector/CoyoteAdapter.java
index 771cc50..50cb5a6 100644
--- a/java/org/apache/catalina/connector/CoyoteAdapter.java
+++ b/java/org/apache/catalina/connector/CoyoteAdapter.java
@@ -130,6 +130,7 @@ public class CoyoteAdapter implements Adapter {
AsyncContextImpl asyncConImpl = request.getAsyncContextInternal();
req.getRequestProcessor().setWorkerThreadName(THREAD_NAME.get());
+req.setRequestThread();
try {
if (!request.isAsync()) {
@@ -341,6 +342,7 @@ public class CoyoteAdapter implements Adapter {
boolean postParseSuccess = false;
req.getRequestProcessor().setWorkerThreadName(THREAD_NAME.get());
+req.setRequestThread();
try {
// Parse and set Catalina and configuration specific
diff --git a/java/org/apache/catalina/connector/InputBuffer.java
b/java/org/apache/catalina/connector/InputBuffer.java
index de306f5..ac1b816 100644
--- a/java/org/apache/catalina/connector/InputBuffer.java
+++ b/java/org/apache/catalina/connector/InputBuffer.java
@@ -32,7 +32,6 @@ import jakarta.servlet.ReadListener;
import org.apache.catalina.security.SecurityUtil;
import org.apache.coyote.ActionCode;
-import org.apache.coyote.ContainerThreadMarker;
import org.apache.coyote.Request;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
@@ -266,7 +265,7 @@ public class InputBuffer extends Reader
// If this is a non-container thread, need to trigger a read
// which will eventually lead to a call to onAllDataRead() via a
// container thread.
-if (!ContainerThreadMarker.isContainerThread()) {
+if (!coyoteRequest.isRequestThread()) {
coyoteRequest.action(ActionCode.DISPATCH_READ, null);
coyoteRequest.action(ActionCode.DISPATCH_EXECUTE, null);
}
diff --git a/java/org/apache/coyote/Request.java
b/java/org/apache/coyote/Request.java
index 08dc535..0cb4dbe 100644
--- a/java/org/apache/coyote/Request.java
+++ b/java/org/apache/coyote/Request.java
@@ -172,6 +172,7 @@ public final class Request {
private long bytesRead=0;
// Time of the request - useful to avoid repeated calls to
System.currentTime
private long startTimeNanos = -1;
+private long threadId = 0;
private int available = 0;
private final RequestInfo reqProcessorMX=new RequestInfo(this);
@@ -238,7 +239,7 @@ public final class Request {
fireListener = true;
}
action(ActionCode.DISPATCH_READ, null);
-if (!ContainerThreadMarker.isContainerThread()) {
+if (!isRequestThread()) {
// Not on a container thread so need to execute the dispatch
action(ActionCode.DISPATCH_EXECUTE, null);
}
@@ -737,6 +738,18 @@ public final class Request {
this.startTimeNanos = startTimeNanos;
}
+public long getThreadId() {
+return threadId;
+}
+
+public void setRequestThread() {
+threadId = Thread.currentThread().getId();
+}
+
+public boolean isRequestThread() {
+return Thread.currentThread().getId() == threadId;
+}
+
// Per-Request "notes"
@@ -828,6 +841,7 @@ public final class Request {
allDataReadEventSent.set(false);
startTimeNanos = -1;
+threadId = 0;
}
// Info
diff --git a/java/org/apache/coyote/Response.java
b/java/org/apache/coyote/Response.java
index 604415a..388ac64 100644
--- a/java/org/apache/coyote/Response.java
+++ b/java/org/apache/coyote/Response.java
@@ -737,
[tomcat] branch main updated: Changelog for 65757
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 d34f930 Changelog for 65757 d34f930 is described below commit d34f930800104bca336fd19b950e334fd90f3866 Author: remm AuthorDate: Mon Jan 3 16:13:18 2022 +0100 Changelog for 65757 --- webapps/docs/changelog.xml | 4 1 file changed, 4 insertions(+) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index 7795f68..e1b858d 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -137,6 +137,10 @@ Allow freeing up context on JVM shutdown in the OpenSSL Panama module by properly using a shared scope. (remm) + +65757: Missing initial IO listener notification on Servlet + container dispatch to another container thread. (remm) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #5 from Christopher Schultz --- (In reply to Michael Osipov from comment #4) > Why is it not possible to use the background process to > detect mtime change of cert/private key and initiate a connector reload? It is possible. It's best done using a Listener (or maybe a Valve?) with a background process. Another option would be to use Romain Manni-Bucau's complete ACME component within Tomcat. It handles the whole ACME process, including reloading the connector as necessary. The OP recommends using a package that is limited (APR only), fragile (custom non-daemon watcher thread, suspicious call behavior, and (IMHO) unnecessary. -- 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 10.0.x updated: BZ65757: Fix forgotten test case
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.0.x by this push:
new 2269c82 BZ65757: Fix forgotten test case
2269c82 is described below
commit 2269c8243eb971cd33ea1af1adf3904aaf9f1803
Author: remm
AuthorDate: Mon Jan 3 16:05:22 2022 +0100
BZ65757: Fix forgotten test case
Dispaching in the servlet container when using non blocking IO needs
better thread identification. Otherwise, the container could see a
container thread and believe it doesn't need an explicit notification,
while actually the thread was simply running another request (so no
async post process).
---
java/org/apache/catalina/connector/CoyoteAdapter.java| 2 ++
java/org/apache/catalina/connector/InputBuffer.java | 3 +--
java/org/apache/coyote/Request.java | 16 +++-
java/org/apache/coyote/Response.java | 2 +-
.../apache/catalina/nonblocking/TestNonBlockingAPI.java | 4 +---
5 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/java/org/apache/catalina/connector/CoyoteAdapter.java
b/java/org/apache/catalina/connector/CoyoteAdapter.java
index ea3dbe4..3d9b52e 100644
--- a/java/org/apache/catalina/connector/CoyoteAdapter.java
+++ b/java/org/apache/catalina/connector/CoyoteAdapter.java
@@ -129,6 +129,7 @@ public class CoyoteAdapter implements Adapter {
AsyncContextImpl asyncConImpl = request.getAsyncContextInternal();
req.getRequestProcessor().setWorkerThreadName(THREAD_NAME.get());
+req.setRequestThread();
try {
if (!request.isAsync()) {
@@ -340,6 +341,7 @@ public class CoyoteAdapter implements Adapter {
boolean postParseSuccess = false;
req.getRequestProcessor().setWorkerThreadName(THREAD_NAME.get());
+req.setRequestThread();
try {
// Parse and set Catalina and configuration specific
diff --git a/java/org/apache/catalina/connector/InputBuffer.java
b/java/org/apache/catalina/connector/InputBuffer.java
index de306f5..ac1b816 100644
--- a/java/org/apache/catalina/connector/InputBuffer.java
+++ b/java/org/apache/catalina/connector/InputBuffer.java
@@ -32,7 +32,6 @@ import jakarta.servlet.ReadListener;
import org.apache.catalina.security.SecurityUtil;
import org.apache.coyote.ActionCode;
-import org.apache.coyote.ContainerThreadMarker;
import org.apache.coyote.Request;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
@@ -266,7 +265,7 @@ public class InputBuffer extends Reader
// If this is a non-container thread, need to trigger a read
// which will eventually lead to a call to onAllDataRead() via a
// container thread.
-if (!ContainerThreadMarker.isContainerThread()) {
+if (!coyoteRequest.isRequestThread()) {
coyoteRequest.action(ActionCode.DISPATCH_READ, null);
coyoteRequest.action(ActionCode.DISPATCH_EXECUTE, null);
}
diff --git a/java/org/apache/coyote/Request.java
b/java/org/apache/coyote/Request.java
index 157a989..c798199 100644
--- a/java/org/apache/coyote/Request.java
+++ b/java/org/apache/coyote/Request.java
@@ -155,6 +155,7 @@ public final class Request {
private long bytesRead=0;
// Time of the request - useful to avoid repeated calls to
System.currentTime
private long startTimeNanos = -1;
+private long threadId = 0;
private int available = 0;
private final RequestInfo reqProcessorMX=new RequestInfo(this);
@@ -221,7 +222,7 @@ public final class Request {
fireListener = true;
}
action(ActionCode.DISPATCH_READ, null);
-if (!ContainerThreadMarker.isContainerThread()) {
+if (!isRequestThread()) {
// Not on a container thread so need to execute the dispatch
action(ActionCode.DISPATCH_EXECUTE, null);
}
@@ -701,6 +702,18 @@ public final class Request {
this.startTimeNanos = startTimeNanos;
}
+public long getThreadId() {
+return threadId;
+}
+
+public void setRequestThread() {
+threadId = Thread.currentThread().getId();
+}
+
+public boolean isRequestThread() {
+return Thread.currentThread().getId() == threadId;
+}
+
// Per-Request "notes"
@@ -784,6 +797,7 @@ public final class Request {
allDataReadEventSent.set(false);
startTimeNanos = -1;
+threadId = 0;
}
// Info
diff --git a/java/org/apache/coyote/Response.java
b/java/org/apache/coyote/Response.java
index 604415a..388ac64 100644
--- a/java/org/apache/coyote/Response.java
+++ b/java/org/apache/coyote/Response.java
@@ -
[tomcat] branch 10.0.x updated: Changelog for 65757
This is an automated email from the ASF dual-hosted git repository. remm pushed a commit to branch 10.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/10.0.x by this push: new bbd7ebf Changelog for 65757 bbd7ebf is described below commit bbd7ebf3ae38c6b0e0cdad8902a04a723e22149a Author: remm AuthorDate: Mon Jan 3 16:29:56 2022 +0100 Changelog for 65757 --- webapps/docs/changelog.xml | 4 1 file changed, 4 insertions(+) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index 025e060..9f87ce2 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -128,6 +128,10 @@ Revert the previous fix for 65714 and implement a more comprehensive fix. (markt) + +65757: Missing initial IO listener notification on Servlet + container dispatch to another container thread. (remm) + - 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: BZ65757: Fix forgotten test case
This is an automated email from the ASF dual-hosted git repository.
remm 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 915c2d9 BZ65757: Fix forgotten test case
915c2d9 is described below
commit 915c2d97cf366300d8a7175b6ec529426029f83e
Author: remm
AuthorDate: Mon Jan 3 16:05:22 2022 +0100
BZ65757: Fix forgotten test case
Dispaching in the servlet container when using non blocking IO needs
better thread identification. Otherwise, the container could see a
container thread and believe it doesn't need an explicit notification,
while actually the thread was simply running another request (so no
async post process).
---
java/org/apache/catalina/connector/CoyoteAdapter.java| 2 ++
java/org/apache/catalina/connector/InputBuffer.java | 3 +--
java/org/apache/coyote/Request.java | 16 +++-
java/org/apache/coyote/Response.java | 2 +-
.../apache/catalina/nonblocking/TestNonBlockingAPI.java | 4 +---
webapps/docs/changelog.xml | 4
6 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/java/org/apache/catalina/connector/CoyoteAdapter.java
b/java/org/apache/catalina/connector/CoyoteAdapter.java
index 71ff866..2e8a4d5 100644
--- a/java/org/apache/catalina/connector/CoyoteAdapter.java
+++ b/java/org/apache/catalina/connector/CoyoteAdapter.java
@@ -133,6 +133,7 @@ public class CoyoteAdapter implements Adapter {
AsyncContextImpl asyncConImpl = request.getAsyncContextInternal();
req.getRequestProcessor().setWorkerThreadName(THREAD_NAME.get());
+req.setRequestThread();
try {
if (!request.isAsync()) {
@@ -344,6 +345,7 @@ public class CoyoteAdapter implements Adapter {
boolean postParseSuccess = false;
req.getRequestProcessor().setWorkerThreadName(THREAD_NAME.get());
+req.setRequestThread();
try {
// Parse and set Catalina and configuration specific
diff --git a/java/org/apache/catalina/connector/InputBuffer.java
b/java/org/apache/catalina/connector/InputBuffer.java
index a69effd..2488bd6 100644
--- a/java/org/apache/catalina/connector/InputBuffer.java
+++ b/java/org/apache/catalina/connector/InputBuffer.java
@@ -32,7 +32,6 @@ import javax.servlet.ReadListener;
import org.apache.catalina.security.SecurityUtil;
import org.apache.coyote.ActionCode;
-import org.apache.coyote.ContainerThreadMarker;
import org.apache.coyote.Request;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
@@ -266,7 +265,7 @@ public class InputBuffer extends Reader
// If this is a non-container thread, need to trigger a read
// which will eventually lead to a call to onAllDataRead() via a
// container thread.
-if (!ContainerThreadMarker.isContainerThread()) {
+if (!coyoteRequest.isRequestThread()) {
coyoteRequest.action(ActionCode.DISPATCH_READ, null);
coyoteRequest.action(ActionCode.DISPATCH_EXECUTE, null);
}
diff --git a/java/org/apache/coyote/Request.java
b/java/org/apache/coyote/Request.java
index 328cb03..a07d485 100644
--- a/java/org/apache/coyote/Request.java
+++ b/java/org/apache/coyote/Request.java
@@ -154,6 +154,7 @@ public final class Request {
private long bytesRead=0;
// Time of the request - useful to avoid repeated calls to
System.currentTime
private long startTime = -1;
+private long threadId = 0;
private int available = 0;
private final RequestInfo reqProcessorMX=new RequestInfo(this);
@@ -220,7 +221,7 @@ public final class Request {
fireListener = true;
}
action(ActionCode.DISPATCH_READ, null);
-if (!ContainerThreadMarker.isContainerThread()) {
+if (!isRequestThread()) {
// Not on a container thread so need to execute the dispatch
action(ActionCode.DISPATCH_EXECUTE, null);
}
@@ -687,6 +688,18 @@ public final class Request {
this.startTime = startTime;
}
+public long getThreadId() {
+return threadId;
+}
+
+public void setRequestThread() {
+threadId = Thread.currentThread().getId();
+}
+
+public boolean isRequestThread() {
+return Thread.currentThread().getId() == threadId;
+}
+
// Per-Request "notes"
@@ -770,6 +783,7 @@ public final class Request {
allDataReadEventSent.set(false);
startTime = -1;
+threadId = 0;
}
// Info
diff --git a/java/org/apache/coyote/Response.java
b/java/org/apache/coyote/Response.java
index 26870ef..be187ec 100644
--- a/java/org/apache/coyote/Response.java
+++
[Bug 65780] CoyoteOutputStream should never throw NullPointerException after AsyncContext.complete() is called
https://bz.apache.org/bugzilla/show_bug.cgi?id=65780 --- Comment #2 from Dapeng Zhang --- A stacktrace is the following: SEVERE: Exception while executing runnable io.grpc.internal.ServerImpl$JumpToApplicationThreadServerStreamListener$1HalfClosed@77087c61 java.lang.NullPointerException at org.apache.catalina.connector.CoyoteOutputStream.isReady(CoyoteOutputStream.java:162) at io.grpc.servlet.AsyncServletOutputStreamWriter.runOrBuffer(AsyncServletOutputStreamWriter.java:186) at io.grpc.servlet.AsyncServletOutputStreamWriter.complete(AsyncServletOutputStreamWriter.java:129) at io.grpc.servlet.ServletServerStream$Sink.writeTrailers(ServletServerStream.java:290) at io.grpc.internal.AbstractServerStream.close(AbstractServerStream.java:126) at io.grpc.internal.ServerCallImpl.closeInternal(ServerCallImpl.java:223) at io.grpc.internal.ServerCallImpl.close(ServerCallImpl.java:207) at io.grpc.PartialForwardingServerCall.close(PartialForwardingServerCall.java:48) at io.grpc.ForwardingServerCall.close(ForwardingServerCall.java:22) at io.grpc.ForwardingServerCall$SimpleForwardingServerCall.close(ForwardingServerCall.java:39) at io.grpc.testing.integration.TestServiceImpl$6$1.close(TestServiceImpl.java:521) at io.grpc.PartialForwardingServerCall.close(PartialForwardingServerCall.java:48) at io.grpc.ForwardingServerCall.close(ForwardingServerCall.java:22) at io.grpc.ForwardingServerCall$SimpleForwardingServerCall.close(ForwardingServerCall.java:39) at io.grpc.testing.integration.TestServiceImpl$5$1.close(TestServiceImpl.java:494) at io.grpc.PartialForwardingServerCall.close(PartialForwardingServerCall.java:48) at io.grpc.ForwardingServerCall.close(ForwardingServerCall.java:22) at io.grpc.ForwardingServerCall$SimpleForwardingServerCall.close(ForwardingServerCall.java:39) at io.grpc.testing.integration.TestServiceImpl$4$1.close(TestServiceImpl.java:467) at io.grpc.stub.ServerCalls$ServerCallStreamObserverImpl.onCompleted(ServerCalls.java:395) at io.grpc.testing.integration.TestServiceImpl.unaryCall(TestServiceImpl.java:116) at io.grpc.testing.integration.TestServiceGrpc$MethodHandlers.invoke(TestServiceGrpc.java:762) at io.grpc.stub.ServerCalls$UnaryServerCallHandler$UnaryServerCallListener.onHalfClose(ServerCalls.java:182) at io.grpc.internal.ServerCallImpl$ServerStreamListenerImpl.halfClosed(ServerCallImpl.java:340) at io.grpc.internal.ServerImpl$JumpToApplicationThreadServerStreamListener$1HalfClosed.runInContext(ServerImpl.java:866) at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37) at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:133) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) This is observed in the standard error running tests of https://github.com/grpc/grpc-java/pull/8596 . It only fails intermittently, and stack trace can be from a different isReady() call. > 2. No. isReady means that the write call will not block, not that it will > return without an error of some sort. Yes. I'm just siting part of the javadoc. The full javadoc is: public abstract boolean isReady() This method can be used to determine if data can be written without blocking. Returns: true if a write to this ServletOutputStream will succeed, otherwise returns false. -- 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 8.5.x updated: BZ65757: Fix forgotten test case
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new 2bfbbef BZ65757: Fix forgotten test case
2bfbbef is described below
commit 2bfbbef65d1b1b07da46c8dcd6cee96cb5567998
Author: remm
AuthorDate: Mon Jan 3 16:05:22 2022 +0100
BZ65757: Fix forgotten test case
Dispaching in the servlet container when using non blocking IO needs
better thread identification. Otherwise, the container could see a
container thread and believe it doesn't need an explicit notification,
while actually the thread was simply running another request (so no
async post process).
---
java/org/apache/catalina/connector/CoyoteAdapter.java| 2 ++
java/org/apache/catalina/connector/InputBuffer.java | 3 +--
java/org/apache/coyote/Request.java | 16 +++-
java/org/apache/coyote/Response.java | 2 +-
.../apache/catalina/nonblocking/TestNonBlockingAPI.java | 4 +---
webapps/docs/changelog.xml | 4
6 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/java/org/apache/catalina/connector/CoyoteAdapter.java
b/java/org/apache/catalina/connector/CoyoteAdapter.java
index 766c11f..d9714e0 100644
--- a/java/org/apache/catalina/connector/CoyoteAdapter.java
+++ b/java/org/apache/catalina/connector/CoyoteAdapter.java
@@ -140,6 +140,7 @@ public class CoyoteAdapter implements Adapter {
AsyncContextImpl asyncConImpl = request.getAsyncContextInternal();
req.getRequestProcessor().setWorkerThreadName(THREAD_NAME.get());
+req.setRequestThread();
try {
if (!request.isAsync()) {
@@ -351,6 +352,7 @@ public class CoyoteAdapter implements Adapter {
boolean postParseSuccess = false;
req.getRequestProcessor().setWorkerThreadName(THREAD_NAME.get());
+req.setRequestThread();
try {
// Parse and set Catalina and configuration specific
diff --git a/java/org/apache/catalina/connector/InputBuffer.java
b/java/org/apache/catalina/connector/InputBuffer.java
index 1fbc3a9..5423517 100644
--- a/java/org/apache/catalina/connector/InputBuffer.java
+++ b/java/org/apache/catalina/connector/InputBuffer.java
@@ -32,7 +32,6 @@ import javax.servlet.ReadListener;
import org.apache.catalina.security.SecurityUtil;
import org.apache.coyote.ActionCode;
-import org.apache.coyote.ContainerThreadMarker;
import org.apache.coyote.Request;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
@@ -274,7 +273,7 @@ public class InputBuffer extends Reader
// If this is a non-container thread, need to trigger a read
// which will eventually lead to a call to onAllDataRead() via a
// container thread.
-if (!ContainerThreadMarker.isContainerThread()) {
+if (!coyoteRequest.isRequestThread()) {
coyoteRequest.action(ActionCode.DISPATCH_READ, null);
coyoteRequest.action(ActionCode.DISPATCH_EXECUTE, null);
}
diff --git a/java/org/apache/coyote/Request.java
b/java/org/apache/coyote/Request.java
index b82856d..677f113 100644
--- a/java/org/apache/coyote/Request.java
+++ b/java/org/apache/coyote/Request.java
@@ -154,6 +154,7 @@ public final class Request {
private long bytesRead=0;
// Time of the request - useful to avoid repeated calls to
System.currentTime
private long startTime = -1;
+private long threadId = 0;
private int available = 0;
private final RequestInfo reqProcessorMX=new RequestInfo(this);
@@ -220,7 +221,7 @@ public final class Request {
fireListener = true;
}
action(ActionCode.DISPATCH_READ, null);
-if (!ContainerThreadMarker.isContainerThread()) {
+if (!isRequestThread()) {
// Not on a container thread so need to execute the dispatch
action(ActionCode.DISPATCH_EXECUTE, null);
}
@@ -717,6 +718,18 @@ public final class Request {
this.startTime = startTime;
}
+public long getThreadId() {
+return threadId;
+}
+
+public void setRequestThread() {
+threadId = Thread.currentThread().getId();
+}
+
+public boolean isRequestThread() {
+return Thread.currentThread().getId() == threadId;
+}
+
// Per-Request "notes"
@@ -799,6 +812,7 @@ public final class Request {
allDataReadEventSent.set(false);
startTime = -1;
+threadId = 0;
}
// Info
diff --git a/java/org/apache/coyote/Response.java
b/java/org/apache/coyote/Response.java
index d25d570..f3bcd8b 100644
--- a/java/org/apache/coyote/Response.java
+++
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #6 from Anders Rundgren --- > The OP recommends using a package that is limited (APR only), fragile > (custom non-daemon watcher thread, suspicious call behavior, and (IMHO) > unnecessary. I'm merely proposing adding this kind of functionality. I'm not an expert on Tomcat internals so I have no suggestion on how :) > Another option would be to use Romain Manni-Bucau's complete ACME component > within Tomcat. It handles the whole ACME process, including reloading the > connector as necessary. Although I was unaware of Romain's ACME stuff, I'm a little bit worried about scoping key reload exclusively to ACME. In addition there are several external ACME packages like https://certbot.eff.org/ which are designed to work with arbitrary Web servers. I'm currently using certbot and the mentioned custom APR connector. -- 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 65780] CoyoteOutputStream should never throw NullPointerException after AsyncContext.complete() is called
https://bz.apache.org/bugzilla/show_bug.cgi?id=65780 Dapeng Zhang changed: What|Removed |Added Status|NEEDINFO|NEW -- 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 8.5.x updated: Improve fix to avoid deadlock reported on some systems
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 6285e75 Improve fix to avoid deadlock reported on some systems
6285e75 is described below
commit 6285e750e2b640fa9c59c11c09a753a36a5396b8
Author: Mark Thomas
AuthorDate: Mon Jan 3 17:24:59 2022 +
Improve fix to avoid deadlock reported on some systems
https://markmail.org/message/ldpjfdwpkmqc7ved
---
java/org/apache/coyote/http2/Http2UpgradeHandler.java | 14 --
java/org/apache/coyote/http2/Stream.java | 18 ++
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 1195997..a2c87ed 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -345,7 +345,7 @@ class Http2UpgradeHandler extends AbstractStream implements
InternalHttpUpgradeH
// continue reading frames
Stream stream = getStream(se.getStreamId(), false);
if (stream == null) {
-sendStreamReset(se);
+sendStreamReset(null, se);
} else {
stream.close(se);
}
@@ -535,7 +535,7 @@ class Http2UpgradeHandler extends AbstractStream implements
InternalHttpUpgradeH
}
-void sendStreamReset(StreamException se) throws IOException {
+void sendStreamReset(StreamStateMachine state, StreamException se) throws
IOException {
if (log.isDebugEnabled()) {
log.debug(sm.getString("upgradeHandler.rst.debug", connectionId,
@@ -554,7 +554,17 @@ class Http2UpgradeHandler extends AbstractStream
implements InternalHttpUpgradeH
// Payload
ByteUtil.setFourBytes(rstFrame, 9, se.getError().getCode());
+// Need to update state atomically with the sending of the RST
+// frame else other threads currently working with this stream
+// may see the state change and send a RST frame before the RST
+// frame triggered by this thread. If that happens the client
+// may see out of order RST frames which may hard to follow if
+// the client is unaware the RST frames may be received out of
+// order.
synchronized (socketWrapper) {
+if (state != null) {
+state.sendReset();
+}
socketWrapper.write(true, rstFrame, 0, rstFrame.length);
socketWrapper.flush(true);
}
diff --git a/java/org/apache/coyote/http2/Stream.java
b/java/org/apache/coyote/http2/Stream.java
index fffd240..a4d6484 100644
--- a/java/org/apache/coyote/http2/Stream.java
+++ b/java/org/apache/coyote/http2/Stream.java
@@ -614,14 +614,16 @@ class Stream extends AbstractNonZeroStream implements
HeaderEmitter {
log.debug(sm.getString("stream.reset.send",
getConnectionId(), getIdAsString(),
se.getError()));
}
-// Sync ensures that if the call to sendReset() triggers resets
-// in other threads, that the RST frame associated with this
-// thread is sent before the RST frames associated with those
-// threads.
-synchronized (state) {
-state.sendReset();
-handler.sendStreamReset(se);
-}
+
+// Need to update state atomically with the sending of the RST
+// frame else other threads currently working with this stream
+// may see the state change and send a RST frame before the RST
+// frame triggered by this thread. If that happens the client
+// may see out of order RST frames which may hard to follow if
+// the client is unaware the RST frames may be received out of
+// order.
+handler.sendStreamReset(state, se);
+
cancelAllocationRequests();
if (inputBuffer != null) {
inputBuffer.swallowUnread();
-
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: Improve fix to avoid deadlock reported on some systems
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 6fa3fd2 Improve fix to avoid deadlock reported on some systems
6fa3fd2 is described below
commit 6fa3fd20d3cc783f664644e124afac57d74d9313
Author: Mark Thomas
AuthorDate: Mon Jan 3 17:24:59 2022 +
Improve fix to avoid deadlock reported on some systems
https://markmail.org/message/ldpjfdwpkmqc7ved
---
java/org/apache/coyote/http2/Http2UpgradeHandler.java | 14 --
java/org/apache/coyote/http2/Stream.java | 18 ++
webapps/docs/changelog.xml| 5 +
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index b105722..2dd439a 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -351,7 +351,7 @@ class Http2UpgradeHandler extends AbstractStream implements
InternalHttpUpgradeH
// continue reading frames
Stream stream = getStream(se.getStreamId(), false);
if (stream == null) {
-sendStreamReset(se);
+sendStreamReset(null, se);
} else {
stream.close(se);
}
@@ -534,7 +534,7 @@ class Http2UpgradeHandler extends AbstractStream implements
InternalHttpUpgradeH
}
-void sendStreamReset(StreamException se) throws IOException {
+void sendStreamReset(StreamStateMachine state, StreamException se) throws
IOException {
if (log.isDebugEnabled()) {
log.debug(sm.getString("upgradeHandler.rst.debug", connectionId,
@@ -553,7 +553,17 @@ class Http2UpgradeHandler extends AbstractStream
implements InternalHttpUpgradeH
// Payload
ByteUtil.setFourBytes(rstFrame, 9, se.getError().getCode());
+// Need to update state atomically with the sending of the RST
+// frame else other threads currently working with this stream
+// may see the state change and send a RST frame before the RST
+// frame triggered by this thread. If that happens the client
+// may see out of order RST frames which may hard to follow if
+// the client is unaware the RST frames may be received out of
+// order.
synchronized (socketWrapper) {
+if (state != null) {
+state.sendReset();
+}
socketWrapper.write(true, rstFrame, 0, rstFrame.length);
socketWrapper.flush(true);
}
diff --git a/java/org/apache/coyote/http2/Stream.java
b/java/org/apache/coyote/http2/Stream.java
index 48e2799..ed8b90b 100644
--- a/java/org/apache/coyote/http2/Stream.java
+++ b/java/org/apache/coyote/http2/Stream.java
@@ -655,14 +655,16 @@ class Stream extends AbstractNonZeroStream implements
HeaderEmitter {
log.debug(sm.getString("stream.reset.send",
getConnectionId(), getIdAsString(),
se.getError()));
}
-// Sync ensures that if the call to sendReset() triggers resets
-// in other threads, that the RST frame associated with this
-// thread is sent before the RST frames associated with those
-// threads.
-synchronized (state) {
-state.sendReset();
-handler.sendStreamReset(se);
-}
+
+// Need to update state atomically with the sending of the RST
+// frame else other threads currently working with this stream
+// may see the state change and send a RST frame before the RST
+// frame triggered by this thread. If that happens the client
+// may see out of order RST frames which may hard to follow if
+// the client is unaware the RST frames may be received out of
+// order.
+handler.sendStreamReset(state, se);
+
cancelAllocationRequests();
if (inputBuffer != null) {
inputBuffer.swallowUnread();
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 810b019..fdc8a4b 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -132,6 +132,11 @@
65757: Missing initial IO listener notification on Servlet
container dispatch to another container thread. (remm)
+
+Improve the fix for RST frame ordering added in 9.0.56 to avoid a
+potential deadlock on some systems in non-default configu
[tomcat] branch 10.0.x updated: Improve fix to avoid deadlock reported on some systems
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.0.x by this push:
new 8ba16e0 Improve fix to avoid deadlock reported on some systems
8ba16e0 is described below
commit 8ba16e09bfc58cdbac820790e8c425279f04cd98
Author: Mark Thomas
AuthorDate: Mon Jan 3 17:24:59 2022 +
Improve fix to avoid deadlock reported on some systems
https://markmail.org/message/ldpjfdwpkmqc7ved
---
java/org/apache/coyote/http2/Http2UpgradeHandler.java | 14 --
java/org/apache/coyote/http2/Stream.java | 18 ++
webapps/docs/changelog.xml| 5 +
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 1c522af..91abf18 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -351,7 +351,7 @@ class Http2UpgradeHandler extends AbstractStream implements
InternalHttpUpgradeH
// continue reading frames
Stream stream = getStream(se.getStreamId(), false);
if (stream == null) {
-sendStreamReset(se);
+sendStreamReset(null, se);
} else {
stream.close(se);
}
@@ -534,7 +534,7 @@ class Http2UpgradeHandler extends AbstractStream implements
InternalHttpUpgradeH
}
-void sendStreamReset(StreamException se) throws IOException {
+void sendStreamReset(StreamStateMachine state, StreamException se) throws
IOException {
if (log.isDebugEnabled()) {
log.debug(sm.getString("upgradeHandler.rst.debug", connectionId,
@@ -553,7 +553,17 @@ class Http2UpgradeHandler extends AbstractStream
implements InternalHttpUpgradeH
// Payload
ByteUtil.setFourBytes(rstFrame, 9, se.getError().getCode());
+// Need to update state atomically with the sending of the RST
+// frame else other threads currently working with this stream
+// may see the state change and send a RST frame before the RST
+// frame triggered by this thread. If that happens the client
+// may see out of order RST frames which may hard to follow if
+// the client is unaware the RST frames may be received out of
+// order.
synchronized (socketWrapper) {
+if (state != null) {
+state.sendReset();
+}
socketWrapper.write(true, rstFrame, 0, rstFrame.length);
socketWrapper.flush(true);
}
diff --git a/java/org/apache/coyote/http2/Stream.java
b/java/org/apache/coyote/http2/Stream.java
index 9f8a83e..1451a1b 100644
--- a/java/org/apache/coyote/http2/Stream.java
+++ b/java/org/apache/coyote/http2/Stream.java
@@ -655,14 +655,16 @@ class Stream extends AbstractNonZeroStream implements
HeaderEmitter {
log.debug(sm.getString("stream.reset.send",
getConnectionId(), getIdAsString(),
se.getError()));
}
-// Sync ensures that if the call to sendReset() triggers resets
-// in other threads, that the RST frame associated with this
-// thread is sent before the RST frames associated with those
-// threads.
-synchronized (state) {
-state.sendReset();
-handler.sendStreamReset(se);
-}
+
+// Need to update state atomically with the sending of the RST
+// frame else other threads currently working with this stream
+// may see the state change and send a RST frame before the RST
+// frame triggered by this thread. If that happens the client
+// may see out of order RST frames which may hard to follow if
+// the client is unaware the RST frames may be received out of
+// order.
+handler.sendStreamReset(state, se);
+
cancelAllocationRequests();
if (inputBuffer != null) {
inputBuffer.swallowUnread();
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 9f87ce2..e0e3d32 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -132,6 +132,11 @@
65757: Missing initial IO listener notification on Servlet
container dispatch to another container thread. (remm)
+
+Improve the fix for RST frame ordering added in 10.0.14 to avoid a
+potential deadlock on some systems in non-default conf
[tomcat] branch main updated: Improve fix to avoid deadlock reported on some systems
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 ca4f298 Improve fix to avoid deadlock reported on some systems
ca4f298 is described below
commit ca4f2989465f4ead1e24ebccda0ab71379164798
Author: Mark Thomas
AuthorDate: Mon Jan 3 17:24:59 2022 +
Improve fix to avoid deadlock reported on some systems
https://markmail.org/message/ldpjfdwpkmqc7ved
---
java/org/apache/coyote/http2/Http2UpgradeHandler.java | 14 --
java/org/apache/coyote/http2/Stream.java | 18 ++
webapps/docs/changelog.xml| 5 +
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index fcb05b0..a075c02 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -353,7 +353,7 @@ class Http2UpgradeHandler extends AbstractStream implements
InternalHttpUpgradeH
// continue reading frames
Stream stream = getStream(se.getStreamId(), false);
if (stream == null) {
-sendStreamReset(se);
+sendStreamReset(null, se);
} else {
stream.close(se);
}
@@ -536,7 +536,7 @@ class Http2UpgradeHandler extends AbstractStream implements
InternalHttpUpgradeH
}
-void sendStreamReset(StreamException se) throws IOException {
+void sendStreamReset(StreamStateMachine state, StreamException se) throws
IOException {
if (log.isDebugEnabled()) {
log.debug(sm.getString("upgradeHandler.rst.debug", connectionId,
@@ -555,7 +555,17 @@ class Http2UpgradeHandler extends AbstractStream
implements InternalHttpUpgradeH
// Payload
ByteUtil.setFourBytes(rstFrame, 9, se.getError().getCode());
+// Need to update state atomically with the sending of the RST
+// frame else other threads currently working with this stream
+// may see the state change and send a RST frame before the RST
+// frame triggered by this thread. If that happens the client
+// may see out of order RST frames which may hard to follow if
+// the client is unaware the RST frames may be received out of
+// order.
synchronized (socketWrapper) {
+if (state != null) {
+state.sendReset();
+}
socketWrapper.write(true, rstFrame, 0, rstFrame.length);
socketWrapper.flush(true);
}
diff --git a/java/org/apache/coyote/http2/Stream.java
b/java/org/apache/coyote/http2/Stream.java
index ac3dd72..8fee970 100644
--- a/java/org/apache/coyote/http2/Stream.java
+++ b/java/org/apache/coyote/http2/Stream.java
@@ -660,14 +660,16 @@ class Stream extends AbstractNonZeroStream implements
HeaderEmitter {
log.debug(sm.getString("stream.reset.send",
getConnectionId(), getIdAsString(),
se.getError()));
}
-// Sync ensures that if the call to sendReset() triggers resets
-// in other threads, that the RST frame associated with this
-// thread is sent before the RST frames associated with those
-// threads.
-synchronized (state) {
-state.sendReset();
-handler.sendStreamReset(se);
-}
+
+// Need to update state atomically with the sending of the RST
+// frame else other threads currently working with this stream
+// may see the state change and send a RST frame before the RST
+// frame triggered by this thread. If that happens the client
+// may see out of order RST frames which may hard to follow if
+// the client is unaware the RST frames may be received out of
+// order.
+handler.sendStreamReset(state, se);
+
cancelAllocationRequests();
if (inputBuffer != null) {
inputBuffer.swallowUnread();
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index e1b858d..7d95f41 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -141,6 +141,11 @@
65757: Missing initial IO listener notification on Servlet
container dispatch to another container thread. (remm)
+
+Improve the fix for RST frame ordering added in 10.1.0-M8 to avoid a
+potential deadlock on some systems in non-default config
[tomcat] branch 10.0.x updated: Fix build. Use new sendResetLock in async handler
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.0.x by this push:
new 4957254 Fix build. Use new sendResetLock in async handler
4957254 is described below
commit 4957254359e6448aef70a602dd49bac878efdeb5
Author: Mark Thomas
AuthorDate: Mon Jan 3 19:05:01 2022 +
Fix build. Use new sendResetLock in async handler
---
.../coyote/http2/Http2AsyncUpgradeHandler.java | 24 ++
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
index 15ec1d1..d79a4b7 100644
--- a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
@@ -45,6 +45,8 @@ public class Http2AsyncUpgradeHandler extends
Http2UpgradeHandler {
// Because of the compression used, headers need to be written to the
// network in the same order they are generated.
private final Object headerWriteLock = new Object();
+// Ensures thread triggers the stream reset is the first to send a RST
frame
+private final Object sendResetLock = new Object();
private final AtomicReference error = new AtomicReference<>();
private final AtomicReference applicationIOE = new
AtomicReference<>();
@@ -123,7 +125,7 @@ public class Http2AsyncUpgradeHandler extends
Http2UpgradeHandler {
@Override
-void sendStreamReset(StreamException se) throws IOException {
+void sendStreamReset(StreamStateMachine state, StreamException se) throws
IOException {
if (log.isDebugEnabled()) {
log.debug(sm.getString("upgradeHandler.rst.debug", connectionId,
Integer.toString(se.getStreamId()), se.getError(),
se.getMessage()));
@@ -139,9 +141,23 @@ public class Http2AsyncUpgradeHandler extends
Http2UpgradeHandler {
ByteUtil.set31Bits(rstFrame, 5, se.getStreamId());
// Payload
ByteUtil.setFourBytes(rstFrame, 9, se.getError().getCode());
-socketWrapper.write(BlockingMode.SEMI_BLOCK,
protocol.getWriteTimeout(),
-TimeUnit.MILLISECONDS, null, SocketWrapperBase.COMPLETE_WRITE,
errorCompletion,
-ByteBuffer.wrap(rstFrame));
+
+// Need to update state atomically with the sending of the RST
+// frame else other threads currently working with this stream
+// may see the state change and send a RST frame before the RST
+// frame triggered by this thread. If that happens the client
+// may see out of order RST frames which may hard to follow if
+// the client is unaware the RST frames may be received out of
+// order.
+synchronized (sendResetLock) {
+if (state != null) {
+state.sendReset();
+}
+
+socketWrapper.write(BlockingMode.SEMI_BLOCK,
protocol.getWriteTimeout(),
+TimeUnit.MILLISECONDS, null,
SocketWrapperBase.COMPLETE_WRITE, errorCompletion,
+ByteBuffer.wrap(rstFrame));
+}
handleAsyncException();
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Fix build. Use new sendResetLock in async handler
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 bd0657c Fix build. Use new sendResetLock in async handler
bd0657c is described below
commit bd0657cba1c42366e8b2495435e1b17dbd2d8706
Author: Mark Thomas
AuthorDate: Mon Jan 3 19:05:01 2022 +
Fix build. Use new sendResetLock in async handler
---
.../coyote/http2/Http2AsyncUpgradeHandler.java | 24 ++
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
index a63f470..9f4af14 100644
--- a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
@@ -45,6 +45,8 @@ public class Http2AsyncUpgradeHandler extends
Http2UpgradeHandler {
// Because of the compression used, headers need to be written to the
// network in the same order they are generated.
private final Object headerWriteLock = new Object();
+// Ensures thread triggers the stream reset is the first to send a RST
frame
+private final Object sendResetLock = new Object();
private final AtomicReference error = new AtomicReference<>();
private final AtomicReference applicationIOE = new
AtomicReference<>();
@@ -123,7 +125,7 @@ public class Http2AsyncUpgradeHandler extends
Http2UpgradeHandler {
@Override
-void sendStreamReset(StreamException se) throws IOException {
+void sendStreamReset(StreamStateMachine state, StreamException se) throws
IOException {
if (log.isDebugEnabled()) {
log.debug(sm.getString("upgradeHandler.rst.debug", connectionId,
Integer.toString(se.getStreamId()), se.getError(),
se.getMessage()));
@@ -139,9 +141,23 @@ public class Http2AsyncUpgradeHandler extends
Http2UpgradeHandler {
ByteUtil.set31Bits(rstFrame, 5, se.getStreamId());
// Payload
ByteUtil.setFourBytes(rstFrame, 9, se.getError().getCode());
-socketWrapper.write(BlockingMode.SEMI_BLOCK,
protocol.getWriteTimeout(),
-TimeUnit.MILLISECONDS, null, SocketWrapperBase.COMPLETE_WRITE,
errorCompletion,
-ByteBuffer.wrap(rstFrame));
+
+// Need to update state atomically with the sending of the RST
+// frame else other threads currently working with this stream
+// may see the state change and send a RST frame before the RST
+// frame triggered by this thread. If that happens the client
+// may see out of order RST frames which may hard to follow if
+// the client is unaware the RST frames may be received out of
+// order.
+synchronized (sendResetLock) {
+if (state != null) {
+state.sendReset();
+}
+
+socketWrapper.write(BlockingMode.SEMI_BLOCK,
protocol.getWriteTimeout(),
+TimeUnit.MILLISECONDS, null,
SocketWrapperBase.COMPLETE_WRITE, errorCompletion,
+ByteBuffer.wrap(rstFrame));
+}
handleAsyncException();
}
-
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: Fix build. Use new sendResetLock in async handler
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 16847e1 Fix build. Use new sendResetLock in async handler
16847e1 is described below
commit 16847e13a483f8268b9144056e621810cea1bd19
Author: Mark Thomas
AuthorDate: Mon Jan 3 19:05:01 2022 +
Fix build. Use new sendResetLock in async handler
---
.../coyote/http2/Http2AsyncUpgradeHandler.java | 24 ++
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
index 848a9e1..817402b 100644
--- a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
@@ -45,6 +45,8 @@ public class Http2AsyncUpgradeHandler extends
Http2UpgradeHandler {
// Because of the compression used, headers need to be written to the
// network in the same order they are generated.
private final Object headerWriteLock = new Object();
+// Ensures thread triggers the stream reset is the first to send a RST
frame
+private final Object sendResetLock = new Object();
private final AtomicReference error = new AtomicReference<>();
private final AtomicReference applicationIOE = new
AtomicReference<>();
@@ -123,7 +125,7 @@ public class Http2AsyncUpgradeHandler extends
Http2UpgradeHandler {
@Override
-void sendStreamReset(StreamException se) throws IOException {
+void sendStreamReset(StreamStateMachine state, StreamException se) throws
IOException {
if (log.isDebugEnabled()) {
log.debug(sm.getString("upgradeHandler.rst.debug", connectionId,
Integer.toString(se.getStreamId()), se.getError(),
se.getMessage()));
@@ -139,9 +141,23 @@ public class Http2AsyncUpgradeHandler extends
Http2UpgradeHandler {
ByteUtil.set31Bits(rstFrame, 5, se.getStreamId());
// Payload
ByteUtil.setFourBytes(rstFrame, 9, se.getError().getCode());
-socketWrapper.write(BlockingMode.SEMI_BLOCK,
protocol.getWriteTimeout(),
-TimeUnit.MILLISECONDS, null, SocketWrapperBase.COMPLETE_WRITE,
errorCompletion,
-ByteBuffer.wrap(rstFrame));
+
+// Need to update state atomically with the sending of the RST
+// frame else other threads currently working with this stream
+// may see the state change and send a RST frame before the RST
+// frame triggered by this thread. If that happens the client
+// may see out of order RST frames which may hard to follow if
+// the client is unaware the RST frames may be received out of
+// order.
+synchronized (sendResetLock) {
+if (state != null) {
+state.sendReset();
+}
+
+socketWrapper.write(BlockingMode.SEMI_BLOCK,
protocol.getWriteTimeout(),
+TimeUnit.MILLISECONDS, null,
SocketWrapperBase.COMPLETE_WRITE, errorCompletion,
+ByteBuffer.wrap(rstFrame));
+}
handleAsyncException();
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch 8.5.x updated: Improve fix to avoid deadlock reported on some systems
Unfortunately I can still reproduce a deadlock on 8.5. I saw the non-8.5
update a few minutes ago, so maybe more changes are coming. Just wanted
to let you know. jstack output attached. Reproduction based on
6285e750e2b640fa9c59c11c09a753a36a5396b8.
Am 03.01.2022 um 18:25 schrieb ma...@apache.org:
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 6285e75 Improve fix to avoid deadlock reported on some systems
6285e75 is described below
commit 6285e750e2b640fa9c59c11c09a753a36a5396b8
Author: Mark Thomas
AuthorDate: Mon Jan 3 17:24:59 2022 +
Improve fix to avoid deadlock reported on some systems
https://markmail.org/message/ldpjfdwpkmqc7ved
---
java/org/apache/coyote/http2/Http2UpgradeHandler.java | 14 --
java/org/apache/coyote/http2/Stream.java | 18 ++
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 1195997..a2c87ed 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -345,7 +345,7 @@ class Http2UpgradeHandler extends AbstractStream implements
InternalHttpUpgradeH
// continue reading frames
Stream stream = getStream(se.getStreamId(),
false);
if (stream == null) {
-sendStreamReset(se);
+sendStreamReset(null, se);
} else {
stream.close(se);
}
@@ -535,7 +535,7 @@ class Http2UpgradeHandler extends AbstractStream implements
InternalHttpUpgradeH
}
-void sendStreamReset(StreamException se) throws IOException {
+void sendStreamReset(StreamStateMachine state, StreamException se) throws
IOException {
if (log.isDebugEnabled()) {
log.debug(sm.getString("upgradeHandler.rst.debug", connectionId,
@@ -554,7 +554,17 @@ class Http2UpgradeHandler extends AbstractStream
implements InternalHttpUpgradeH
// Payload
ByteUtil.setFourBytes(rstFrame, 9, se.getError().getCode());
+// Need to update state atomically with the sending of the RST
+// frame else other threads currently working with this stream
+// may see the state change and send a RST frame before the RST
+// frame triggered by this thread. If that happens the client
+// may see out of order RST frames which may hard to follow if
+// the client is unaware the RST frames may be received out of
+// order.
synchronized (socketWrapper) {
+if (state != null) {
+state.sendReset();
+}
socketWrapper.write(true, rstFrame, 0, rstFrame.length);
socketWrapper.flush(true);
}
diff --git a/java/org/apache/coyote/http2/Stream.java
b/java/org/apache/coyote/http2/Stream.java
index fffd240..a4d6484 100644
--- a/java/org/apache/coyote/http2/Stream.java
+++ b/java/org/apache/coyote/http2/Stream.java
@@ -614,14 +614,16 @@ class Stream extends AbstractNonZeroStream implements
HeaderEmitter {
log.debug(sm.getString("stream.reset.send",
getConnectionId(), getIdAsString(),
se.getError()));
}
-// Sync ensures that if the call to sendReset() triggers resets
-// in other threads, that the RST frame associated with this
-// thread is sent before the RST frames associated with those
-// threads.
-synchronized (state) {
-state.sendReset();
-handler.sendStreamReset(se);
-}
+
+// Need to update state atomically with the sending of the RST
+// frame else other threads currently working with this stream
+// may see the state change and send a RST frame before the RST
+// frame triggered by this thread. If that happens the client
+// may see out of order RST frames which may hard to follow if
+// the client is unaware the RST frames may be received out of
+// order.
+handler.sendStreamReset(state, se);
+
cancelAllocationRequests();
if (inputBuffer != null) {
inputBuffer.swallowUnread();2022-01-03 20:05:11
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.212-b10 mixed mode):
"Attach Listener" #29 daemon prio=9 os_prio=64 tid=0x000100d96800 nid=0x20
waiting on condition [
Re: [tomcat] branch 10.0.x updated: Update Eclipse JDT from 4.20 to 4.22
On Mon, Jan 3, 2022 at 12:32 PM Mark Thomas wrote: > > On 03/01/2022 11:20, Rémy Maucherat wrote: > > On Mon, Jan 3, 2022 at 11:53 AM Rainer Jung wrote: > >> > >> For reference: this is probably the ticket about moving JDT (and ECJ) to > >> Java 11: > >> > >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=572389 > >> > >> And this is the parallel mail discussion: > >> > >> https://www.eclipse.org/lists/eclipse-dev/msg11703.html > >> > >> If we roll back the change for TC 10.0 and 9, there is also the later > >> change about JSP compilation for Java 17/18 that was depeding on the ECJ > >> update. > > > > Well, this is a big problem since we plan to support Tomcat 9 for a > > very long time and there's now no way to update JDT :( > > Any ideas ? > > I think we have options. Ok :) > JDT bugs that affect JSP compilation are rare as are security bugs. On > that basis, the likelihood of an update being required is low. > > Tomcat 8.5.x has been stuck on ECJ 4.6.3 (last Java 7 version) since > 2017 and that hasn't been an issue so far. > > I don't think we have said Tomcat 9.10.x etc will continue to have Java > 8 as a minimum. It is the Java EE 8 API we are looking to retain and > while java EE 8 does specify Java 8 as a minimum I think we have a case > - in terms of extended support - to update that if we need a newer > version of Java in order to update a dependency we need to update. Indeed, nothing was said about keeping 9.x on Java 8. Now that I think about it, it would be annoying to do it as we would need to rewrite more code. > Users always have the option of replacing the ECJ JAR that ships with > Tomcat with a new (or older) version. Whatever we decide to do as the > default, users will always have the option to use a different ECJ JAR. > > Actually, using an older version might be tricky as we use the newer > constants but if we keep that in mind for 9.10.x onwards we could ship > with a newer ECJ and leave the option open for users to downgrade. Overall, I still think this is bad news, but you convinced me it could work ... > Sort of related, I am wondering about the build environment. We have > seen an issue with downstream building with Java 11 and there are > difficulties building 8.5.x particularly with a clean install of the > latest publicly available Java 7. What about switching all versions to > building with Java 11 and using the release compilation option to set > the appropriate Java API to build against? Does that work for avoiding the ByteBuffer problems ? Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65773] WINDOW_UPDATE NOT SENT
https://bz.apache.org/bugzilla/show_bug.cgi?id=65773 Arshiya changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- -- 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] branch 10.0.x updated: Update Eclipse JDT from 4.20 to 4.22
Am 2022-01-03 um 12:20 schrieb Rémy Maucherat: On Mon, Jan 3, 2022 at 11:53 AM Rainer Jung wrote: For reference: this is probably the ticket about moving JDT (and ECJ) to Java 11: https://bugs.eclipse.org/bugs/show_bug.cgi?id=572389 And this is the parallel mail discussion: https://www.eclipse.org/lists/eclipse-dev/msg11703.html If we roll back the change for TC 10.0 and 9, there is also the later change about JSP compilation for Java 17/18 that was depeding on the ECJ update. Well, this is a big problem since we plan to support Tomcat 9 for a very long time and there's now no way to update JDT :( Any ideas ? Why not talk to the JDT guys and see what they say? I scanned through the BZ and I haven't seen anything compelling for Java 11 use. Maybe they will reconsider the Java baseline? M
