Re: catalina_out env var
On Fri, Nov 1, 2019 at 1:59 PM Mark Thomas wrote: > > On November 1, 2019 3:25:36 PM UTC, Chris Cheshire > wrote: > >(Tomcat 9, Debian & Centos Unix) > > > >I use systemd to start tomcat with base and home separated using > >catalina.sh. For the service script, values for JAVA_HOME, > >CATALINA_HOME, CATALINA_BASE and CATALINA_OUT are defined there. > > > >Inside catalina.sh it says this about CATALINA_OUT > > > ># CATALINA_OUT(Optional) Full path to a file where stdout and > >stderr > ># will be redirected. > ># Default is $CATALINA_BASE/logs/catalina.out > > > >If this isn't defined, catalina.sh sets a default. It seems that > >everything that goes in here also goes in catalina.date.log > >(controlled by the tomcat's logging.properties), so why does it exist? > >Can I force a redirection to /dev/null instead so I don't have > >duplicated logs? > > > > You can control this in logging.properties Just disable the console logger. > > You don't want redirect to /dev/null as then you will be unable to take > thread dumps or anything else that writes to stdout. > > It is setup this way for users running Tomcat directly from the console. > > Mark > OK so I just remove java.util.logging.ConsoleHandler from the .handlers line? Does this affect the content of catalina.log, or catalina.date.log? I'm less concerned about the chattiness than the redundancy. I've got two logs that contain the same thing, one I have to control with logrotate.d and the other automatically rotates but is never cleared so I also need a cron job to remove old logs. I'm just trying to clean things up. Thanks Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: catalina_out env var
On November 1, 2019 3:25:36 PM UTC, Chris Cheshire wrote: >(Tomcat 9, Debian & Centos Unix) > >I use systemd to start tomcat with base and home separated using >catalina.sh. For the service script, values for JAVA_HOME, >CATALINA_HOME, CATALINA_BASE and CATALINA_OUT are defined there. > >Inside catalina.sh it says this about CATALINA_OUT > ># CATALINA_OUT(Optional) Full path to a file where stdout and >stderr ># will be redirected. ># Default is $CATALINA_BASE/logs/catalina.out > >If this isn't defined, catalina.sh sets a default. It seems that >everything that goes in here also goes in catalina.date.log >(controlled by the tomcat's logging.properties), so why does it exist? >Can I force a redirection to /dev/null instead so I don't have >duplicated logs? > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org You can control this in logging.properties Just disable the console logger. You don't want redirect to /dev/null as then you will be unable to take thread dumps or anything else that writes to stdout. It is setup this way for users running Tomcat directly from the console. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: catalina_out env var
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris, On 11/1/19 11:25, Chris Cheshire wrote: > (Tomcat 9, Debian & Centos Unix) > > I use systemd to start tomcat with base and home separated using > catalina.sh. For the service script, values for JAVA_HOME, > CATALINA_HOME, CATALINA_BASE and CATALINA_OUT are defined there. > > Inside catalina.sh it says this about CATALINA_OUT > > # CATALINA_OUT(Optional) Full path to a file where stdout and > stderr # will be redirected. # > Default is $CATALINA_BASE/logs/catalina.out > > If this isn't defined, catalina.sh sets a default. It seems that > everything that goes in here also goes in catalina.date.log > (controlled by the tomcat's logging.properties), so why does it > exist? They aren't strictly duplicated. The file used in CATALINA_OUT will catch stdout+stderr of the process. That includes things like System.out.print() and System.err.print(). By default, Tomcat's error loggers are configured to write to stdout/stderr but those can be reconfigured to do other things. stdout is always stdout, and stderr is always stderr, though. For example, if you use "kill -3" to get a thread dump, it will never go to catalina.date.log because it doesn't go through any logging facility. > Can I force a redirection to /dev/null instead so I don't have > duplicated logs? You *can* do this, but you might miss some things. If you think catalina.out is chatty, you might want to adjust logging.properties to stop logging to the console. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl28b8YACgkQHPApP6U8 pFimxBAAxqzv3XGMb6gkcNFDnqAsMAx3vvIfmrEtWC8JpWr0O6ao0a+KI/WkeF3n kgNuyRDvFWbCH67c9qxThXs+cDToTUZNOjeTb/OcgIScf/PbWGe1vGCdQ04SWpKQ m3O7yTfUjnfa/VYB2L93Bzf3EVHUbhjmKrhHV7XCO358FqQNmgXdBEEWC3NB4ns0 /xqqgWxj3v9LCc1GtQ6DUiblm91WUyEFzzy9lSxCAHcarYFvXnBApodganDbfbVt eJ/hHy68vjcIvryJ2AgGJvMY97lc0mmS3EuYZeaTFM9VHDm2wnOpEvckk5fkcZzL pnmK1+j9RJXXKwcQPTO2FOSyOdIoTGf0pdMpGOyHlUY6cy6RcwYeHOUfCK19y28t npfRYywOJIkphnFm4u0/etEuggn9wIQKnMLJYO9n0ei9Rp8P4ESYuXUq3QrzIvQM czUCL9Vtl8ahgghNb+60LEuMtnVYDwcSsFdCV3bldxefOYrRvG7eP4taEFIxhV/W dEWz9btxfbejZFQpNUQQfPy3rAPy4I6sGww/EZN7o6d66jzanergjk9FOWeQ4rSx yDkU2/CoTppjaKofWzVB36V43kx/fdG48QOFeZ3dHCxEHzTmEyc8Vv0WEqMDv9ga suWczx3WtOUyhbRLHWitSO3voqufoVRWY7Fl+YcPW21UHMiU21g= =eJW1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
catalina_out env var
(Tomcat 9, Debian & Centos Unix) I use systemd to start tomcat with base and home separated using catalina.sh. For the service script, values for JAVA_HOME, CATALINA_HOME, CATALINA_BASE and CATALINA_OUT are defined there. Inside catalina.sh it says this about CATALINA_OUT # CATALINA_OUT(Optional) Full path to a file where stdout and stderr # will be redirected. # Default is $CATALINA_BASE/logs/catalina.out If this isn't defined, catalina.sh sets a default. It seems that everything that goes in here also goes in catalina.date.log (controlled by the tomcat's logging.properties), so why does it exist? Can I force a redirection to /dev/null instead so I don't have duplicated logs? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Client Cert TLS issue
Thanks Mark, will do! -Original Message- From: Mark Thomas Sent: Thursday, October 31, 2019 3:04 PM To: Tomcat Users List ; George Stanchev Subject: Re: Client Cert TLS issue On 16/10/2019 18:55, George Stanchev wrote: > And this is not where it hangs. I stepped through the code through the > handshaker but still haven't been able to figure out the hang point as I am > not familiar with the details of that portion of TC code . I've attached two > cacerts that you can plug in as truststore to try out the issue. George, The mailing list strips most attachments. Please open a BZ issue for this. One, that means it won't get forgotten and two you will be able to attach those cacert files so we can easily reproduce the issue you are seeing. Thanks, Mark
Re: Question about thread's "keep alive time" value in Embed Tomcat 8.5 in Spring Boot 1.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Roy, On 11/1/19 08:23, Roy Zhang wrote: > I am confused about "keep alive time" value in Embed Tomcat. I am > using Spring Boot 1.5, embed tomcat version is 8.5. > > According to > https://github.com/spring-projects/spring-boot/issues/16450#issuecomme nt-480236238, > > we can't configured thread's "keep alive time" via "maxIdleTime" > parameter, "keep alive time" value is hard coded as 60s via > https://github.com/apache/tomcat/blob/de1f55e672106031821948d5cac80f40 adc09513/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L884, It > is only hard-coded if you use the internal, default Executor. You can instantiate your own Executor with whatever settings you wish. It's a bad name for that setting, but this is how long "excess" threads will live when they are not being used. > I found 60s "keep alive time" sometimes take effect, some times it > doesn't take effect. Could u please kindly help to review my > following two cases and kindly provide explanation? Really > appreciate ur help in advance! > > *Case 1 (60s "keep alive time" DOESN'T take effect):* API latency: > _100ms_ Test step: run API with 800 concurrent threads for 1 > minutes, then run API with 10 concurrent threads for about 1 hour. > As we can see from following graph, after BusyThreads reduced from > ~800 to 10, CurrentThreadsCount remains at 800 for following 1 hour > (60s "keep alive time" DOESN'T take effect). After test stopped, > CurrentThreadsCount reduced from 800 to 100(MinSpareThreads). > image.png Your images have been stripped from the mailing list. Find another way to describe your problem. When you say "X concurrent threads", how often are requests being made? Constantly? So you are sending requests as fast as possible with c=10? I haven't read the code in detail, but I'm guessing that the thread pool uses a queue and not a stack of threads, so each thread gets used, repeatedly, in order of availability. That means that if you keep making requests, you'll keep hitting *all* the threads in the queue and not just the same 10 over and over again. So they never time out. > *Case 2 (60s "keep alive time" DOES take effect):* API latency: > _10s_ Test step: run API with 800 concurrent threads for 1 minutes, > then run API with 10 concurrent threads for about 1 hour. As we can > see from following graph, after BusyThreads reduced from ~800 to > 10, CurrentThreadsCount reduced from 800 to 100(MinSpareThreads). > 60s "keep alive time" DOES take effect) Note that Tomcat's thread pool is just a wrapper around Java's ThreadPoolExecutor -- adding methods to handle Tomcat's lifecycle events, etc. So if the pool isn't behaving as you'd like it, you'll need to file a but against the Java API and not Tomcat. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl28NzYACgkQHPApP6U8 pFjcRxAApIe9WPrO43rIn+8TZ/KBncZbw2ZQr/nEew1pS7xdRFl2LVn/gMpuYaIe 78rF/3M9S0aYcG93vaqzn1+BZXW5EI9EINo+UG3E17ZYeD162Cpl2Q7aqaB/Te0j QR/JHIv31TAUpH39VLEpzfk/d1uct7oVZDq4P3kUjjAFwAo2G0useiHjokXtdIEm 3wXL1e8ChpvdP8RfrPdeATdGtEvGh0zNDW2Qjce+7R5LoC55UpHqJfB+p8BB6nV/ W6Jdp8CN8pVp+wROMMyK3HFvubFqSPcrKGURCmwKMH/QgRfRSTNpIfXYpubfOOqm EF0XxvRc2s/x6ZqRrfnbkunqqmb0h35SXPaWl1RJWpe/cAAaHi0DGORorbDZfnff agzNvl7Wl0/6HL09CXr2PHU6ZQGytSYbItVAjEHqLKhbYW4pLKviLYB84ZRiEc5N 2ZA2ZE9VKWQRgu1kS25U4c5R7Zgy5oVAAIPLzNqEdcqu2dXSsZZeW4sJutwjioOL pia5qqRcotdDPxATqv0Eo75cqvvgE5WeWZ/tMb2sVia85UPRL/cJCgrc/+HmYPmb JRzhobGhQ7WA33yqRfvBdcJ5HIGe2aU4o06VoAv6tHXPldjD4jQ/YHyyicP+bj6E wswEM7oIAIU8+R7JFp1Lhv6ZMuLlKohDmOu2bubhAgweSrAQ8jY= =901h -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Question about thread's "keep alive time" value in Embed Tomcat 8.5 in Spring Boot 1.5
Dear Tomcat experts, I am confused about "keep alive time" value in Embed Tomcat. I am using Spring Boot 1.5, embed tomcat version is 8.5. According to https://github.com/spring-projects/spring-boot/issues/16450#issuecomment-480236238, we can't configured thread's "keep alive time" via "maxIdleTime" parameter, "keep alive time" value is hard coded as 60s via https://github.com/apache/tomcat/blob/de1f55e672106031821948d5cac80f40adc09513/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L884, I found 60s "keep alive time" sometimes take effect, some times it doesn't take effect. Could u please kindly help to review my following two cases and kindly provide explanation? Really appreciate ur help in advance! *Case 1 (60s "keep alive time" DOESN'T take effect):* API latency: *100ms* Test step: run API with 800 concurrent threads for 1 minutes, then run API with 10 concurrent threads for about 1 hour. As we can see from following graph, after BusyThreads reduced from ~800 to 10, CurrentThreadsCount remains at 800 for following 1 hour (60s "keep alive time" DOESN'T take effect). After test stopped, CurrentThreadsCount reduced from 800 to 100(MinSpareThreads). [image: image.png] *Case 2 (60s "keep alive time" DOES take effect):* API latency: *10s* Test step: run API with 800 concurrent threads for 1 minutes, then run API with 10 concurrent threads for about 1 hour. As we can see from following graph, after BusyThreads reduced from ~800 to 10, CurrentThreadsCount reduced from 800 to 100(MinSpareThreads). 60s "keep alive time" DOES take effect) [image: image.png] Thanks, Roy
Re: Intermittent JSP Caching/Compiling Issue while under load
On 31/10/2019 22:07, Mark Thomas wrote: > > > On 29/10/2019 14:31, Tim K wrote: >> I'm on Tomcat 9.0.21 on Linux. I have Jsps that get updated while >> Tomcat is running. I believe development mode is set to true by >> default, I do not have it set to true or false in the >> $CATALINA_BASE/conf/web.xml for the Jsp servlet init-params. I have a >> cluster of 4-8 servers across different envs. I'm noticing an >> intermittent issue where 1 or more of my tomcat instances do not >> always compile the latest Jsp content while the server is under load. >> I've tried debugging the org.apache.jasper.compiler, it appears that >> the class/java files of the tomcat work directory are getting >> deleted/regenerated (get a new timestamp as well) but occasionally the >> contents of the Jsp becomes out of sync in the generated class file >> within the tomcat work directory. I've tried different combinations >> of development mode, checkInterval, modificationTestInterval but none >> seem to help resolve this issue. This only seems to be an issue when >> the server is under a load. I was able to reproduce in my lower env >> (4 server cluster) while hitting the Jsp every 1 seconds while >> changing the jsp contents. I can make a subsequent change and the Jsp >> content likely get's picked up by the same server(s) which previous >> didn't pick it up. > > That you see the issue when hitting the JSP once a second makes me think > it is something to do with timestamp resolution. Are you making > modifications within a similarly short time-frame? Or do you still see > the issue when the modifications are, say, minutes apart? Could this be the issue: https://bz.apache.org/bugzilla/show_bug.cgi?id=63897 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
