[Bug 65397] NullPointerException during jar scanning with jar symlinked into WEB-INF/lib
https://bz.apache.org/bugzilla/show_bug.cgi?id=65397 --- Comment #3 from Martin Knoblauch --- Hi, sorry, but I do not think this is completely fixed. When moving from 9.0.48 to 9.0.50, we get a nasty stack trace that is cured by adding There is definitely no warning about a mis-configuration as I would have expected from the 9.0.49 change log entry. We are using symbolic links on a few levels of our installation. There is no symbolic linking directly in WEB-INF/lib. So it seems to be somewhere else. Shall I open an new report? At the moment I do not have an easy reproducer. 18-Jul-2021 14:06:07.991 INFO [main] org.apache.myfaces.config.DefaultFacesConfigurationProvider.getClassloaderFacesConfig Reading config : jar:file:/net/ltsdm01/fs1/cb2/Portals/smgr2021.2 -GA-final-r10889/apache-tomcat-9.0.50/webapps/cb2/WEB-INF/lib/richfaces-a4j-4.5.1.Final.jar!/META-INF/behaviors-handler-delegate.faces-config.xml 18-Jul-2021 14:06:07.992 INFO [main] org.apache.myfaces.config.DefaultFacesConfigurationProvider.getContextSpecifiedFacesConfig Reading config /WEB-INF/sdm-facelets-config.xml 18-Jul-2021 14:06:08.024 SEVERE [main] org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces An error occured while initializing MyFaces: String index out of range: -25 java.lang.StringIndexOutOfBoundsException: String index out of range: -25 at java.base/java.lang.String.substring(String.java:1841) at org.apache.catalina.webresources.DirResourceSet.listWebAppPaths(DirResourceSet.java:175) at org.apache.catalina.webresources.StandardRoot.listWebAppPaths(StandardRoot.java:149) at org.apache.catalina.core.ApplicationContext.getResourcePaths(ApplicationContext.java:602) at org.apache.catalina.core.ApplicationContextFacade.getResourcePaths(ApplicationContextFacade.java:183) at org.apache.myfaces.context.servlet.ServletExternalContextImplBase.getResourcePaths(ServletExternalContextImplBase.java:142) at org.apache.myfaces.config.DefaultFacesConfigurationProvider.getFacesFlowFacesConfig(DefaultFacesConfigurationProvider.java:583) at org.apache.myfaces.config.DefaultFacesConfigurationMerger.getFacesConfigData(DefaultFacesConfigurationMerger.java:111) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:474) at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:416) at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:172) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:119) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4768) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5230) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1398) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1388) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:921) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1398) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1388) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:921) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:263) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:437) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.co
[Bug 65397] NullPointerException during jar scanning with jar symlinked into WEB-INF/lib
https://bz.apache.org/bugzilla/show_bug.cgi?id=65397 --- Comment #4 from Mark Thomas --- That is a regression in this fix and is tracked as bug 65433 -- 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 65455] after about 10 days ago, tomcat8.5.63 can't response web request again
https://bz.apache.org/bugzilla/show_bug.cgi?id=65455 Mark Thomas changed: What|Removed |Added OS||All Status|NEW |NEEDINFO --- Comment #1 from Mark Thomas --- It looks like Tomcat is reaching the maxConnections limit. Given the low usage of the system, it looks like some connection closures are being missed. If this analysis is correct, the finding the root cause is going to be a lot easier if we can recreate the issue. The default value for maxConnections is 1. Can you try reducing, the lower the better, and then try reproducing the issue? That should trigger the issue faster and may provide some clues as to which connection closures are being missed. What is the nature of the web application where this is observed? Does is use the Servlet async API? Does it use the Servlet non-blocking API? Does it use WebSocket? Try switching to the NIO connector. The performance of NIO and NIO2 is very similar is most circumstances. Testing with the latest 8.5.x release would also be helpful. -- 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 65455] after about 10 days ago, tomcat8.5.63 can't response web request again
https://bz.apache.org/bugzilla/show_bug.cgi?id=65455 --- Comment #2 from 13998197...@163.com --- (In reply to Mark Thomas from comment #1) > It looks like Tomcat is reaching the maxConnections limit. Given the low > usage of the system, it looks like some connection closures are being > missed. If this analysis is correct, the finding the root cause is going to > be a lot easier if we can recreate the issue. > > The default value for maxConnections is 1. Can you try reducing, the > lower the better, and then try reproducing the issue? That should trigger > the issue faster and may provide some clues as to which connection closures > are being missed. > > What is the nature of the web application where this is observed? Does is > use the Servlet async API? Does it use the Servlet non-blocking API? Does it > use WebSocket? > > Try switching to the NIO connector. The performance of NIO and NIO2 is very > similar is most circumstances. > > Testing with the latest 8.5.x release would also be helpful. First of all, THANK YOU for your help!! I failed to recreate the issue by using jmeter and hping3, even if use hping3 mock flood attack. I use command 'netstat -nat|grep 8080|wc -l' to stat connections when issue happens, it's 108, and server load is very light, 3-5 req/second, so I think the reason is not maxConnections limit. By the way, client lib is using httpClient, it's timeout param set to 10s. I think, client and server's time out param cause the issue. -- 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 65433] Possible StringIndexOutOfBoundsException for symlinks in DirResourceSet.listWebAppPaths
https://bz.apache.org/bugzilla/show_bug.cgi?id=65433 --- Comment #2 from Martin Knoblauch --- FWIW: I can confirm that the fix solves my observed problems as well -- 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 65455] after about 10 days ago, tomcat8.5.63 can't response web request again
https://bz.apache.org/bugzilla/show_bug.cgi?id=65455 --- Comment #3 from 13998197...@163.com --- Created attachment 37962 --> https://bz.apache.org/bugzilla/attachment.cgi?id=37962&action=edit wireshark's screen shot, stream normal and abnormal The picture is wireshark's screen shot -- 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 65397] NullPointerException during jar scanning with jar symlinked into WEB-INF/lib
https://bz.apache.org/bugzilla/show_bug.cgi?id=65397 --- Comment #5 from Martin Knoblauch --- Thanks for clarifying. -- 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 65455] after about 10 days ago, tomcat8.5.63 can't response web request again
https://bz.apache.org/bugzilla/show_bug.cgi?id=65455 --- Comment #4 from Mark Thomas --- The thread dump you provided shows that Tomcat is blocking new connections because the maxConnections limit has been reached. This means that Tomcat isn't tracking completed connections correctly but finding out where this is going wrong is non-trivial. If the average number of concurrent requests is low, you should be able to reduce maxConnections significantly. If reaching the maxConnections limit is the problem, the problem should trigger a lot faster than ~10 days with a lower limit. I'd suggest setting to to 100. It should trigger in a few hours. Confirming that the issue is related to reaching maxConnections is the first step towards a fix. Please answer the following questions: 1. What is the impact of reducing maxConnections to 100? 2. What is the impact of switching from NIO2 to NIO (with maxConnections="100") ? 3. What is the impact of using NIO2 with maxConnections="-1" ? 4. What is the nature of the web application where this is observed? Does is use the Servlet async API? Does it use the Servlet non-blocking API? Does it use WebSocket? 5. Does this issue still occur with NIO2, maxConnections="100" and the latest 8.5.x release? By all means provide us with additional information you think might be helpful but if you don't also provide answers to the questions we ask, we are unlikely to be able to help. -- 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 65408] tomcat8.5.X occurs an AssertionError occationally after running for a period of time
https://bz.apache.org/bugzilla/show_bug.cgi?id=65408 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #9 from Mark Thomas --- Both the stack traces in the bug description are consistent with attempting to use a request object that has already been recycled. While that might be a Tomcat bug, it is typically cased by applications retaining references to requests, responses etc and attempting to use the objects after they are no longer valid. Unless a test case is provided that can be used to recreate this bug, it will eventually get resolved as WORKSFORME. -- 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
