Hi,
When talking about the strategy for our next test on the release we checked
at the tomcat connector configuration but we are unsure how to applies your
advices:
1. Check the nginx configuration. Specifically, the keep-alive and
timeout associated with the proxy configuration.
2. Make sure that Tomcat's timeouts are appropriate for those matching
settings in nginx.
It seems were have 100 connections max keept alive at nginx level (
keepalive), a timeout to connect to tomcat of 2s (proxy_connect_timeout)
and a timeout to read from tomcat of 10s (proxy_read_timeout).
On tomcat side we have a connector like follows:
<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
selectorTimeout="1000"
maxThreads="200"
maxHttpHeaderSize="16384"
address="127.0.0.1"
redirectPort="8443"/>
Thomas
2015-04-23 14:50 GMT+02:00 Thomas Boniface <tho...@stickyads.tv>:
> I just want to keep you updated and tell you that all your replies are
> very helpful. It give me clues on what to look for and sometimes confirm
> some of our suspicion.
>
> I have transmitted some of the element collected in this thread to our
> platform team but we were not able to setup new test so far due to other
> task keeping the team busy. I'll post an update when some new tests will be
> possible.
>
> Thanks again,
> Thomas
>
> 2015-04-22 17:19 GMT+02:00 Frederik Nosi <frederik.n...@postecom.it>:
>
>> On 04/22/2015 05:15 PM, Christopher Schultz wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> Frederik,
>>>
>>> On 4/22/15 10:53 AM, Frederik Nosi wrote:
>>>
>>>> Hi, On 04/22/2015 04:35 PM, Christopher Schultz wrote: Neill,
>>>>
>>>> On 4/22/15 9:12 AM, Neill Lima wrote:
>>>>
>>>>> If I am not wrong, if the application in question is
>>>>>>> monitored in VisualVM through JMX
>>>>>>> (https://visualvm.java.net/) you could trigger a Force GC
>>>>>>> from its monitoring console.
>>>>>>>
>>>>>> You can do this, but it won't close any CLOSE_WAIT connections.
>>>> Tomcat's timeout must be reached. I suspect that the timeout(s)
>>>> are simply way too long.
>>>>
>>>>> You can tune the network stack's timeout using sysctl, eg:
>>>>> net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1
>>>>> net.ipv4.tcp_fin_timeout = 3
>>>>>
>>>> This won't do anything, either. As far as the OS is concerned, the
>>> application (Tomcat) is still using that connection. Therefore it
>>> can't be cleaned up.
>>>
>>
>> Indeed you are right, tuning the network stack help with TIME_WAIT, not
>> CLOSE_WAIT, my bad.
>>
>>
>>> Tomcat has to actively hang up the connection, and the best way to do
>>> that is with synchronized timeouts between the reverse proxy and Tomcat.
>>>
>>> You can try all other kinds of tricks, but the fact of the matter is
>>> that the application is still trying to use the socket, so no other
>>> component can step-in and kill it.
>>>
>>
>> Probably the application is slow then, or the server overloaded.
>>
>>
>>
>>> - -chris
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v2
>>> Comment: GPGTools - http://gpgtools.org
>>>
>>> iQIcBAEBCAAGBQJVN7sZAAoJEBzwKT+lPKRYRhkP/j0GBtPH/+/QU2YEgZxbRoJE
>>> z2lmWxDrbFNxiYFS5332SvN4bXhG/Khog83CeBM0bg0VLciSxKYqm5J8YziMlrlo
>>> omqk3gUiNeViyjsjO5SBW9hxT1qhC1PLdtx7uZ7xUiNmmE24wQ3Gi2edyjyvYDJ0
>>> pzLT+bEp8BjXgm0c6aOONO0PJ+PbyZPeF56PXq6iqn426IhebEUlDP8kxuSh3RwL
>>> LQW7tg05bg3yTuP1ZjiwH4gmBfbomJ+xpY6F+zwDkZgk7Cs4okp5/Tr0uTNhsHQM
>>> lgGaIZc9SCoqKaMFqWila3RaAnnpqDe1cdg2N44zluIaMkcO94kDSWBuT25t5dGe
>>> GBiFG2HGczwyo5MCrx0RgYgLtb2bQ0QZQ8nHzNis8wkNQdHWzziWsvsVQOCnCqL/
>>> 3FOkWUbbJTdmnB8lx84sRcuMsDYQ0BYOYW4W/F2WmSxzBnm7V4NixHG9dD4lZ3vJ
>>> fhIO/d0VNOpI+wesZyQg+pwWRHInbigZ0+5A3InOLHW84rWa2qX0wvt6a7rBb0YP
>>> gonBY4xbrPTHoXDHH7ZCs3JW+gwstA5avA/Obp45C5LessbduqRPtBvMUZizyZR5
>>> ByPtJcrCvHlFux1fwc7Idj/9seqaYvllyvO6evvhqgYVU3jV2tekOUNuFGDJ8KRt
>>> HmrzuiH3cmU1JpT6FSen
>>> =XyQw
>>> -----END PGP SIGNATURE-----
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
