Am 03.12.2020 um 15:49 schrieb Mark Thomas:
The proposed Apache Tomcat 8.5.61 release is now available for voting.
The notable changes compared to the 8.5.60 release are:
- Align the behaviour of ServletContext.getRealPath(String path) with
the recent clarification from the Servlet specification project. If
the path parameter does not start with / then Tomcat processes the
call as if / is appended to the beginning of the provided path.
- Fix a potential file descriptor leak when WebSocket connections are
attempted and fail. Patch provided by Maurizio Adami.
- Ensure that the LoadBalancerDrainingValve uses the correct setting
for the secure attribute for any session cookies it creates. Based on
a pull request by Andreas Kurth.
Along with lots of other bug fixes and improvements.
For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.61/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1290/
The tag is:
https://github.com/apache/tomcat/tree/8.5.61
77d330abea52e4aeb039ca7eb8a766e0e1c56a71
The proposed 8.5.61 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 8.5.61
I don't know, whether this is new, but I observe a loop when running
"main" prio=3 tid=0x0002ac00 nid=0x2 waiting on condition [0xfe37e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xed612508> (a
java.util.concurrent.CountDownLatch$Sync)
at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at
java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
at org.apache.tomcat.util.net.TestSsl.testPost(TestSsl.java:153)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
...
The loop happens in
"Thread-8" prio=3 tid=0x00692800 nid=0x43 runnable [0xe5bff000]
java.lang.Thread.State: RUNNABLE
at sun.security.ssl.AppInputStream.read(AppInputStream.java:92)
- locked <0xed614d38> (a sun.security.ssl.AppInputStream)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:69)
- locked <0xed614d38> (a sun.security.ssl.AppInputStream)
at org.apache.tomcat.util.net.TestSsl$1.run(TestSsl.java:128)
"Thread-8" prio=3 tid=0x00692800 nid=0x43 runnable [0xe5bff000]
java.lang.Thread.State: RUNNABLE
at org.apache.tomcat.util.net.TestSsl$1.run(TestSsl.java:128)
Another stack I captured was:
Thread t@67: (state = IN_JAVA)
- java.lang.StringBuilder.append(java.lang.String) @bci=2, line=132
(Compiled frame; information may be imprecise)
- sun.security.ssl.SSLSocketImpl.checkEOF() @bci=96, line=1496
(Compiled frame)
- sun.security.ssl.AppInputStream.read(byte[], int, int) @bci=46,
line=92 (Compiled frame)
- sun.security.ssl.AppInputStream.read() @bci=7, line=69 (Compiled frame)
- org.apache.tomcat.util.net.TestSsl$1.run() @bci=151, line=128
(Compiled frame)
The test loops using a lot of CPU, it is not just a hang.
This was an Solaris 10 Sparc using java 1.7.0_80.
It might be a test only problem though.
The process is still there in case we have an idea how to get more out
of the running process.
Kind regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
