Re: Not running on Jetty, JSR-356 support unavailable
Hi Chris, I am running tomcat and keeping the jetty-all-9.4.19.v20190610-uber.jar inside tomcat\lib. I do not need websockets functionality. But I'm not getting a way to disable it so that it can work fine with tomcat. Thanks Naveen On Mon, Nov 25, 2019 at 9:37 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Naveen, > > On 11/25/19 04:21, Naveen Kumar wrote: > > I am trying to upgrade ActiveMQ jar to its latest version. It > > requires me to upgrade Jetty to 9.4 version. I have current setup > > as Tomcat 9 + ActiveMQ 5.12 + jetty-all-8.1. I want to upgrade it > > as Tomcat 9 + ActiveMQ 5.15 + jetty-all-9.4. > > > > After doing the changes when I try to start tomcat, it gives me > > below error: > > > > javax.servlet.ServletException: Not running on Jetty, JSR-356 > > support unavailable at > > org.eclipse.jetty.websocket.jsr356.server.deploy.WebSocketServerContai > nerInitializer.onStartup(WebSocketServerContainerInitializer.java:200) > > > > > at > > org.apache.catalina.core.StandardContext.startInternal(StandardContext > .java:5125) > > > > It looks like Jetty 9.4 has JSR-356 implementation and it is > > conflicting with Tomcat. Can someone please help to fix this ? > > This sounds like a question for Jetty, not for Apache Tomcat. > > How are you running Tomcat ... with Jetty? Or Jetty with Tomcat? > > Would you like to use the Jetty version of JSR-356 (better known as > WebSocket) of the Tomcat version? > > Be aware of the exact version of Jetty you are running. Some versions > of 9.4.x have published vulnerabilities. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3b/BsACgkQHPApP6U8 > pFjUBRAAwqrg7yYRzNFeFB9lX+zJZ8aIvWRGmbHftw0S4JSIZltHb6+cvi1wLHAA > R03zau14niYLHZ9ZqDsBIXxoVD07djrdCXb2lNS8ANku9dcP/JD1Vn7PmfPxzuWf > 5ZckluKDnutKIeAVE0BA1GmnLFoYmxQ1CK4yWnBAFNkGu/SVF4aiU7Mwu71VOFBO > O8b7whIvw7kdLqPjkEFAe5KcCaxxEqa/334cVbFTAZEHU5YmELR7r96S0x/Ekcii > EXa6h1DNjulGgCKzr72OB7XgdihZOuR6gABJV1rKBODvV+QBPqpA2/s1038vHQoK > WA/bfxp1eMgLFGOoylMgClvdxCFZs9a0AAZXqZhf/yJHgD/qg34o8y3Lz12lSJcV > MWUNujBxsb1/qVoyBkwramqPulC1rVM01wDwOiUc+xtuZsP8611jDoqAsc7pAjQt > bxN4VvVp8/WZFoYrbDJNhUiVdURLuTCGH+FZ6kz0hsbBf3zuAT+wVjP4Lp0Zfisb > VuYYN7eFbcZW1ATpK3oK40kLtJNZiHt1RduO6/zg5MvcZ2VzXPcvJpEJDAtzvQHs > YTV7lHOsFStHM1Kvt8mInHBGUbr6PZcDVRyf/HVcK4/fcAC8Z9H25z9VTXG9R10R > uUvyzbep/SCUUNhH0oAeIWACzI9g7/r429TdreAfzi5BoYIsCpg= > =8QAg > -END PGP SIGNATURE- > > - > 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 26/11/2019 16:34, Mark Thomas wrote: >> Jan, >> >> On 11/26/19 09:20, jan.a...@seznam.cz wrote: >>> with update of Tomcat to version 8.5.49 we observed issue in our >>> application when accessing login page. >> >> Sounds suspiciously familiar: >> https://markmail.org/message/7xfg5x7mllrki3hd >> >> This was for a recent Tomcat 9.0 release, not 8.5, but it: >> >> 1. Is a stack overflow >> 2. Involves MyFaces >> >>> Application log contains StackOverflowError. There is recursive >>> call of CompositionHandler.apply() method. >> >> Note that MyFaces is not a Tomcat artifact, though it does come from >> Apache. >> >>> It seems that issue is connected with resource caching because when >>> I set resources attribute cachingAllowed="false" in application >>> xml, issue disappears. >> >> That is very good information. >> >>> Could it be caused by fix of Bug 63872? > > 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org " Thank you for you answers. @Mark: It would help if you provide binary build, I'll test it. " "
Re: Error after upgrading to Tomcat 9.0.29
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? 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
Re: CPU high usage, the reason org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run
Hi Chris, On Tue, Nov 26, 2019 at 7:51 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > You never actually said what your definition of "high CPU usage" was. > Are you looking at load-average? %-CPU usage from "top"? > I'm sorry if I wasn't clear enough, I meant high system load (which was according to top) and actually spending time in futex_wait kernel function most of the time. > Do you have the option of comparing your CPU usage when you use APR > versus NIO? I would expect your CPU usage to o *up* by switching from > APR to NIO due to two factors: > This is a production server and it would be a bad idea to compare APR vs NIO on it. > Do you have any scope to separate-out TLS termination from the > application server? That is, use a reverse-proxy for TLS termination > and proxy to another server that only handles the application logic? > You may find that TLS is just "expensive" in terms of CPU which, well, > is simply the truth. > Well, we could separate TLS from the application server by using adequate "proxy" in the future, but I don't see a reason why we would do it now. When we migrated from http to https CPU usage went up multiple times, so I agree that TLS is expensive. I've setup things years ago and I don't remember all the details why things are like that, but there are (probably) some reasons why things are like they are. Our setup is documented here: https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/ It wasn't easy for me to configure https/tomcat/letsencrypt... > [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= >
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 11:13, Mladen Adamović wrote: > I dig into Tomcat source code and from what I've seen this is what > happens: > > Tomcat "worker thread", tries the polls the work and if it doesn't > succeed it invokes sun.misc.Unsafe.park (that's waiting which can > be interrupted by another thread), internally in Linux goes through > kernel function FUTEX_WAIT (futex definition is " The futex() > system call provides a method for waiting until a certain condition > becomes true." This is usually the underlying JVM implementation doing all of this. I don't believe Tomcat calls Unsafe.park() directly. Theoretically, park() is a blocking call, so even if the thread reports that it is RUNNABLE it is really (effectively) BLOCKED, although it might be a slightly busy-wait[1]. > However, these futex_wait functions sums to top CPU load, although > I don't find it's actually load here, as per infamous Linux change > of 29 Oct 1993 by Matthias Urlichs: > http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html Well, > CPU load average doesn't tell the whole story. The real question is how much work is being done per unit time. If you are observing a performance *problem* then maybe we can look into that. But a high CPU load average itself doesn't represent anything worrying IMHO. If you have sustained high CPU load average, you probably need to be looking at scaling-out, anyway, but you might not have a performance problem ... yet. I have a medium-busy service running 2-3 distinct web applications on two application servers (~1k peak requests per minute in aggregate; that includes static resources being served by web servers without hitting Tomcat). The load-average on any given application server is usually well under the number of CPUs. We are running a 4.9.0 kernel and I'm not sure if the load-average is being scaled by the number of CPUs or not, but my 1/5/15 load averages are all under 1.0 right now, and the 13:00 hour (/now/ in my timezone) is when we start approaching our peak daily load. We have a very simple connector configuration which isn't much different than the default: We are using NIO (and not e.g. APR) for both connectors. The one with the most traffic is the AJP connector which maintains a bunch of (nominally) persistent connections from the small number of web servers. I have many threads that are blocked on I/O, such as the client poller for the HTTP connector: "http-nio-127.0.0.1-8017-ClientPoller-0" #49 daemon prio=5 os_prio=0 tid=0x7fc3901c4000 nid=0x74f runnable [0x7fc359325000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) - locked <0xd915c318> (a sun.nio.ch.Util$3) - locked <0xd915c308> (a java.util.Collections$UnmodifiableSet) - locked <0xd915c0c0> (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:825) at java.lang.Thread.run(Thread.java:748) Note that the thread state says "runnable" (and "RUNNABLE") but it's essentially blocked. The request-processing threads waiting for work are in a similar state: "catalina-exec-25" #44 daemon prio=5 os_prio=0 tid=0x7fc3901c2000 nid=0x74a waiting on condition [0x7fc35982a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xd915d3a0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.aw ait(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:4 42) at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:103) at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:31) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java: 1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav a:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja va:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThrea d.java:61) at java.lang.Thread.run(Thread.java:748) ... although this one says "parking"/"WAITING" which is a more appropriate description of what's happening. The above thread states can both be thought of as "asleep". So perhaps the "problem" isn't so much that you are seeing lots of threads in these states,
Re: Error after upgrading to Tomcat 9.0.29
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
Re: Apache Tomcat 8.5.49 - StackOverflowError when getting static resources
On 26/11/2019 16:34, Mark Thomas wrote: >> Jan, >> >> On 11/26/19 09:20, jan.a...@seznam.cz wrote: >>> with update of Tomcat to version 8.5.49 we observed issue in our >>> application when accessing login page. >> >> Sounds suspiciously familiar: >> https://markmail.org/message/7xfg5x7mllrki3hd >> >> This was for a recent Tomcat 9.0 release, not 8.5, but it: >> >> 1. Is a stack overflow >> 2. Involves MyFaces >> >>> Application log contains StackOverflowError. There is recursive >>> call of CompositionHandler.apply() method. >> >> Note that MyFaces is not a Tomcat artifact, though it does come from >> Apache. >> >>> It seems that issue is connected with resource caching because when >>> I set resources attribute cachingAllowed="false" in application >>> xml, issue disappears. >> >> That is very good information. >> >>> Could it be caused by fix of Bug 63872? > > 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Could not find worker with name 'ajp13_worker'
Hi Chris, the file workers.properties is the one i found after the libapache2-mod-jk installation (with aptitude)! I changed only the 2 lines with workers.tomcat_home and workers.java_home (that you said, they do nothing)... the directive : JkMount /* ajp13_worker is present in the VirtualHost of Apache : DocumentRoot "/var/www/vhosts/www.mydomain.com/ROOT" ServerName www.mydomain.com ServerAdmin i...@mydomain.com JkMount /* ajp13_worker JkLogLevel debug allow from all Options None Require all granted and Apache also load the httpd-jk.conf file to config some general directives of the connectors (and therefore also workers.properties.. JkWorkersFile /etc/libapache2-mod-jk/workers.properties) Roberto Il 26-11-2019 17:54 Christopher Schultz ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Roberto, On 11/26/19 09:58, Roberto Bottoni wrote: I have a Debian 10 server with Apache 2 + Tomcat 9. I can't run JSF pages due to an internal server error. I use OpenJDK v. 11, also use the Apache Tomcat Native library [1.2.23] (tomcat-native-1.2.23-src.tar.gz) using the APR version [1.7.0] (apr-1.7.0.tar.gz). Tomcat starts regularly and also Apache. If I open : http://www.mydomain.com i get Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request etc.. etc.. the site should be display the current date and time, but if I do : http://www.mydomain.com:8080 i see the page correctly! I think the error is in the Apache Tomcat connector (libapache2-mod-jk installed with "aptitude" command) .. This is my workers.properties file : Next time, please remove all the comments when posting configuration, unless they are particularly relevant. workers.tomcat_home=/usr/share/tomcat9 This directive does nothing. workers.java_home=/usr/lib/jvm/java-11-openjdk-amd64 This directive does nothing. ps=/ This directive does nothing. How old is this configuration? worker.list=ajp13_worker worker.ajp13_worker.port=8009 worker.ajp13_worker.host=localhost worker.ajp13_worker.type=ajp13 worker.ajp13_worker.lbfactor=1 worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=ajp13_worker Okay, so you have a worker called ajp13_worker and another one called loadbalancer which (a) balances to ajp13_worker but (b) isn't registered as a worker, so you can't JkMount to it. Keep that in mind. and this is my httpd-jk.conf (loaded by Apache) file : JkWorkersFile /etc/libapache2-mod-jk/workers.properties This is the file above, right? Double-check. JkWatchdogInterval 60 # Inside Location we can omit the URL in JkMount JkMount jk-status Require ip 127.0.0.1 You haven't defined a jk-status worker. This won't work. # Inside Location we can omit the URL in JkMount JkMount jk-manager Require ip 127.0.0.1 Nor will this. Your configuration is incomplete: you have no JkMounts defined, other than the invalid ones. So something is missing, because your configuration clearly shows that JkMounts are in effect: This is my mod_jk.log log file (I replaced my real domain with www.mydomain.com) [Mon Nov 25 16:40:11.684 2019] [1914:140619718063232] [debug] uri_worker_map_add::jk_uri_worker_map.c (848): wildchar rule '/*=ajp13_worker' source 'JkMount' was added So somewhere in your configuration, this line must be present: JkMount /* ajp13_worker [Mon Nov 25 16:40:11.684 2019] [1914:140619718063232] [debug] wc_get_worker_for_name::jk_worker.c (120): did not find a worker ajp13_worker That's not good. It appears to be in your configuration. My initial conclusion is that the file where you have defined ajp13_worker is not the file actually being used by mod_jk. the VirtualHost in Apache is : DocumentRoot "/var/www/vhosts/www.mydomain.com/ROOT" ServerName www.mydomain.com ServerAdmin i...@mydomain.com JkMount /* ajp13_worker Yup there it is. JkLogLevel debug Okay. I have a new Debian 10 server with Apache 2 + Tomcat 9. I can't run the JSF page due to an internal server error. I think the error is in the Apache Tomcat connector (libapache2-mod-jk) .. [snip: repeated configuration files] So, it seems that Apache cannot find "ajp13_worker" worker.. Why? Can you confirm that this file contains your configuration: /etc/libapache2-mod-jk/workers.properties - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3dWK0ACgkQHPApP6U8 pFggWRAAhd6GlMtBivtufplh5StspDDFkt6n/PUJuvIu8dWlkyXXMKqTNpfxwCQm SfK4hPbbL/caaocoG7xDYYBIBrq7juwdWQCBQFByS8WXXJrzDWU+wq86jVsg5Uw5 WVSzps6BAH4DcXb+jss/EIeeDW110eXy14COjJ70o+kDmNzBJvTxP8e75WHPq0pm JTiZKwnAHL6jNhuJhFF+V6LnZcnDz2yo63NQPVCTSdlxpHlGES2RXWFT/z6U5GnK xI+6R7WQAauQqWfMjNi32t3jySr6KV1CbVlwAE3FGWmGBEsOeb5AhSJ/aclKTsSy 768kfJL8tiTYraZcLBxT5jNChkHTa3lMh5JmeW2FSBerteNW1APRysHdPBZ6CgS2
Re: Could not find worker with name 'ajp13_worker'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Roberto, On 11/26/19 09:58, Roberto Bottoni wrote: > I have a Debian 10 server with Apache 2 + Tomcat 9. I can't run > JSF pages due to an internal server error. I use OpenJDK v. 11, > also use the Apache Tomcat Native library [1.2.23] > (tomcat-native-1.2.23-src.tar.gz) using the APR version [1.7.0] > (apr-1.7.0.tar.gz). Tomcat starts regularly and also Apache. > > If I open : http://www.mydomain.com > > i get Internal Server Error The server encountered an internal > error or misconfiguration and was unable to complete your > request etc.. etc.. > > the site should be display the current date and time, but if I do > : > > http://www.mydomain.com:8080 i see the page correctly! > > > I think the error is in the Apache Tomcat connector > (libapache2-mod-jk installed with "aptitude" command) .. > > > This is my workers.properties file : Next time, please remove all the comments when posting configuration, unless they are particularly relevant. > workers.tomcat_home=/usr/share/tomcat9 This directive does nothing. > workers.java_home=/usr/lib/jvm/java-11-openjdk-amd64 This directive does nothing. > ps=/ This directive does nothing. How old is this configuration? > worker.list=ajp13_worker worker.ajp13_worker.port=8009 > worker.ajp13_worker.host=localhost worker.ajp13_worker.type=ajp13 > worker.ajp13_worker.lbfactor=1 worker.loadbalancer.type=lb > worker.loadbalancer.balance_workers=ajp13_worker Okay, so you have a worker called ajp13_worker and another one called loadbalancer which (a) balances to ajp13_worker but (b) isn't registered as a worker, so you can't JkMount to it. Keep that in mind. > and this is my httpd-jk.conf (loaded by Apache) file : > > > > JkWorkersFile /etc/libapache2-mod-jk/workers.properties This is the file above, right? Double-check. > JkWatchdogInterval 60 # Inside Location we > can omit the URL in JkMount JkMount jk-status Require ip 127.0.0.1 > You haven't defined a jk-status worker. This won't work. > # Inside Location we can omit the URL in > JkMount JkMount jk-manager Require ip 127.0.0.1 Nor will this. > Your configuration is incomplete: you have no JkMounts defined, other than the invalid ones. So something is missing, because your configuration clearly shows that JkMounts are in effect: > This is my mod_jk.log log file (I replaced my real domain with > www.mydomain.com) > > [Mon Nov 25 16:40:11.684 2019] [1914:140619718063232] [debug] > uri_worker_map_add::jk_uri_worker_map.c (848): wildchar rule > '/*=ajp13_worker' source 'JkMount' was added So somewhere in your configuration, this line must be present: JkMount /* ajp13_worker > [Mon Nov 25 16:40:11.684 2019] [1914:140619718063232] [debug] > wc_get_worker_for_name::jk_worker.c (120): did not find a worker > ajp13_worker That's not good. It appears to be in your configuration. My initial conclusion is that the file where you have defined ajp13_worker is not the file actually being used by mod_jk. > the VirtualHost in Apache is : > > DocumentRoot > "/var/www/vhosts/www.mydomain.com/ROOT" ServerName > www.mydomain.com ServerAdmin i...@mydomain.com > > JkMount /* ajp13_worker Yup there it is. > JkLogLevel debug Okay. > I have a new Debian 10 server with Apache 2 + Tomcat 9. I can't run > the JSF page due to an internal server error. I think the error is > in the Apache Tomcat connector (libapache2-mod-jk) .. > > [snip: repeated configuration files] > > So, it seems that Apache cannot find "ajp13_worker" worker.. > > Why? Can you confirm that this file contains your configuration: /etc/libapache2-mod-jk/workers.properties - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3dWK0ACgkQHPApP6U8 pFggWRAAhd6GlMtBivtufplh5StspDDFkt6n/PUJuvIu8dWlkyXXMKqTNpfxwCQm SfK4hPbbL/caaocoG7xDYYBIBrq7juwdWQCBQFByS8WXXJrzDWU+wq86jVsg5Uw5 WVSzps6BAH4DcXb+jss/EIeeDW110eXy14COjJ70o+kDmNzBJvTxP8e75WHPq0pm JTiZKwnAHL6jNhuJhFF+V6LnZcnDz2yo63NQPVCTSdlxpHlGES2RXWFT/z6U5GnK xI+6R7WQAauQqWfMjNi32t3jySr6KV1CbVlwAE3FGWmGBEsOeb5AhSJ/aclKTsSy 768kfJL8tiTYraZcLBxT5jNChkHTa3lMh5JmeW2FSBerteNW1APRysHdPBZ6CgS2 PkxoKoQizAc73ehIdFIN8Bvlsbx545VkQxgOvGu4KS4Ka5voMy2vpHq0RA2zcyyz cUAyJt3dtHnBuB0APxI7StKDvh3AtN8VVGg7kwcNJrBZYrJkNr0FOFCW4bw7JdY4 MfJsefH4g3ge/XADXo8Bx0pYZln5avCi46FpEg9NGPghqjBUTp+rjMIn++oBDWXA iZHJ3DMb/WRQGCpbysyi2qIad4tWrFNVJwX3y6VipRnHNSQJcm8vLiY+uEqEuDBf BuadOJbw1HRHDxh0sOt40N/bLoeNBAzKVT6umU8wHmlrQKPDai0= =Yo8V -END PGP SIGNATURE- - 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 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 ? Mark - 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
> Jan, > > On 11/26/19 09:20, jan.a...@seznam.cz wrote: >> with update of Tomcat to version 8.5.49 we observed issue in our >> application when accessing login page. > > Sounds suspiciously familiar: > https://markmail.org/message/7xfg5x7mllrki3hd > > This was for a recent Tomcat 9.0 release, not 8.5, but it: > > 1. Is a stack overflow > 2. Involves MyFaces > >> Application log contains StackOverflowError. There is recursive >> call of CompositionHandler.apply() method. > > Note that MyFaces is not a Tomcat artifact, though it does come from > Apache. > >> It seems that issue is connected with resource caching because when >> I set resources attribute cachingAllowed="false" in application >> xml, issue disappears. > > That is very good information. > >> Could it be caused by fix of Bug 63872? I don't think so. More likely this is another instance of https://bz.apache.org/bugzilla/show_bug.cgi?id=63964 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.48: java.lang.StringIndexOutOfBoundsException
On 24/11/2019 13:50, i...@flyingfischer.ch wrote: > Thanks for confirming and fixing. I have committed the fix. Can you build from source and test this? If it is easier for you I can provide binaries. Thanks, Mark > > Markus > > Am 24.11.19 um 12:34 schrieb Mark Thomas: >> Thanks for providing the additional information. >> >> Confirmed. This is a regression in the fix for: >> https://bz.apache.org/bugzilla/show_bug.cgi?id=63815 >> >> Yon can work-around this by reverting the addition of " in daemon.sh >> made in this commit: >> https://markmail.org/message/ouaatfznmjbrva23 >> >> I'll get this fixed for the next release. The November release was >> fairly late. The December one should (hopefully) be nearer the beginning >> of the month. >> >> Also... >> >> On 24/11/2019 08:20, i...@flyingfischer.ch wrote: >> > built with > > commons-daemon-native > tomcat-native (./configure --with-apr=/usr/bin/apr-1-config > --with-java-home=$JAVA_HOME --with-ssl=yes > --prefix=/usr/share/tomcat8/$newVersion) >> Commons daemon doesn't depend on APR, nor on OpenSSL. That looks like a >> configure for Tomcat Native rather than Commons Daemon. >> >> 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
Re: CPU high usage, the reason org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run
I dig into Tomcat source code and from what I've seen this is what happens: Tomcat "worker thread", tries the polls the work and if it doesn't succeed it invokes sun.misc.Unsafe.park (that's waiting which can be interrupted by another thread), internally in Linux goes through kernel function FUTEX_WAIT (futex definition is " The futex() system call provides a method for waiting until a certain condition becomes true." However, these futex_wait functions sums to top CPU load, although I don't find it's actually load here, as per infamous Linux change of 29 Oct 1993 by Matthias Urlichs: http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html On Tue, Nov 26, 2019 at 4:50 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > 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 > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3dSaUACgkQHPApP6U8 > pFhStRAArIHBU4UT6cw5jS7ys6aRlYpaxw4lJ1lhRA9WB5U7/bG+qnZlai6052X7 > MPrfjP8ZlNMugVwhHjMnY3iijfWT2K6bkd8WILT3gcu/ZSqwz2tr9QYru40zG/Bu > FHHlmoUwfWkUrwphJUgwvp1VsIU3exdG28LDlnGjjp1JmgALd7/KeBmS98kpSyKR > Dot/7tlW98Y9DaPOnOnwkWO/MIZLEuekjBRRgZcYr6OpY+9s0hRP/RJ8uEpSfOgA > +ZCvqrjR3MR26gbap9o6zBsZzI+tjFjH9YteAHkxAOmzU+ztiCoIRj6SA4LJErgT > z53yqxpVRszbWmJod3P7sphHJ+r2dmvf0iOEV4qbkBAYF2vP8wsV3jY/7B68OfNh > 6sSC9CWTg7l0wYzxFLrSVQqIt7WV4BBX/4yH9fQ72jHs8Qd5uIJoDbD5GJ1HW32E > viGpzg9/dlXxsRisow7wdKOFC+wTtWeoyDasMZqgdf+SofSTK1qGF/sR0n866dM3 > I1Rz8E0cVZKADtDrjkUK4BMTExfX0rS2WdpwqWOykvTOA9wvW5IzMfokblMQ1XxG > ctnIJA4sRfFwFmnQVu7ew0Ryu3P3tLzaXE7CqfveOgqu/YLi/9gwbvmSB0x0UGsk > YHepLdZ+CwB1vo0fTn0kVKf+anVoAq3xOguPB69gnBZwmsK4v6g= > =Pk1p > -END PGP SIGNATURE- > > - > 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jan, On 11/26/19 09:20, jan.a...@seznam.cz wrote: > with update of Tomcat to version 8.5.49 we observed issue in our > application when accessing login page. Sounds suspiciously familiar: https://markmail.org/message/7xfg5x7mllrki3hd This was for a recent Tomcat 9.0 release, not 8.5, but it: 1. Is a stack overflow 2. Involves MyFaces > Application log contains StackOverflowError. There is recursive > call of CompositionHandler.apply() method. Note that MyFaces is not a Tomcat artifact, though it does come from Apache. > It seems that issue is connected with resource caching because when > I set resources attribute cachingAllowed="false" in application > xml, issue disappears. That is very good information. > Could it be caused by fix of Bug 63872? > > Application was working with previous 8.5.* tomcat versions without > issues. > > Application uses javax.faces library version 2.2.17 Thanks for the version information. - -chris > -- LOG snippet > > Caused by: java.lang.StackOverflowError > > at java.net.URL.(Unknown Source) > > at java.net.URL.(Unknown Source) > > at sun.misc.URLClassPath$FileLoader.getResource(Unknown Source) > > at sun.misc.URLClassPath$FileLoader.findResource(Unknown Source) > > at sun.misc.URLClassPath$1.next(Unknown Source) > > at sun.misc.URLClassPath$1.hasMoreElements(Unknown Source) > > at java.net.URLClassLoader$3$1.run(Unknown Source) > > at java.net.URLClassLoader$3$1.run(Unknown Source) > > 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 > org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.i nc > > (WebappClassLoaderBase.java:2691) > > at > org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration. > > hasMoreElements(WebappClassLoaderBase.java:2676) > > 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(SAXCompile r. > > 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) > > at java.util.concurrent.FutureTask.run(Unknown Source) > > at > com.sun.faces.util.ExpiringConcurrentCache.get(ExpiringConcurrentCache . > > java:114) > > at com.sun.faces.facelets.impl.DefaultFaceletCache.getFacelet > (DefaultFaceletCache.java:124) > > at com.sun.faces.facelets.impl.DefaultFaceletCache.getFacelet > (DefaultFaceletCache.java:63) > > at com.sun.faces.facelets.impl.DefaultFaceletFactory.getFacelet > (DefaultFaceletFactory.java:295) > > at > com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java : > > 370) > > at > com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java : > > 350) > > at > com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet > (DefaultFaceletContext.java:199) > > at com.sun.faces.facelets.tag.ui.CompositionHandler.apply > (CompositionHandler.java:174) > > at > com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandle r. > > java:93) > > at > com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler. > > java:87) > > at > com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java : > > 312) > > at >
Re: CPU high usage, the reason org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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 -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3dSaUACgkQHPApP6U8 pFhStRAArIHBU4UT6cw5jS7ys6aRlYpaxw4lJ1lhRA9WB5U7/bG+qnZlai6052X7 MPrfjP8ZlNMugVwhHjMnY3iijfWT2K6bkd8WILT3gcu/ZSqwz2tr9QYru40zG/Bu FHHlmoUwfWkUrwphJUgwvp1VsIU3exdG28LDlnGjjp1JmgALd7/KeBmS98kpSyKR Dot/7tlW98Y9DaPOnOnwkWO/MIZLEuekjBRRgZcYr6OpY+9s0hRP/RJ8uEpSfOgA +ZCvqrjR3MR26gbap9o6zBsZzI+tjFjH9YteAHkxAOmzU+ztiCoIRj6SA4LJErgT z53yqxpVRszbWmJod3P7sphHJ+r2dmvf0iOEV4qbkBAYF2vP8wsV3jY/7B68OfNh 6sSC9CWTg7l0wYzxFLrSVQqIt7WV4BBX/4yH9fQ72jHs8Qd5uIJoDbD5GJ1HW32E viGpzg9/dlXxsRisow7wdKOFC+wTtWeoyDasMZqgdf+SofSTK1qGF/sR0n866dM3 I1Rz8E0cVZKADtDrjkUK4BMTExfX0rS2WdpwqWOykvTOA9wvW5IzMfokblMQ1XxG ctnIJA4sRfFwFmnQVu7ew0Ryu3P3tLzaXE7CqfveOgqu/YLi/9gwbvmSB0x0UGsk YHepLdZ+CwB1vo0fTn0kVKf+anVoAq3xOguPB69gnBZwmsK4v6g= =Pk1p -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Could not find worker with name 'ajp13_worker'
Hello, I have a Debian 10 server with Apache 2 + Tomcat 9. I can't run JSF pages due to an internal server error. I use OpenJDK v. 11, also use the Apache Tomcat Native library [1.2.23] (tomcat-native-1.2.23-src.tar.gz) using the APR version [1.7.0] (apr-1.7.0.tar.gz). Tomcat starts regularly and also Apache. If I open : http://www.mydomain.com i get Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request etc.. etc.. the site should be display the current date and time, but if I do : http://www.mydomain.com:8080 i see the page correctly! I think the error is in the Apache Tomcat connector (libapache2-mod-jk installed with "aptitude" command) .. This is my workers.properties file : # workers.properties - # # This file is a simplified version of the workers.properties supplied # with the upstream sources. The jni inprocess worker (not build in the # debian package) section and the ajp12 (deprecated) section are removed. # # As a general note, the characters $( and ) are used internally to define # macros. Do not use them in your own configuration!!! # # Whenever you see a set of lines such as: # x=value # y=$(x)\something # # the final value for y will be value\something # # Normaly all you will need to do is un-comment and modify the first three # properties, i.e. workers.tomcat_home, workers.java_home and ps. # Most of the configuration is derived from these. # # When you are done updating workers.tomcat_home, workers.java_home and ps # you should have 3 workers configured: # # - An ajp13 worker that connects to localhost:8009 # - A load balancer worker # # # OPTIONS ( very important for jni mode ) # # workers.tomcat_home should point to the location where you # installed tomcat. This is where you have your conf, webapps and lib # directories. # workers.tomcat_home=/usr/share/tomcat9 # # workers.java_home should point to your Java installation. Normally # you should have a bin and lib directories beneath it. # workers.java_home=/usr/lib/jvm/java-11-openjdk-amd64 # # You should configure your environment slash... ps=\ on NT and / on UNIX # and maybe something different elsewhere. # ps=/ # #-- ADVANCED MODE #- # # #-- worker list -- #- # # # The workers that your plugins should create and work with # worker.list=ajp13_worker # #-- ajp13_worker WORKER DEFINITION -- #- # # # Defining a worker named ajp13_worker and of type ajp13 # Note that the name and the type do not have to match. # worker.ajp13_worker.port=8009 worker.ajp13_worker.host=localhost worker.ajp13_worker.type=ajp13 # # Specifies the load balance factor when used with # a load balancing worker. # Note: # > lbfactor must be > 0 # > Low lbfactor means less work done by the worker. worker.ajp13_worker.lbfactor=1 # # Specify the size of the open connection cache. #worker.ajp13_worker.cachesize # #-- DEFAULT LOAD BALANCER WORKER DEFINITION -- #- # # # The loadbalancer (type lb) workers perform wighted round-robin # load balancing with sticky sessions. # Note: # > If a worker dies, the load balancer will check its state #once in a while. Until then all work is redirected to peer #workers. worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=ajp13_worker and this is my httpd-jk.conf (loaded by Apache) file : # Licensed to the Apache Software Foundation (ASF) under one or more # contributor license agreements. See the NOTICE file distributed with # this work for additional information regarding copyright ownership. # The ASF licenses this file to You under the Apache License, Version 2.0 # (the "License"); you may not use this file except in compliance with # the License. You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and #
Apache Tomcat 8.5.49 - StackOverflowError when getting static resources
Hello, with update of Tomcat to version 8.5.49 we observed issue in our application when accessing login page. Application log contains StackOverflowError. There is recursive call of CompositionHandler.apply() method. It seems that issue is connected with resource caching because when I set resources attribute cachingAllowed="false" in application xml, issue disapears. Could it be caused by fix of Bug 63872? Application was working with previous 8.5.* tomcat versions without issues. Application uses javax.faces library version 2.2.17 -- LOG snippet Caused by: java.lang.StackOverflowError at java.net.URL.(Unknown Source) at java.net.URL.(Unknown Source) at sun.misc.URLClassPath$FileLoader.getResource(Unknown Source) at sun.misc.URLClassPath$FileLoader.findResource(Unknown Source) at sun.misc.URLClassPath$1.next(Unknown Source) at sun.misc.URLClassPath$1.hasMoreElements(Unknown Source) at java.net.URLClassLoader$3$1.run(Unknown Source) at java.net.URLClassLoader$3$1.run(Unknown Source) 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 org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.inc (WebappClassLoaderBase.java:2691) at org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration. hasMoreElements(WebappClassLoaderBase.java:2676) 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) at java.util.concurrent.FutureTask.run(Unknown Source) at com.sun.faces.util.ExpiringConcurrentCache.get(ExpiringConcurrentCache. java:114) at com.sun.faces.facelets.impl.DefaultFaceletCache.getFacelet (DefaultFaceletCache.java:124) at com.sun.faces.facelets.impl.DefaultFaceletCache.getFacelet (DefaultFaceletCache.java:63) at com.sun.faces.facelets.impl.DefaultFaceletFactory.getFacelet (DefaultFaceletFactory.java:295) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java: 370) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java: 350) at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet (DefaultFaceletContext.java:199) at com.sun.faces.facelets.tag.ui.CompositionHandler.apply (CompositionHandler.java:174) at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler. java:93) at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler. java:87) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java: 312) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java: 371) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java: 350) at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet (DefaultFaceletContext.java:199) at com.sun.faces.facelets.tag.ui.CompositionHandler.apply (CompositionHandler.java:174) at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler. java:93) at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler. java:87) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java: 312) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java: 371) at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java: 350) at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet
