Re: [tomcat-users] Re: getting web application version string?
Am 2020-08-17 um 17:57 schrieb Jason Pyeron: -Original Message- From: Michael Osipov Sent: Sunday, August 16, 2020 1:27 PM Am 2020-08-16 um 18:16 schrieb Jason Pyeron: Is there a better way than this? Specifically - detect running Tomcat, then if under Tomcat (today only interested in v7 and v9) obtain the version string as described [1] and shown on the Manager web application. At least for the version, you can use my listener, it will expose all all context-related information via JNDI. Give it a try: http://mo-tomcat-ext.sourceforge.net/user-guide.html#ContextNamingInfoListener Cute. I like how you use org.apache.catalina.LifecycleListener to have legitimate access to the org.apache.catalina.Context. The only gotcha I have is it requires advanced knowledge that you are on Tomcat. Specifically, it requires Operations to configure the context.xml for the web application. I see no portable way to solve this. In fact, from an app's POV. JNDI is portable through containers. If you want the version then you need to accept that this is Tomcat-specific information. M - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [tomcat-users] Re: getting web application version string?
> -Original Message- > From: Michael Osipov > Sent: Sunday, August 16, 2020 1:27 PM > > Am 2020-08-16 um 18:16 schrieb Jason Pyeron: > > Is there a better way than this? > > > > Specifically - detect running Tomcat, then if under Tomcat (today only > > interested in v7 and v9) > obtain the version string as described [1] and shown on the Manager web > application. > > At least for the version, you can use my listener, it will expose all > all context-related information via JNDI. Give it a try: > http://mo-tomcat-ext.sourceforge.net/user-guide.html#ContextNamingInfoListener Cute. I like how you use org.apache.catalina.LifecycleListener to have legitimate access to the org.apache.catalina.Context. The only gotcha I have is it requires advanced knowledge that you are on Tomcat. Specifically, it requires Operations to configure the context.xml for the web application. v/r, Jason - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Handling close_waits
Hi. On 17.08.2020 02:51, Norbert Elbanbuena wrote: Hi Paul, Yes these are some samples, I have about 300 of them getting stuck hourly tcp 761 0 192.168.1.50:58870 74.112.28.109:8011 CLOSE_WAIT tcp0 0 192.168.1.50:56938 192.168.1.50:61616 CLOSE_WAIT tcp0 0 192.168.1.50:56924 192.168.1.50:61616 CLOSE_WAIT tcp0 0 192.168.1.50:56910 192.168.1.50:61616 CLOSE_WAIT tcp0 0 192.168.1.50:56912 192.168.1.50:61616 CLOSE_WAIT tcp6 0 6240 192.168.1.50:44352.11.72.45:47123 CLOSE_WAIT tcp6 32 0 192.168.1.50:44334.209.104.242:13402CLOSE_WAIT tcp6 268 0 192.168.1.50:443108.162.244.28:40864CLOSE_WAIT tcp6 32 0 192.168.1.50:44335.167.185.49:10019 CLOSE_WAIT tcp6 32 0 192.168.1.50:44352.24.48.141:60660 CLOSE_WAIT tcp6 202 0 192.168.1.50:443199.189.191.86:51716CLOSE_WAIT tcp6 202 0 192.168.1.50:443199.189.191.86:1386 CLOSE_WAIT Try forcing a Java Garbage Collection in Tomcat, and check if these CLOSE_WAIT sockets are still there after that. If they are gone, you probably have a server application which leaves these sockets "dangling" and does not properly close them. Other people on this list may be able to provide a simpler way to trigger a GC, but I used a script with "jmxsh", like this : # gc_tomcat.jmxsh # force the target JVM to do a GC, from the jmxsh shell # invoke as : # java -jar jmxsh.jar gc_tomcat.jmxsh # # In the following command, replace the port number (-p) # by the port which has been specified in the parameter : # -Dcom.sun.management.jmxremote.port=x # of the target Java JVM startup line jmx_connect -h 127.0.0.1 -p (port) -U (userid) -P (password) jmx_invoke -m java.lang:type=Memory gc jmx_close for jmxsh, see : - https://github.com/davr/jmxsh - http://isbyr.com/use-jmxsh-jmx-cli-tool-to-troubleshoot-remote-jmx-connection/ Warm regards, Norbert -Original Message- From: Paul Carter-Brown Sent: Sunday, August 16, 2020 2:43 PM To: Tomcat Users List Subject: Re: Tomcat Handling close_waits Hi Norbert, The TCP socket states and timers are managed by the underlying OS and not by Tomcat. Can you paste a netstat -an result so I can see what you mean. Also, is the client using HTTP 1.1 with keep-alive or not? What kind of traffic is this? Paul On Sun, Aug 16, 2020 at 7:16 PM Norbert Elbanbuena wrote: I also noticed that while server receives the connection requests, we are seeing multiple requests from the same sources. Some same source requests (FIN-WAIT) are all in state while other same sources requests are in other state (some in FIN-WAIT or close_wait and some Established). Why are we seeing multiple requests from the same source at the same time? Doesn't each socket request exhaust a thread on the application? Warm regards, Norbert Elbanbuena -Original Message- From: Norbert Elbanbuena Sent: Sunday, August 16, 2020 11:35 AM To: Tomcat Users List Subject: Tomcat Handling close_waits Hi, We are experiencing a flood of close_waits in our server. Interestingly, all of the sessions stuck in close_waits are sourced from Amazon IP addresses. Our second server running the same setup (hardware spec, OS version, Tomcat version, etc.) and had almost the same session count and our application and Tomcat didn't go unresponsive. Is there any tuneable parameter for the APR connector for Tomcat to close the stuck sessions, rather than waiting for the application? Warm regards, Norbert Elbanbuena - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat behind httpd, with Let's Encrypt and Certbot
On 16/08/2020 18:00, James H. H. Lampert wrote: > Permit me to clarify: > > 1. The existing httpd server on this box, and its certbot setup may be > extended/expanded, but not otherwise disturbed. > > 2. Running Tomcat independently of httpd on this box is not an option, > because *both* are to be visible to the outside world on port 443 of the > same IP address. Doing so was not merely "an option," but *mandatory* on > the other box, which has Tomcat and httpd on separate ports. > > 3. At this point, the concern is making certain that the httpd virtual > host for the new subdomain provides for the needs of both Certbot and > Tomcat. Then, I can worry about adding the new subdomain to Certbot. First of all, to confirm I am reading the config correctly: - httpd redirects all http requests to https - anything proxied to Tomcat MUST have been received by httpd over https Given you don't mind whether proxying to Tomcat is over http or https, I recommend http and an http connector in Tomcat with the following settings: SSLEnabled="false", secure="true", scheme="https" I'd be wary of directory traversal issues with the IP controls on Manager and Host Manager access in httpd. There are some edge cases where the Servlet spec's view on matching URIs to targets and the HTTP spec's view are not entirely consistent. This has been known to expose directory traversal issues. I'd recommend using the RemoteIpValve to expose the original IP to Tomcat and then perform the IP filtering in Tomcat. Whether you keep the filtering in httpd (pro of early rejection vs con of having to keep configs in sync) is up to you. HTH, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
