Thank you Mark, I appreciate it!
On Sun, Jul 10, 2022 at 2:03 PM Mark Thomas wrote:
> On 10/07/2022 14:25, Jason Zhang wrote:
> > Hi Mark,
> >
> > Thank you for your response. We are currently working with the Alfresco
> > team on this issue. No updates so far.
> >
> > Does this configuration
On 10/07/2022 14:25, Jason Zhang wrote:
Hi Mark,
Thank you for your response. We are currently working with the Alfresco
team on this issue. No updates so far.
Does this configuration help to mitigate the issue (temporary workaround)?
keepAliveTimeout = "0"
Given that that is a setting for
Hi Mark,
Thank you for your response. We are currently working with the Alfresco
team on this issue. No updates so far.
Does this configuration help to mitigate the issue (temporary workaround)?
keepAliveTimeout = "0"
Thank you
On Sun, Jul 10, 2022 at 4:49 AM Mark Thomas wrote:
> On
On 10/07/2022 05:40, Jason Zhang wrote:
Hello Tomcat Support team,
The Tomcat is not responding to requests to port 80 in our system, I would
like to know:
1. If this is an issue with Tomcat or outside the Tomcat
2. If it is an issue with Tomcat, how to fix it
3. If it is outside the Tomcat,
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
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 just if I restart the Spring application.
I can reproduce
> 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=
sts ProxyPass /admx_ecms
> >>> balancer://admxcluster ProxyPassReverse /admx_ecms
> >>> balancer://admxcluster
> >>> BalancerMember http://dl360x3799:8021/custcare_cmax retry=60
> >>> status=+H route=dl360x3799.8021 BalancerMember
> >&g
ster
SetHandler balancer-manager
SetHandler server-status
ExtendedStatus On
TraceEnable Off
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
Hi.
Your netstat screenshot showed the CLOSE_WAIT connections on port 8030,
like :
tcp 509 0 :::10.61.137.49:8030:::10
rMember
>>> http://dl360x3799:8022/custcare_cmax retry=60 status=+H
>>> route=dl360x3799.8022 BalancerMember
>>> http://dl360x3806:8035/custcare_cmax retry=60
>>> route=dl360x3806.8035 BalancerMember
>>> http://dl360x3806:8036/custcare_cmax retry=60
&g
-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
te=dl360x3806.8035
>> BalancerMember http://dl360x3806:8036/custcare_cmax retry=60
>> route=dl360x3806.8036
>> ProxySet stickysession=JSESSIONID
>> ProxySet lbmethod=byrequests
>>
>> ProxyPass /custcare_cmax balancer://cmaxcluster
>> ProxyPassReverse /c
byrequests
ProxyPass /mx balancer://mxcluster
ProxyPassReverse /mx balancer://mxcluster
SetHandler balancer-manager
SetHandler server-status
ExtendedStatus On
TraceEnable Off
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
Hi.
Your netstat screenshot showed the CLOSE_WAIT c
---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 h
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::
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 Diagra
-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 fro
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
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,
>
-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)
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
ctions to the Tomcat backend(s).
>
> Guido
>
> >-Original Message-
> >From: Adhavan Mathiyalagan [mailto:adhav@gmail.com]
> >Sent: Wednesday, May 10, 2017 6:32 PM
> >To: Tomcat Users List
> >Subject: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD
HTTP, but if you use AJP (with mod_jk) you may configure it to
keep and reuse connections to the Tomcat backend(s).
Guido
>-Original Message-
>From: Adhavan Mathiyalagan [mailto:adhav@gmail.com]
>Sent: Wednesday, May 10, 2017 6:32 PM
>To: Tomcat Users List
>Subject: CLO
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) ,wh
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 through the Apache HTTPD
load balancer to the Application running over tomcat container. This leads
to slowness of the port
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
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 app stops responding.
Restarting the app
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 app stops responding.
Restarting the app
: 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
-jdbc.jar)
We are having web based application hosted on Tomcat 7. We are facing
close_wait issue between tomcat and database
server. After certain time period close_wait count increases and reaches
threshold (maxActive="500") after which tomcat was unable to create new
thread a
tion server: Apache Tomcat 7.0.63
>
> Web server : Apache 2.2
>
> JRE build : jdk1.6.0_23
>
> Connection pooling: Tomcat jdbc connection pooling (Tomcat-jdbc.jar)
>
>
>
> We are having web based application hosted on Tomcat 7. We are facing
> close_wait issue between tom
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 it creates close_wait.
Best Regards,
Prashant Kaujalgi
-Original Message-
From
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
process.
So, on server all ESTABLISHED becomes, CLOSE_WAIT in netstat
Another clear description of what you're seeing, thanks - but what is
the problem?
What do you expect or want to happen?
p
tcp0 0 10.168.43.69:8080 115.113.7.178:1197
CLOSE_WAIT 10761/java
tcp
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
-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
sslProtocol=TLSv1
maxKeepAliveRequests=1/
I have executed CURL request, around 5000 and after that I kill all my curl
process. So, all ESTABLISHED connection becomes in CLOSE_WAIT state.
Is any configuration is missing or doing something wrong..
Please help me out.
--
Regards,
Chandrakant Solanki
SSLCertificateFile=
SSLCertificateKeyFile=...
clientAuth=false sslProtocol=TLSv1
maxKeepAliveRequests=1/
I have executed CURL request, around 5000 and after that I kill all my curl
process. So, all ESTABLISHED connection becomes in CLOSE_WAIT state.
You have described some
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
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
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
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
to a state of close_wait.
however, if I telnet to the port (8980) from the server running apache I can
connect and the port shows a state of established.
Any ideas as to why I can no longer reach my web application?
Whats causing this close_wait state?
CLOSE_WAIT is when the remote side
running tomcat
changes to a state of close_wait.
however, if I telnet to the port (8980) from the server running apache I
can
connect and the port shows a state of established.
Any ideas as to why I can no longer reach my web application?
Whats causing this close_wait state?
CLOSE_WAIT
connect to my web application
over http. I'm getting a proxy error in my browser window: error reading
from the remote server. The apache log shows the same message.
On the server running tomcat, netstat -a shows the port running tomcat
changes to a state of close_wait.
however, if I telnet
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
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
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
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
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
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
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
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
on my systems a fair number of
sockets apparently stuck for a long time in the CLOSE_WAIT state.
(Sometimes several hundreds of them).
They seem to predominantly concern Tomcat and other java processes, but
as Alan pointed out previously and I confirm, my perspective is slanted,
because we use
the situation above, is there
something
I can do locally to free these lingering CLOSE_WAIT sockets, and under
which conditions ?
For example, I see this line :
tcp6 12 0 :::127.0.0.1:41764 :::127.0.0.1:11002
CLOSE_WAIT 29649/java
which tells me that there is a local process 29649
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.
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
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
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
in the CLOSE_WAIT state.
(Sometimes several hundreds of them).
They seem to predominantly concern Tomcat and other java processes, but
as Alan pointed out previously and I confirm, my perspective is slanted,
because we use a lot of common java programs and webapps on our servers,
and the ones
60 matches
Mail list logo
