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
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 E
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
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
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
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 ap
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.
import org.apache.catalina.core.*;
//...
public void init(ServletConfig confi
