Re: Apache Tomcat 8.5.49 - StackOverflowError when getting static resources
" On 27/11/2019 23:40:27, ma...@apache.org wrote: > Sorry to be a pain but could you test again? I've updated the 9.0.30-dev > > build and added 8.5.50-dev here: > > > > http://people.apache.org/~markt/dev/ > > > > The last patch went to far and essentially complete undid the original > > fix rather than keeping the original fix and fixing the regression you saw. > > > > If you could download, test and report back that would be very helpful. > > > > Note: > > - this is NOT an official release > > - this is NOT for production use > > - this is ONLY for testing this bug > > - please don't blame me if your server catches fire during testing ;) > > > > (Sorry to go on about this but ASF releases have various bits of QA and > > legal machinery behind them whereas test/dev builds like this don't and > > we need to make sure folks reading this understand there is a difference.) > > > > Thanks, > > > > Mark Hello Mark, no problem, thanks that I could test it also with 8.5 version. With your build Apache Tomcat/8.5.50-dev issue also disapeared. Jan "
RE: FW: tomcat creating new ssl session id for same session
Highly Restricted - Confidential Thanks for your prompt reply. Please find my response inline. -Original Message- From: Christopher Schultz Sent: Wednesday, November 27, 2019 11:15 PM To: users@tomcat.apache.org Subject: Re: FW: tomcat creating new ssl session id for same session -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rekha, On 11/27/19 05:15, rekha...@dell.com wrote: > I am using javax.servlet.request.ssl_session_id for session > validation. But tomcat creating new ssl session id and user session > validation is failing. How are you performing the validation? Rekha MS: Ssl_session_id is used for validation. What is the order-of-events that you are observing? Rekha MS : Ssl_session_id is same for some requests and then it changes after some time. What version of Tomcat, and what kind of are you using? Rekha MS: Tomcat 8.5.15 , Nio connector(Http11NioProtocol to be specific) > Please let me know when tomcat creates new ssl session id and how by > mandate it to use same ssl session id for same user session TLS session ids must change periodically when certain renegotiations occur. This is actually a security feature. I'm not sure it is possible to disable it entirely Rekha MS: what triggers these renegotiations? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3etiEACgkQHPApP6U8 pFiKsg/+MSt/JOsbkOtL/x9z9RDV85HQtj3oQK6GQY5bp66ZTsZZugkwEbUdg8wb 3IDrw4qYuuyGs+PXqqjKwd76Td9EVWYBUEbtw3HPmOx2g0g3XsfTEgKetMRSyJrh Xh6vTFb9PPwlR1Lozv+OAkQXIradAZUXxHxWY6lcR1ox1X8A8VlnzTKA1oPBL+qk 1q6coOcNuhSJ2DjFFCmaBBp75qBQMFRvcIQacChQEfT1oFdFWkt22L8tmwLF3bKZ gb8Tc4ohDkwWZUeSeiq6p6dIN8LhK7q40rJH3akEwQJGrD3dPoSojwGiLKXvOMkj 2czFC4SdJ6MJnjxh57LvKlcxwIP+heEIpF1lscGjfZn+sSzzVDRLZkgkV0hXF4aG uDIKLvETzW88mE4ddfxHICf6IAsLcz6aSR2TaGlJdNgNnsbOooLJc6+cyoA3M1oc 1FpvyzSZsckKpA6KRKqOtNlvveDSgtrTr7EmgK0a2pjAiaq69zxttGfyyOwcKIQw aozuJBRH4mtP1HAT+4EKeUAUHtuPUXeGMJwoFa4MDMu2+HT9krIFB9kcixDuPy5k 6CFfPkXcVCN+XcChWYrI9HJ0vKRh0DzVVEB14RG/8V+oSXUM0+imJdC2I4QFBI0r y1ssOJkam+ZzP+fc5Mz1v/hbbLmX2Y1pe4d/FLNF91l+IXRsKOY= =J9i5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat 8.5.49 - StackOverflowError when getting static resources
On 27/11/2019 19:21, jan.a...@seznam.cz wrote: > Many thanks Mark. It seems fix works correctly. > > Because I observed the issue on version 8.5.49 and your build is version 9.0 > I installed Apache Tomcat/9.0.29 and observed not the same error but very > similar. It was also StackOverflow and contained recursive > DefaultFaceletContext.includeFacelet() method calls. > So I installed your build and got to login page without issue. > Thanks for your fast reaction and solution. > Will be this fix also for 8.5.50 release version? Sorry to be a pain but could you test again? I've updated the 9.0.30-dev build and added 8.5.50-dev here: http://people.apache.org/~markt/dev/ The last patch went to far and essentially complete undid the original fix rather than keeping the original fix and fixing the regression you saw. If you could download, test and report back that would be very helpful. Note: - this is NOT an official release - this is NOT for production use - this is ONLY for testing this bug - please don't blame me if your server catches fire during testing ;) (Sorry to go on about this but ASF releases have various bits of QA and legal machinery behind them whereas test/dev builds like this don't and we need to make sure folks reading this understand there is a difference.) Thanks, Mark > > Jan > > For info there is snipet of 9.0.29 log error: > > Caused by: java.lang.StackOverflowError > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader$3.next(Unknown Source) > at java.net.URLClassLoader$3.hasMoreElements(Unknown Source) > at sun.misc.CompoundEnumeration.next(Unknown Source) > at sun.misc.CompoundEnumeration.hasMoreElements(Unknown Source) > at sun.misc.CompoundEnumeration.next(Unknown Source) > at sun.misc.CompoundEnumeration.hasMoreElements(Unknown Source) > at sun.misc.CompoundEnumeration.next(Unknown Source) > at sun.misc.CompoundEnumeration.hasMoreElements(Unknown Source) > at > org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.inc(WebappClassLoaderBase.java:2701) > at > org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.hasMoreElements(WebappClassLoaderBase.java:2686) > at java.util.ServiceLoader$LazyIterator.hasNextService(Unknown Source) > at java.util.ServiceLoader$LazyIterator.hasNext(Unknown Source) > at java.util.ServiceLoader$1.hasNext(Unknown Source) > at javax.xml.parsers.FactoryFinder$1.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at javax.xml.parsers.FactoryFinder.findServiceProvider(Unknown Source) > at javax.xml.parsers.FactoryFinder.find(Unknown Source) > at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) > at com.sun.faces.util.Util.createSAXParserFactory(Util.java:297) > at > com.sun.faces.facelets.compiler.SAXCompiler.createSAXParser(SAXCompiler.java:527) > at > com.sun.faces.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:463) > at > com.sun.faces.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:440) > at com.sun.faces.facelets.compiler.Compiler.compile(Compiler.java:124) > at > com.sun.faces.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:481) > at > com.sun.faces.facelets.impl.DefaultFaceletFactory.access$100(DefaultFaceletFactory.java:106) > at > com.sun.faces.facelets.impl.DefaultFaceletFactory$1.newInstance(DefaultFaceletFactory.java:199) > at > com.sun.faces.facelets.impl.DefaultFaceletFactory$1.newInstance(DefaultFaceletFactory.java:197) > at > com.sun.faces.facelets.impl.DefaultFaceletCache$1.newInstance(DefaultFaceletCache.java:86) > at > com.sun.faces.facelets.impl.DefaultFaceletCache$1.newInstance(DefaultFaceletCache.java:81) > at > com.sun.faces.util.ExpiringConcurrentCache$1.call(ExpiringConcurrentCache.java:99) > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat 8.5.49 - StackOverflowError when getting static resources
On 27/11/2019 13:14:02, ma...@apache.org wrote: >On 27/11/2019 06:27, jan.a...@seznam.cz wrote: > > > >> "On 26/11/2019 16:34, Mark Thomas wrote: > >>> I don't think so. More likely this is another instance of > >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=63964 > >> > >> I think I have a fix for this. Are you able to build from source to test > >> this once I commit the fix? If you aren't able to build from source, > >> would it help if I provided a binary build? > >> > >> Mark > >> > >> Thank you for you answers. > >> > >> @Mark: It would help if you provide binary build, I'll test it. > > > >Thanks great. Thanks. > > > >You can pick up a 9.0.30-dev build from: > >http://people.apache.org/~markt/dev/v9.0.30-dev/ > > > >Note: This is just to enable this fix to be tested. It isn't a formal > >release. Use it at your own risk. If you machine catches fire don't > >blame me > > > >Thanks, > > > >Mark > > > >- > >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >For additional commands, e-mail: users-h...@tomcat.apache.org Many thanks Mark. It seems fix works correctly. Because I observed the issue on version 8.5.49 and your build is version 9.0 I installed Apache Tomcat/9.0.29 and observed not the same error but very similar. It was also StackOverflow and contained recursive DefaultFaceletContext.includeFacelet() method calls. So I installed your build and got to login page without issue. Thanks for your fast reaction and solution. Will be this fix also for 8.5.50 release version? Jan For info there is snipet of 9.0.29 log error: Caused by: java.lang.StackOverflowError at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader$3.next(Unknown Source) at java.net.URLClassLoader$3.hasMoreElements(Unknown Source) at sun.misc.CompoundEnumeration.next(Unknown Source) at sun.misc.CompoundEnumeration.hasMoreElements(Unknown Source) at sun.misc.CompoundEnumeration.next(Unknown Source) at sun.misc.CompoundEnumeration.hasMoreElements(Unknown Source) at sun.misc.CompoundEnumeration.next(Unknown Source) at sun.misc.CompoundEnumeration.hasMoreElements(Unknown Source) at org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.inc(WebappClassLoaderBase.java:2701) at org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.hasMoreElements(WebappClassLoaderBase.java:2686) at java.util.ServiceLoader$LazyIterator.hasNextService(Unknown Source) at java.util.ServiceLoader$LazyIterator.hasNext(Unknown Source) at java.util.ServiceLoader$1.hasNext(Unknown Source) at javax.xml.parsers.FactoryFinder$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at javax.xml.parsers.FactoryFinder.findServiceProvider(Unknown Source) at javax.xml.parsers.FactoryFinder.find(Unknown Source) at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) at com.sun.faces.util.Util.createSAXParserFactory(Util.java:297) at com.sun.faces.facelets.compiler.SAXCompiler.createSAXParser(SAXCompiler.java:527) at com.sun.faces.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:463) at com.sun.faces.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:440) at com.sun.faces.facelets.compiler.Compiler.compile(Compiler.java:124) at com.sun.faces.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:481) at com.sun.faces.facelets.impl.DefaultFaceletFactory.access$100(DefaultFaceletFactory.java:106) at com.sun.faces.facelets.impl.DefaultFaceletFactory$1.newInstance(DefaultFaceletFactory.java:199) at com.sun.faces.facelets.impl.DefaultFaceletFactory$1.newInstance(DefaultFaceletFactory.java:197) at com.sun.faces.facelets.impl.DefaultFaceletCache$1.newInstance(DefaultFaceletCache.java:86) at com.sun.faces.facelets.impl.DefaultFaceletCache$1.newInstance(DefaultFaceletCache.java:81) at com.sun.faces.util.ExpiringConcurrentCache$1.call(ExpiringConcurrentCache.java:99) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FW: tomcat creating new ssl session id for same session
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rekha, On 11/27/19 05:15, rekha...@dell.com wrote: > I am using javax.servlet.request.ssl_session_id for session > validation. But tomcat creating new ssl session id and user > session validation is failing. How are you performing the validation? What is the order-of-events that you are observing? What version of Tomcat, and what kind of are you using? > Please let me know when tomcat creates new ssl session id and how > by mandate it to use same ssl session id for same user session TLS session ids must change periodically when certain renegotiations occur. This is actually a security feature. I'm not sure it is possible to disable it entirely - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3etiEACgkQHPApP6U8 pFiKsg/+MSt/JOsbkOtL/x9z9RDV85HQtj3oQK6GQY5bp66ZTsZZugkwEbUdg8wb 3IDrw4qYuuyGs+PXqqjKwd76Td9EVWYBUEbtw3HPmOx2g0g3XsfTEgKetMRSyJrh Xh6vTFb9PPwlR1Lozv+OAkQXIradAZUXxHxWY6lcR1ox1X8A8VlnzTKA1oPBL+qk 1q6coOcNuhSJ2DjFFCmaBBp75qBQMFRvcIQacChQEfT1oFdFWkt22L8tmwLF3bKZ gb8Tc4ohDkwWZUeSeiq6p6dIN8LhK7q40rJH3akEwQJGrD3dPoSojwGiLKXvOMkj 2czFC4SdJ6MJnjxh57LvKlcxwIP+heEIpF1lscGjfZn+sSzzVDRLZkgkV0hXF4aG uDIKLvETzW88mE4ddfxHICf6IAsLcz6aSR2TaGlJdNgNnsbOooLJc6+cyoA3M1oc 1FpvyzSZsckKpA6KRKqOtNlvveDSgtrTr7EmgK0a2pjAiaq69zxttGfyyOwcKIQw aozuJBRH4mtP1HAT+4EKeUAUHtuPUXeGMJwoFa4MDMu2+HT9krIFB9kcixDuPy5k 6CFfPkXcVCN+XcChWYrI9HJ0vKRh0DzVVEB14RG/8V+oSXUM0+imJdC2I4QFBI0r y1ssOJkam+ZzP+fc5Mz1v/hbbLmX2Y1pe4d/FLNF91l+IXRsKOY= =J9i5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CPU high usage, the reason org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mladen, On 11/26/19 15:49, Mladen Adamović wrote: > Our setup is documented here: > https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with- ssl-on-ubuntu-minimal/ When > I read it in your documentation, I assumed it was just out-of-date, so I went back to your posts to check: you are using a really old version of Tomcat. Your version is 8.5.5 which was released back on 2016-09-05. The current version is 8.5.49 which was released this past week. In the intervening years, there have been many improvements. I browsed the changelog but don't see anything specific that might explain and/or fix your issue. I may not be looking carefully enough. There have also been a bunch of security advisories[1] since you version. If you are worried about DDOS, you might want to read through those. > It wasn't easy for me to configure https/tomcat/letsencrypt... Really? I realize it's just as simple as "just type encrypt and press enter" but it's relatively straightforward if you understand all the pieces and how they fit together. Have a look at http://tomcat.apache.org/presentations.html#latest-lets-encrypt if you'd like more information. - -chris [1] http://tomcat.apache.org/security-8.html >> [1] https://en.wikipedia.org/wiki/Busy_waiting >> >>> On Tue, Nov 26, 2019 at 4:50 PM Christopher Schultz < >>> ch...@christopherschultz.net> wrote: >>> >>> Mladen, >>> >>> On 11/25/19 14:36, Mladen Adamović wrote: >> On Mon, Nov 25, 2019 at 5:57 PM Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> We certainly want to be able to serve 1 hits per second (!), while some connections might be stalled. >>> >>> What might stall a connection? The network, or the >>> application (or database, etc.)? >>> >> >> Underlying (synchronized) monitors could stall every >> thread, the network, whatever. >> >> The network itself demands a large number of connection, >> i.e. current situation at the server (displaying only >> remove connections): >> >> root@condor1796 ~ # netstat -tnp | grep -v "127.0.0" | wc >> -l 1220 >>> >>> Note this is every connection, bound port, and cleanup >>> connection the kernel knows about ; not just established/active >>> connections to your application specifically. >>> >> If we now have 1220, we definitely need at least 1 >> active connections for Tomcat and I don't see that >> setting this to 5 is a bad idea. >>> >>> Okay. I think you need a reverse proxy and more servers if you >>> think 5 is going to be your peak load. >>> >>> For real DDOS protection, you need a provider who can >>> handle lots of traffic and respond quickly by >>> black-holing that kind of traffic as >> >> Depending on how large server farm they use >> (hypothetically). We want to be able to survive some DDoS >> attacks. If we limit the number of concurrent connections >> by IP address and the number of connections per second, >> that's some DoS protection. >>> >>> But honestly, this is better done at another layer of the >>> network; not at the host-level. >>> >> Regarding network delays, out of currently 1220 active >> remove connections, most of them are in TIME_WAIT state. >> Lowering TIME_WAIT settings in Linux are not >> recommended. >>> >>> Hmm. Lots of TIME_WAIT connections isn't good. I actually >>> don't know if they count "against" your 5 limit in the Java >>> process. >>> >>> -chris --- - -- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> -BEGIN PGP SIGNATURE- Comment: Using GnuPG with >> Thunderbird - https://www.enigmail.net/ >> >> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3ddD8ACgkQHPApP6U8 >> pFjTJBAAuWpntlG9XFNS90GpJc3SWWeOPFQmJN8FTrQNPhJ49sPlk6aOgTbujGwS >> eHxQI2NIpgeP0MDqEKWEotOfxn+wwxUMJKOKnuxyxbDU8CGytJ4UwBJ5CddnsA5T >> QaIbANdoGI2+K+9v5jjlbv97DK2Vz/dh92v7QaKdJjND/ql61i7g/ZfBnJJmSZSE >> ScwVlexuYdG+izy2Vr1PX2lSltMeI+7Dth5JkyhHFVbw1wGF9qZsQ4rsszRKO0ZB >> jPrCK2VmHNUcYQNG1q0Gi9bzAUI67fHoaJjmRIU3A8PtoFMehIomKn8HkgBrc9aQ >> kmtb7BPxD63VcTK2rVGuMfa5y70AWB2hPcvUtKAO7CBC7LyC9/ux2jZqNTxMVUH6 >> wkxIkeQklLYpSDeI0E2xwxiH4OPakP2kZABp2zXH5JyfRQljlnbchWg/gT3DrCck >> lDt0ZmZPEfz792Pw8K/vJ4ZZre2BuQXRZhL3XvQUyWMHkHO3XTuWsJ2beaXzbo8E >> qFrrU0iXdErC6TT00V75t3MUQWto3Zrvb7Y/n8k3rh4X3pfblUQw6z1mojZui6Ik >> XZ4qrWkR9unxYHlMuaYOg3e9Ug67UHgUVM+Vvj3tlI81nJrDw8ikbVDHJ2R6R5Ft >> SqZoM7i+Y0i02jH0hpNAukFlw3Vdig1YmoPciAvCJcbZkJDU96E= =bUtP >> -END PGP SIGNATURE- >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail:
Re: Apache Tomcat 8.5.49 - StackOverflowError when getting static resources
On 27/11/2019 06:27, jan.a...@seznam.cz wrote: > "On 26/11/2019 16:34, Mark Thomas wrote: >> I don't think so. More likely this is another instance of >> https://bz.apache.org/bugzilla/show_bug.cgi?id=63964 > > I think I have a fix for this. Are you able to build from source to test > this once I commit the fix? If you aren't able to build from source, > would it help if I provided a binary build? > > Mark > > Thank you for you answers. > > @Mark: It would help if you provide binary build, I'll test it. Thanks great. Thanks. You can pick up a 9.0.30-dev build from: http://people.apache.org/~markt/dev/v9.0.30-dev/ Note: This is just to enable this fix to be tested. It isn't a formal release. Use it at your own risk. If you machine catches fire don't blame me Thanks, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Error after upgrading to Tomcat 9.0.29
On 26/11/2019 21:22, Juri Berlanda wrote: > Hi, > > I never built Tomcat from source, but I guess there is a first time for > everything :-) > > I'm out of office tomorrow, but I will give it a shot on Thursday and > let you know how it went. Where can I find the source with the fix? https://github.com/apache/tomcat (master branch) Alternatively, you can pick up a 9.0.30-dev build from: http://people.apache.org/~markt/dev/v9.0.30-dev/ Note: This is just to enable this fix to be tested. It isn't a formal release. Use it at your own risk. If you machine catches fire don't blame me ;) Thanks, Mark > > Cheers, > > Juri > > On 11/26/19 7:01 PM, Mark Thomas wrote: >> On 26/11/2019 16:35, Mark Thomas wrote: >>> On 25/11/2019 19:17, Juri Berlanda wrote: Hi all, I post my Stacktrace again, as I mistakenly previously only sent it to Rémy Maucherat. I'll try to make it as short as possible: >>> Maybe a cariation of: >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=63964 >>> ? >> I think I have a fix for this. Are you able to build from source to test >> this once I commit the fix? If you aren't able to build from source, >> would it help if I provided a binary build? >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
FW: tomcat creating new ssl session id for same session
Hi , I am using javax.servlet.request.ssl_session_id for session validation. But tomcat creating new ssl session id and user session validation is failing. Please let me know when tomcat creates new ssl session id and how by mandate it to use same ssl session id for same user session Thanks, Rekha MS
