[Bug 63767] install windows service, tomcat9 start crash.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63767 --- Comment #10 from Mark Thomas --- The compiler didn't report it. The compiler runs with the default -W3 flag. The relevant warning is not shown unless you run with -W4. Switching to -W4 generates quite a few warnings. I'm currently reviewing them. -- 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
svn commit: r1867771 - /tomcat/site/trunk/xdocs/presentations.xml
Author: csutherl Date: Mon Sep 30 12:35:23 2019 New Revision: 1867771 URL: http://svn.apache.org/viewvc?rev=1867771&view=rev Log: Add slide links for Coty Modified: tomcat/site/trunk/xdocs/presentations.xml Modified: tomcat/site/trunk/xdocs/presentations.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/presentations.xml?rev=1867771&r1=1867770&r2=1867771&view=diff == --- tomcat/site/trunk/xdocs/presentations.xml (original) +++ tomcat/site/trunk/xdocs/presentations.xml Mon Sep 30 12:35:23 2019 @@ -49,6 +49,7 @@ mailing list. Tips for Debugging Tomcat and Web Applications - Coty Sutherland, +https://people.apache.org/~csutherl/ApacheCon%20NA%202019/Tips%20for%20Debugging%20Tomcat%20and%20Web%20Applications%20(2019).pdf">slides, https://www.youtube.com/watch?v=taKWjPeIbIM";>video @@ -71,6 +72,7 @@ mailing list. Packaging Tomcat for Linux Distributions - Coty Sutherland, +https://people.apache.org/~csutherl/ApacheCon%20NA%202019/Packaging%20Tomcat%20for%20Linux%20Distributions%20(2019).pdf">slides, https://www.youtube.com/watch?v=yyx5e83DOgc";>video - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63251] [JDK-8194653] Deadlock in FileSystems.getDefault on catalina startup
https://bz.apache.org/bugzilla/show_bug.cgi?id=63251 --- Comment #3 from harri...@gmail.com --- (In reply to harristr from comment #2) > The work-around of pre-loading the default FileSystem does not appear to > solve the problem for logging, or maybe it only reduced the frequency of the > occurrence. I am still seeing the following stacktrace from a Spring Boot > Microservice running Tomcat 9.0.22 with JDK 1.8.0_222 64-bit on RedHat 7.5: After further investigation I think this work-around actually CAUSED the "deadlock" I am experiencing. I never saw this using Tomcat 9.0.17, it only manifested after an upgrade directly to 9.0.22. In an environment such as mine (a SpringBoot Microservice), Tomcat is NOT running in the main thread or starting first, Spring Boot is. This means the probability of reaching the "deadlock" is higher since Spring Boot is the one running first and Tomcat is coming up in a different thread but is now trying to prime the FileSystem right away. I included more of the thread dump below. "background-preinit" #9 prio=5 os_prio=0 tid=0x02d11800 nid=0x726 waiting for monitor entry [0x7f26ddd01000] java.lang.Thread.State: BLOCKED (on object monitor) at java.lang.Runtime.loadLibrary0(Runtime.java:862) - waiting to lock <0xc010be00> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:1122) at sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java:573) at sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java:571) at java.security.AccessController.doPrivileged(Native Method) at sun.nio.fs.UnixNativeDispatcher.(UnixNativeDispatcher.java:571) at sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:67) at sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39) at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46) at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39) at sun.nio.fs.UnixFileSystemProvider.(UnixFileSystemProvider.java:56) at sun.nio.fs.LinuxFileSystemProvider.(LinuxFileSystemProvider.java:41) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:442) at sun.nio.fs.DefaultFileSystemProvider.createProvider(DefaultFileSystemProvider.java:48) at sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:63) at java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:108) at java.nio.file.FileSystems$DefaultFileSystemHolder.access$000(FileSystems.java:89) at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:98) at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:96) at java.security.AccessController.doPrivileged(Native Method) at java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:96) at java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:90) at java.nio.file.FileSystems.getDefault(FileSystems.java:176) at org.apache.juli.logging.LogFactory.(LogFactory.java:85) at org.apache.juli.logging.LogFactory.(LogFactory.java:66) at org.apache.catalina.mbeans.MBeanFactory.(MBeanFactory.java:59) at org.springframework.boot.autoconfigure.BackgroundPreinitializer$MBeanFactoryInitializer.run(BackgroundPreinitializer.java:139) at org.springframework.boot.autoconfigure.BackgroundPreinitializer$1.runSafely(BackgroundPreinitializer.java:102) at org.springframework.boot.autoconfigure.BackgroundPreinitializer$1.run(BackgroundPreinitializer.java:94) at java.lang.Thread.run(Thread.java:748) "Service Thread" #8 daemon prio=9 os_prio=0 tid=0x00fa nid=0x6d7 runnable [0x] java.lang.Thread.State: RUNNABLE "C1 CompilerThread1" #7 daemon prio=9 os_prio=0 tid=0x00f9 nid=0x6d6 waiting on condition [0x] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #6 daemon prio=9 os_prio=0 tid=0x00f98800 nid=0x6d4 waiting on condition [0x] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00ebf800 nid=0x6d0 waiting on condition [0x] java.lang.Thread.State: RUNNABLE "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00e95000 nid=0x6c9 in Object.wait() [0x7f26e4c2d000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xc0166a10> (a java
[Bug 63251] [JDK-8194653] Deadlock in FileSystems.getDefault on catalina startup
https://bz.apache.org/bugzilla/show_bug.cgi?id=63251 --- Comment #4 from Mark Thomas --- It would be worth testing with Java 8 u231 when released - it is reported as fixed in that version. Meanwhile, you can see if the Spring Boot team is willing to add the workaround to Boot. -- 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
[GitHub] [tomcat] markt-asf commented on a change in pull request #209: BZ 63778: Jre7Compat cannot find getPseudoColumns with zero parameters
markt-asf commented on a change in pull request #209: BZ 63778: Jre7Compat
cannot find getPseudoColumns with zero parameters
URL: https://github.com/apache/tomcat/pull/209#discussion_r329665560
##
File path: java/org/apache/tomcat/util/compat/Jre7Compat.java
##
@@ -32,6 +36,9 @@
class Jre7Compat extends JreCompat {
+private static final Log log = LogFactory.getLog(Jre7Compat.class);
+private static final StringManager sm =
StringManager.getManager(Jre7Compat.class);
Review comment:
No. It should be `sm` for consistency with the rest of the Tomcat code base.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1867788 - /tomcat/site/trunk/docs/presentations.html
Author: schultz Date: Mon Sep 30 17:40:46 2019 New Revision: 1867788 URL: http://svn.apache.org/viewvc?rev=1867788&view=rev Log: Update presentations display HTML. Modified: tomcat/site/trunk/docs/presentations.html Modified: tomcat/site/trunk/docs/presentations.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/presentations.html?rev=1867788&r1=1867787&r2=1867788&view=diff == --- tomcat/site/trunk/docs/presentations.html (original) +++ tomcat/site/trunk/docs/presentations.html Mon Sep 30 17:40:46 2019 @@ -269,14 +269,80 @@ mailing list. +State of the Cat, New ! - Rémy Maucherat, +https://drive.google.com/open?id=1A9RbmALoDDpkUXyyfbpZCMoP5KEZ2yNB";>slides, +https://www.youtube.com/watch?v=_W2FK7raGMI";>video + + + + Let's Encrypt Apache Tomcat - Christopher Schultz, -https://people.apache.org/~schultz/ApacheCon%20NA%202019/Let's%20Encrypt%20Apache%20Tomcat.pdf">slides +https://people.apache.org/~schultz/ApacheCon%20NA%202019/Let's%20Encrypt%20Apache%20Tomcat.pdf">slides, +https://www.youtube.com/watch?v=BWUjvmJgSeE";>video + + + + +Tips for Debugging Tomcat and Web Applications - Coty Sutherland, +https://people.apache.org/~csutherl/ApacheCon%20NA%202019/Tips%20for%20Debugging%20Tomcat%20and%20Web%20Applications%20(2019).pdf">slides, +https://www.youtube.com/watch?v=taKWjPeIbIM";>video + + + + +Serving Clean URLs via Custom Internet Media Types on Tomcat - Garret Wilson, +https://www.youtube.com/watch?v=kkVWdyD4L-Q";>video Locking-Down Apache Tomcat - Christopher Schultz, -https://people.apache.org/~schultz/ApacheCon%20NA%202019/Locking-Down%20Apache%20Tomcat.pdf";>slides +https://people.apache.org/~schultz/ApacheCon%20NA%202019/Locking-Down%20Apache%20Tomcat.pdf";>slides, +https://www.youtube.com/watch?v=1H9y7k3llFc";>video + + + + +Tomcat from a cluster to a cloud - Jean-Frederic Clere, +https://www.youtube.com/watch?v=gDSl1FOAXOk";>video + + + + +Apache Tomcat, your webapp, and the Graal - Rémy Maucherat, +https://drive.google.com/open?id=1tFFEeZ4ks7U-vLsJQ8Eli3sHgfhJ_bNW";>slides, +https://www.youtube.com/watch?v=b_FwPW9ivkc";>video + + + + +Packaging Tomcat for Linux Distributions - Coty Sutherland, +https://people.apache.org/~csutherl/ApacheCon%20NA%202019/Packaging%20Tomcat%20for%20Linux%20Distributions%20(2019).pdf">slides, +https://www.youtube.com/watch?v=yyx5e83DOgc";>video + + + + +HTTP/2, HTTP/3 and SSL/TLS State of Art in Our Servers - Jean-Frederic Clere, +https://www.youtube.com/watch?v=3o6r1c5GI3g";>video + + + + +Apache Tomcat / HTTPD Configuration Management - Steve Sanders, +https://www.youtube.com/watch?v=c8aJW9LMDlE";>video + + + + +I Love Lucee - Igal Sapir, +https://www.youtube.com/watch?v=D6l8hyRdFII";>video + + +
[Bug 63791] New: Incomplete response + Exceptions thrown when using NIO adapter
https://bz.apache.org/bugzilla/show_bug.cgi?id=63791 Bug ID: 63791 Summary: Incomplete response + Exceptions thrown when using NIO adapter Product: Tomcat 9 Version: 9.0.26 Hardware: Macintosh Status: NEW Severity: normal Priority: P2 Component: Util Assignee: dev@tomcat.apache.org Reporter: erikbeerep...@hush.com Target Milestone: - Created attachment 36805 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36805&action=edit Minimal sample app demonstrating the issue Apologies for the somewhat vague title. I'm filing this as a Tomcat bug as tomcat appears to be throwing exceptions, any the tracing I've done points to an issue with the Nio and/or Nio2 implementation. If I'm wrong, please let me know and I'll go over to Spring. Here's my situation: - Using tomcat in a Spring Webflux app - Enabled Spring Actuator + Prometheus registry for metrics This was generated here: https://start.spring.io/ using the following parameters: - Gradle project - Kotlin as the language - Spring Boot 2.1.8 - Add webflux + actuator as deps Start the app, and start making requests to get the default spring metrics from prometheus: curl -X GET http://localhost:8080/actuator/prometheus After a few requests, the client will display an error, typically: "Premature end of Content-Length delimited message body (expected: 8,705; received: 8,061)" In the logs, I see: 2019-09-30 15:34:08.867 ERROR 91885 --- [nio-8080-exec-4] o.a.coyote.http11.Http11NioProtocol : Error reading request, ignored java.lang.IllegalStateException: Calling [asyncOperation()] is not valid for a request with Async state [COMPLETING] at org.apache.coyote.AsyncStateMachine.asyncOperation(AsyncStateMachine.java:269) ~[tomcat-embed-core-9.0.24.jar:9.0.24] at org.apache.coyote.AbstractProcessor.dispatch(AbstractProcessor.java:203) ~[tomcat-embed-core-9.0.24.jar:9.0.24] at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53) ~[tomcat-embed-core-9.0.24.jar:9.0.24] at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:860) ~[tomcat-embed-core-9.0.24.jar:9.0.24] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1587) [tomcat-embed-core-9.0.24.jar:9.0.24] at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-9.0.24.jar:9.0.24] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_181] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_181] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-9.0.24.jar:9.0.24] at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181] 2019-09-30 15:34:08.868 INFO 91885 --- [nio-8080-exec-4] o.a.catalina.connector.CoyoteAdapter : Encountered a non-recycled request and recycled it forcedly. org.apache.catalina.connector.CoyoteAdapter$RecycleRequiredException: null at org.apache.catalina.connector.CoyoteAdapter.checkRecycled(CoyoteAdapter.java:525) [tomcat-embed-core-9.0.24.jar:9.0.24] at org.apache.coyote.http11.Http11Processor.recycle(Http11Processor.java:1329) [tomcat-embed-core-9.0.24.jar:9.0.24] at org.apache.coyote.AbstractProtocol$ConnectionHandler.release(AbstractProtocol.java:1055) [tomcat-embed-core-9.0.24.jar:9.0.24] at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:1023) [tomcat-embed-core-9.0.24.jar:9.0.24] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1587) [tomcat-embed-core-9.0.24.jar:9.0.24] at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-9.0.24.jar:9.0.24] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_181] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_181] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-9.0.24.jar:9.0.24] at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181] It appears the magic size is 8192 (as indicated in the message). If I turn off metrics such that the payload is below this size, none of these errors occur. It appears this coincides with some configurable tomcat socket params such as "socket.appReadBufSize" though tweaking those values had no effect. I've attached a minimal sample app. Let me know if there's any further information to provide. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.
