Re: CLOSE_WAIT connections when OutOfMemoryError is thrown

On 04/09/18 03:20, Antonio Rafael Rodrigues wrote: > Hi > In my rest API, everytime time my request generates an OutOfMemoryError the > client doesn't get a response from server and hangs forever. If I kill the > client, I can see by lsof that a CLOSE_WAIT connection remains and it goes > away

RE: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

> From: Adhavan Mathiyalagan [mailto:adhav@gmail.com] > Subject: Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD What part of do not top-post do you not understand? > The Application port is configured in the catalina.properties file > HTTP_PORT=8030 > JVM_ROUTE=

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

Hi, The Application port is configured in the catalina.properties file # String cache configuration. tomcat.util.buf.StringCache.byte.enabled=true #tomcat.util.buf.StringCache.char.enabled=true #tomcat.util.buf.StringCache.trainThreshold=50 #tomcat.util.buf.StringCache.cacheSize=5000

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

On 11.05.2017 17:32, Adhavan Mathiyalagan wrote: Hi, 8030 is the port where the application is running. /What/ application ? Is that a stand-alone application ? For Tomcat, I cannot say (because it is not clear below what value ${HTTP_PORT} has. But from your front-end balancer, it looks

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adhavan, On 5/11/17 11:32 AM, Adhavan Mathiyalagan wrote: > 8030 is the port where the application is running. Port 8030 appears nowhere in your configuration. Not in server.xml (where you used ${HTTP_PORT}, which could plausibly be 8030) and not

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adhavan, On 5/11/17 10:57 AM, Adhavan Mathiyalagan wrote: > *Tomcat Configuration* > > HTTP/1.1 and APR > > > connectionTimeout="2" > > redirectPort="8443" maxHttpHeaderSize="8192" /> Okay, so you have a number of defaults taking

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

Hi, 8030 is the port where the application is running. Regards, Adhavan.M On Thu, May 11, 2017 at 8:53 PM, André Warnier (tomcat) wrote: > On 11.05.2017 16:57, Adhavan Mathiyalagan wrote: > >> Hi Chris, >> >> *Tomcat Configuration* >> >> HTTP/1.1 and APR >> >> > >>

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

On 11.05.2017 16:57, Adhavan Mathiyalagan wrote: Hi Chris, *Tomcat Configuration* HTTP/1.1 and APR ${catalina.base}/conf/web.xml *HTTPD Configuration* ServerTokens OS ServerRoot "/etc/httpd" PidFile run/httpd.pid Timeout 60 KeepAlive Off MaxKeepAliveRequests 100

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

Hi Chris, *Tomcat Configuration* HTTP/1.1 and APR ${catalina.base}/conf/web.xml *HTTPD Configuration* ServerTokens OS ServerRoot "/etc/httpd" PidFile run/httpd.pid Timeout 60 KeepAlive Off MaxKeepAliveRequests 100 KeepAliveTimeout 15 StartServers256 MinSpareServers

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

Hi Chris, The netstat O/P below for the CLOSE_WAIT connections tcp 509 0 :::10.61.137.49:8030:::10.61.137.47:60903 CLOSE_WAIT tcp 491 0 :::10.61.137.49:8030:::10.61.137.47:24856 CLOSE_WAIT tcp 360 0 :::10.61.137.49:8030

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

Dear André, ups - yes, I confused both. FIN ;) Guido On 11.05.2017 13:37, André Warnier (tomcat) wrote: > I believe that the explanation given below by Guido is incorrect and > misleading, as it seems to confuse CLOSE_WAIT with TIME_WAIT. > See : TCP/IP State Transition Diagram (RFC793) > >

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adhavan, On 5/11/17 9:30 AM, Adhavan Mathiyalagan wrote: > The connections in the CLOSE_WAIT are owned by the Application > /Tomcat process. Okay. Can you please post your configuration on both httpd and Tomcat sides? If it's not clear from your

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

On 11.05.2017 15:30, Adhavan Mathiyalagan wrote: Hi Chris, The connections in the CLOSE_WAIT are owned by the Application /Tomcat process. Can you provide an example output of the "netstat" command that shows such connections ? (not all, just some) (copy and paste it right here) ->

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

Hi Chris, The connections in the CLOSE_WAIT are owned by the Application /Tomcat process. Regards, Adhavan.M On Thu, May 11, 2017 at 6:53 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Adhavan, > > On 5/10/17 12:32 PM,

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adhavan, On 5/10/17 12:32 PM, Adhavan Mathiyalagan wrote: > Team, > > Tomcat version : 8.0.18 > > Apache HTTPD version : 2.2 > > > There are lot of CLOSE_WAIT connections being created at the > Application(tomcat) ,when the traffic is routed

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

I believe that the explanation given below by Guido is incorrect and misleading, as it seems to confuse CLOSE_WAIT with TIME_WAIT. See : TCP/IP State Transition Diagram (RFC793) CLOSE-WAIT represents waiting for a connection termination request from the local user. TIME-WAIT represents

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

Thanks Guido ! On Thu, May 11, 2017 at 12:02 PM, Jäkel, Guido wrote: > Dear Adhavan, > > I think this is quiet normal, because the browser clients "in front" will > reuse connections (using keep-alive at TCP level) but an in-between load > balancer may be not work or configured

RE: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

Dear Adhavan, I think this is quiet normal, because the browser clients "in front" will reuse connections (using keep-alive at TCP level) but an in-between load balancer may be not work or configured in this way and will use a new connection for each request to the backend. Then, you'll see a

Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

On 10/05/17 17:32, Adhavan Mathiyalagan wrote: > Team, > > Tomcat version : 8.0.18 That is over two years old. Have you considered updating? > Apache HTTPD version : 2.2 > > > There are lot of CLOSE_WAIT connections being created at the > Application(tomcat) ,when the traffic is routed

Re: Close_wait state

On 18.02.2016 16:50, Elias, Michael wrote: Hi - We are running tomcat version 7.0.50. Starting 2 days ago are application stopped responding to requests. Our investigation showed us that we are not closing connections. We see after 300 tcp sessions, for the tomcat PID, in CLOSE_WAIT state out

RE: close_wait in Tomcat 7.0.63

: Thursday, January 07, 2016 12:28 PM To: 'Tomcat Users List' Subject: RE: close_wait in Tomcat 7.0.63 Hi Konstantin, Thanks for prompt reply. Server.xml contains following resource. We are having Apache web server (2.2) which sends request to tomcat and when tomcat communicates with database

Re: close_wait in Tomcat 7.0.63

2016-01-07 9:36 GMT+03:00 Prashant Kaujalgi : > Dear Team, > > > > First of all, I want to apologies if there is a well known fix to my > problem. > > > > Environment: > > OS: Windows server 2008 > > Tomcat application server: Apache Tomcat 7.0.63 > > Web server :

RE: close_wait in Tomcat 7.0.63

: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Thursday, January 07, 2016 12:15 PM To: Tomcat Users List Subject: Re: close_wait in Tomcat 7.0.63 2016-01-07 9:36 GMT+03:00 Prashant Kaujalgi <prashant.kauja...@e-nxt.com>: > Dear Team, > > > > First of all, I want to apologi

Re: CLOSE_WAIT Connection Issue

Hi, 1] having one project in webapps, which will hold connection for 45 seconds. 2] I executed 5000 CURL request, on above project. 3] And then from Clinet Side, from where, I execute curl, kill all curl process. So, on server all ESTABLISHED becomes, CLOSE_WAIT in netstat. tcp0

Re: CLOSE_WAIT Connection Issue

On 18 Nov 2011, at 08:49, Chandrakant Solanki solanki.chandrak...@gmail.com wrote: Hi, 1] having one project in webapps, which will hold connection for 45 seconds. 2] I executed 5000 CURL request, on above project. 3] And then from Clinet Side, from where, I execute curl, kill all curl

Re: CLOSE_WAIT Connection Issue

3] And then from Clinet Side, from where,  I execute curl, kill all curl process. So, on server all ESTABLISHED becomes, CLOSE_WAIT in netstat. I'd imagine kill -KILL or kill -TERM is preventing proper socket teardown. The server is expecting ACKs from the clients that apparently not being

Re: CLOSE_WAIT Connection Issue

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chandrakant, This is a bit OT from your original question: On 11/18/11 2:34 AM, Chandrakant Solanki wrote: Connector port=8080 protocol=org.apache.coyote. http11.Http11NioProtocol maxThreads=5000 minSpareThreads=100 maxSpareThreads=300

Re: CLOSE_WAIT Connection Issue

On 18 Nov 2011, at 07:34, Chandrakant Solanki solanki.chandrak...@gmail.com wrote: Hi All, I am using apache-tomcat 6.0.26 and below is my server.xml Connector port=8080 protocol=org.apache.coyote. http11.Http11NioProtocol redirectPort=8443 maxKeepAliveRequests=1

Re: CLOSE_WAIT

On 3 February 2011 11:35, Pid p...@pidster.com wrote: What factor caused so many people to hijack this thread? Using a mail client such as Gmail, which performs its own threading and doesn't respect or even show the thread ID. (And, Andre, you're right, I was confusing the two states - my

Re: CLOSE_WAIT

Peter Crowther schrieb am 03.02.2011 um 11:47 (+): On 3 February 2011 11:35, Pid p...@pidster.com wrote: What factor caused so many people to hijack this thread? Using a mail client such as Gmail, which performs its own threading and doesn't respect or even show the thread ID. Or

Re: CLOSE_WAIT

On 2 February 2011 10:24, Bw57899 bw57...@gmail.com wrote: Install an application in apache tomcat (6.0.29) in dev env on Solaris 10 with no issue. But after move to production, there are always about 50 ~ 100 CLOSE_WAIT on port 1521. The application need connect an Oracle database which is

Re: CLOSE_WAIT

Peter Crowther wrote: On 2 February 2011 10:24, Bw57899 bw57...@gmail.com wrote: Install an application in apache tomcat (6.0.29) in dev env on Solaris 10 with no issue. But after move to production, there are always about 50 ~ 100 CLOSE_WAIT on port 1521. The application need connect an

RE: CLOSE_WAIT and what to do about it

From: André Warnier [mailto:a...@ice-sa.com] public void close() throws SomeException { putEndRequest(); flush(); socket = null; } flush() being another function which reads the socket until there's nothing left to read, and throws away

RE: CLOSE_WAIT and what to do about it

From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: CLOSE_WAIT and what to do about it If these sockets disappear during a GC, then it must mean that they are still being referenced by some abandoned objects sitting on the Heap, which have not yet been reclaimed by the GC. Which

Re: CLOSE_WAIT and what to do about it

Caldarale, Charles R wrote: From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: CLOSE_WAIT and what to do about it Relatedly, does there exist any way to force a given JVM process to do a full GC interactively, but from a Linux command-line ? Found a command line tool that will do

Re: CLOSE_WAIT and what to do about it

Caldarale, Charles R wrote: From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: CLOSE_WAIT and what to do about it If these sockets disappear during a GC, then it must mean that they are still being referenced by some abandoned objects sitting on the Heap, which have not yet been

RE: CLOSE_WAIT and what to do about it

From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: CLOSE_WAIT and what to do about it Looking at that code above, it is obvious that socket is open, until it is set to null, without previously doing a socket.close(). I don't know Java enough to know if this alone could cause

Re: CLOSE_WAIT and what to do about it

Caldarale, Charles R wrote: From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: CLOSE_WAIT and what to do about it Looking at that code above, it is obvious that socket is open, until it is set to null, without previously doing a socket.close(). I don't know Java enough to know

RE: CLOSE_WAIT and what to do about it

From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: CLOSE_WAIT and what to do about it Relatedly, does there exist any way to force a given JVM process to do a full GC interactively, but from a Linux command-line ? Found a command line tool that will do what you want: http

Re: CLOSE_WAIT and what to do about it

Skimmed quickly through your post there while working, so forgive me if this is irrelevant. CLOSE_WAIT is a state where the connection has been closed on the tcp/ip level, but the application (in this case java) has not closed the socket descriptor yet. As a coincidence we just fixed this very

RE: CLOSE_WAIT and what to do about it

From: André Warnier [mailto:a...@ice-sa.com] It has been previously established that a socket in a long-time-lingering CLOSE-WAIT status, is due to one or the other side of a TCP connection not properly closing its side of the connection when it is done with it. I also surmise (without

Re: CLOSE_WAIT and what to do about it

Peter Crowther wrote: [...] Does that help? Or is it clear as mud? For no-java-expert-me, it is indeed of the hazy category. But it helps a lot, in the sense of adding a +3 in the column get back to the vendor and ask them to fix their code. ;-) Thanks.

Re: CLOSE_WAIT and what to do about it

Peter Crowther wrote: [...] If you have some way of forcing that Java process to collect garbage, you should do so. It's possible for sockets that haven't been close()d to hang around, unreferenced but not yet garbage collected. A full GC would collect any of these, finalizing them as it

RE: CLOSE_WAIT and what to do about it

From: André Warnier [mailto:a...@ice-sa.com] This process is started as a daemon, with a java command-line. Is it possible to add some arguments to that command-line to induce the JVM to do a GC more often ? http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html - I don't think

RE: CLOSE_WAIT and what to do about it

From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: CLOSE_WAIT and what to do about it Relatedly, does there exist any way to force a given JVM process to do a full GC interactively, but from a Linux command-line ? I haven't found one yet, but there are numerous command-line

Re: CLOSE_WAIT and what to do about it

Hi André, I didn't fully read all responses, so I hope i don't repeat to much (or worse contradict statements contained in other replies). On 08.04.2009 12:32, André Warnier wrote: Like the original poster, I am seeing on my systems a fair number of sockets apparently stuck for a long time in