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
SHUTDOWN_PORT=-1
HTTP_PORT=8030
JVM_ROUTE=dl360x3805.8030
With regard to the HTTPD configuration , the members are configured in the
another file (balancer.conf) which is included in the httpd.conf
Include /etc/httpd/conf/balancer.conf
BalancerMember http://dl360x3806:8030/custcare_cmax/view/services retry=60
route=dl360x3806.8030
Regards,
Adhavan.M
On Thu, May 11, 2017 at 9:06 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -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
> in httpd.conf -- where you specify all port numbers for mod_proxy_http
> and none of them were port 8030.
>
> - -chris
>
> > On Thu, May 11, 2017 at 8:53 PM, André Warnier (tomcat)
> > <a...@ice-sa.com> wrote:
> >
> >> On 11.05.2017 16:57, Adhavan Mathiyalagan wrote:
> >>
> >>> Hi Chris,
> >>>
> >>> *Tomcat Configuration*
> >>>
> >>> HTTP/1.1 and APR
> >>>
> >>> >>>
> >>> connectionTimeout="2"
> >>>
> >>> redirectPort="8443" maxHttpHeaderSize="8192" />
> >>>
> >>>
> >>> ${catalina.base}/conf/web.xml
> >>>
> >>>
> >>>
> >>> className="org.apache.catalina.session.StandardManager"
> >>> maxActiveSessions="400"/>
> >>>
> >>>
> >>> *HTTPD Configuration*
> >>>
> >>>
> >>>
> >>> ServerTokens OS ServerRoot "/etc/httpd"
> >>>
> >>> PidFile run/httpd.pid
> >>>
> >>> Timeout 60 KeepAlive Off MaxKeepAliveRequests 100
> >>> KeepAliveTimeout 15 StartServers256
> >>> MinSpareServers100 MaxSpareServers500 ServerLimit
> >>> 2000 MaxClients2000 MaxRequestsPerChild 4000
> >>>
> >>> StartServers 4 MaxClients
> >>> 300 MinSpareThreads 25 MaxSpareThreads 75
> >>> ThreadsPerChild 25 MaxRequestsPerChild 0
> >>>
> >>>
> >>>
> >>> ServerName * Timeout 300 ProxyPreserveHost On ProxyRequests
> >>> Off BalancerMember
> >>> http://dl360x3799:8011/admx_ecms/view/services retry=60
> >>> status=+H route=dl360x3799.8011 BalancerMember
> >>> http://dl360x3799:8012/admx_ecms/view/services retry=60
> >>> status=+H route=dl360x3799.8012 ProxySet
> >>> stickysession=JSESSIONID ProxySet lbmethod=byrequests
> >>> ProxyPass /custcare_cmax/view/services balancer://wsiservices
> >>> ProxyPassReverse /custcare_cmax/view/services
> >>> balancer://wsiservices ProxyPass /admx_ecms/view/services
> >>> balancer://wsiservices ProxyPassReverse
> >>> /admx_ecms/view/services balancer://wsiservices >>> balancer://wsiinstances> BalancerMember
> >>> http://dl360x3806:8035/custcare_cmax/services/ws_cma3 retry=60
> >>> route=dl360x3806.8035 BalancerMember
> >>> http://dl360x3806:8036/custcare_cmax/services/ws_cma3 retry=60
> >>> route=dl360x3806.8036 ProxySet stickysession=JSESSIONID
> >>> ProxySet lbmethod=byrequests ProxyPass
> >>> /custcare_cmax/services/ws_cma3 balancer://wsiinstances
> >>> ProxyPassReverse /custcare_cmax/services/ws_cma3
> >>> balancer://wsiinstances ProxyPass /admx_ecms/services/ws_cma3
> >>> balancer://wsiinstances ProxyPassReverse
> >>> /admx_ecms/services/ws_cma3 balancer://wsiinstances >>> balancer://admxcluster> BalancerMember
> >>> http://dl360x3799:8011/admx_ecms retry=60 status=+H
> >>> route=dl360x3799.8011 BalancerMember
> >>> http://dl360x3799:8012/admx_ecms retry=60 status=+H
> >>> route=dl360x3799.8012 ProxySet stickysession=JSESSIONID
> >>> ProxySet lbmethod=byrequests ProxyPass /admx_ecms
> >>> balancer://admxcluster ProxyPassReverse /admx_ecms
> >>> balancer://admxcluster
> >>> BalancerMember http://dl360x3799:8021/custca
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) <a...@ice-sa.com>
wrote:
> On 11.05.2017 16:57, Adhavan Mathiyalagan wrote:
>
>> Hi Chris,
>>
>> *Tomcat Configuration*
>>
>> HTTP/1.1 and APR
>>
>> >
>> connectionTimeout="2"
>>
>> redirectPort="8443" maxHttpHeaderSize="8192" />
>>
>>
>> ${catalina.base}/conf/web.xml
>>
>> > className="org.apache.catalina.session.StandardManager"
>> maxActiveSessions="400"/>
>>
>>
>>
>> *HTTPD Configuration*
>>
>>
>>
>> ServerTokens OS
>> ServerRoot "/etc/httpd"
>>
>> PidFile run/httpd.pid
>>
>> Timeout 60
>> KeepAlive Off
>> MaxKeepAliveRequests 100
>> KeepAliveTimeout 15
>>
>> StartServers256
>> MinSpareServers100
>> MaxSpareServers500
>> ServerLimit2000
>> MaxClients2000
>> MaxRequestsPerChild 4000
>>
>>
>>
>> StartServers 4
>> MaxClients 300
>> MinSpareThreads 25
>> MaxSpareThreads 75
>> ThreadsPerChild 25
>> MaxRequestsPerChild 0
>>
>>
>>
>>
>> ServerName *
>> Timeout 300
>> ProxyPreserveHost On
>> ProxyRequests Off
>>
>> BalancerMember http://dl360x3799:8011/admx_ecms/view/services retry=60
>> status=+H route=dl360x3799.8011
>> BalancerMember http://dl360x3799:8012/admx_ecms/view/services retry=60
>> status=+H route=dl360x3799.8012
>> ProxySet stickysession=JSESSIONID
>> ProxySet lbmethod=byrequests
>>
>> ProxyPass /custcare_cmax/view/services balancer://wsiservices
>> ProxyPassReverse /custcare_cmax/view/services balancer://wsiservices
>> ProxyPass /admx_ecms/view/services balancer://wsiservices
>> ProxyPassReverse /admx_ecms/view/services balancer://wsiservices
>>
>> BalancerMember http://dl360x3806:8035/custcare_cmax/services/ws_cma3
>> retry=60 route=dl360x3806.8035
>> BalancerMember http://dl360x3806:8036/custcare_cmax/services/ws_cma3
>> retry=60 route=dl360x3806.8036
>> ProxySet stickysession=JSESSIONID
>> ProxySet lbmethod=byrequests
>>
>> ProxyPass /custcare_cmax/services/ws_cma3 balancer://wsiinstances
>> ProxyPassReverse /custcare_cmax/services/ws_cma3 balancer://wsiinstances
>> ProxyPass /admx_ecms/services/ws_cma3 balancer://wsiinstances
>> ProxyPassReverse /admx_ecms/services/ws_cma3 balancer://wsiinstances
>>
>> BalancerMember http://dl360x3799:8011/admx_ecms retry=60 status=+H
>> route=dl360x3799.8011
>> BalancerMember http://dl360x3799:8012/admx_ecms retry=60 status=+H
>> route=dl360x3799.8012
>> ProxySet stickysession=JSESSIONID
>> ProxySet lbmethod=byrequests
>>
>> ProxyPass /admx_ecms balancer://admxcluster
>> ProxyPassReverse /admx_ecms balancer://admxcluster
>>
>> BalancerMember http://dl360x3799:8021/custcare_cmax retry=60 status=+H
>> route=dl360x3799.8021
>> BalancerMember 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
>> route=dl360x3806.8036
>> ProxySet stickysession=JSESSIONID
>> ProxySet lbmethod=byrequests
>>
>> ProxyPass /custcare_cmax balancer://cmaxcluster
>> ProxyPassReverse /custcare_cmax balancer://cmaxcluster
>>
>> BalancerMember http://dl360x3805:8089/mx route=dl360x3806.8089
>> ProxySet stickysession=JSESSIONID
>> ProxySet lbmethod=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 connections on port 8030,
> like :
>
> tcp 509 0 :::10.61.137.49:8030:::10.61.137.47:60903
> CLOSE_WAIT
>
> But I do not see any mention of port 8030 in your configs above. So what
> is listening there ?
> ("netstat --tcp -aopn" would show this)
>
>
>
> On Thu, May 11, 2017 at 7:20 PM, Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>>
>> -BEGIN PGP S
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
MinSpareServers100
MaxSpareServers500
ServerLimit2000
MaxClients2000
MaxRequestsPerChild 4000
StartServers 4
MaxClients 300
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
ServerName *
Timeout 300
ProxyPreserveHost On
ProxyRequests Off
BalancerMember http://dl360x3799:8011/admx_ecms/view/services retry=60
status=+H route=dl360x3799.8011
BalancerMember http://dl360x3799:8012/admx_ecms/view/services retry=60
status=+H route=dl360x3799.8012
ProxySet stickysession=JSESSIONID
ProxySet lbmethod=byrequests
ProxyPass /custcare_cmax/view/services balancer://wsiservices
ProxyPassReverse /custcare_cmax/view/services balancer://wsiservices
ProxyPass /admx_ecms/view/services balancer://wsiservices
ProxyPassReverse /admx_ecms/view/services balancer://wsiservices
BalancerMember http://dl360x3806:8035/custcare_cmax/services/ws_cma3
retry=60 route=dl360x3806.8035
BalancerMember http://dl360x3806:8036/custcare_cmax/services/ws_cma3
retry=60 route=dl360x3806.8036
ProxySet stickysession=JSESSIONID
ProxySet lbmethod=byrequests
ProxyPass /custcare_cmax/services/ws_cma3 balancer://wsiinstances
ProxyPassReverse /custcare_cmax/services/ws_cma3 balancer://wsiinstances
ProxyPass /admx_ecms/services/ws_cma3 balancer://wsiinstances
ProxyPassReverse /admx_ecms/services/ws_cma3 balancer://wsiinstances
BalancerMember http://dl360x3799:8011/admx_ecms retry=60 status=+H
route=dl360x3799.8011
BalancerMember http://dl360x3799:8012/admx_ecms retry=60 status=+H
route=dl360x3799.8012
ProxySet stickysession=JSESSIONID
ProxySet lbmethod=byrequests
ProxyPass /admx_ecms balancer://admxcluster
ProxyPassReverse /admx_ecms balancer://admxcluster
BalancerMember http://dl360x3799:8021/custcare_cmax retry=60 status=+H
route=dl360x3799.8021
BalancerMember 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
route=dl360x3806.8036
ProxySet stickysession=JSESSIONID
ProxySet lbmethod=byrequests
ProxyPass /custcare_cmax balancer://cmaxcluster
ProxyPassReverse /custcare_cmax balancer://cmaxcluster
BalancerMember http://dl360x3805:8089/mx route=dl360x3806.8089
ProxySet stickysession=JSESSIONID
ProxySet lbmethod=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
On Thu, May 11, 2017 at 7:20 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -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 configuration, please tell us which
> type of connector you are using (e.g. AJP/HTTP and BIO/NIO/APR).
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkUbAoACgkQHPApP6U8
> pFjWZQ/9EfGcfgvvkM92bIaRBYYh93ET2X7tKP6xQnusKfJ6D0xubfAOU5E+P77c
> BM/3jS1rNyP29zOouHxsGj3h8VzHR4w5ieo6SHHZzkRiOngULSd8hIAbtYdE1UfD
> 4LX8D86KkOZ7HlIxQOQMphP/Lta7KaJ+90FFRmuvEzj3UfYM0JOpzgND/e9609hs
> 6XhpPzmWlSpxdGrnAqoVpMow6F+X1lwolWaZxFCAevQ8gUFqnBVFxfT+zmkwT5mH
> dqk/jPlaAsTUOf4bz4ly8xrXmD3uAldODzRzVpIMCAtPIvkVGWazyIUltF6w5o1X
> Bz4Z8efsc6mKGrfqcTAar/mpbzAdlbkUVusAhWurXfM+NIneAER7cuR8c1DfldOA
> x1L3owirmTIM9+qf+KV9d+bnsdMfEuGnnNEnx2SYXaCGh4+2sZOG4Zbb4oRO5RlM
> b+7emzY+Y4JVnbFYVQD1D/RSUS5V+jX69ewm7hfksRPUJYLLDR8smJ1vbAR4MMHB
> rdqIajl3tAAxCylTQA2hnVfbhu60Iz/Eky4kWATLY0kO5aR7YsXPQFxIQYnkYVZa
> 0o9TjRVJvhoLwSv10RmD1JxEXCXbpr3qeD+zvDK+TJSowCPqu2xnx+DqGkjpiWk6
> eSHDyxaSJqfuz02HeDXWivhYmRE/iWKSETox5Na8UR2MjOdLnPw=
> =YwUt
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
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:::10.61.137.47:12328 CLOSE_WAIT tcp 511 0 :::10.61.137.49:8030:::10.61.137.47:24710 CLOSE_WAIT tcp 479 0 :::10.61.137.49:8030:::10.61.137.47:33175 CLOSE_WAIT tcp 361 0 :::10.61.137.49:8030:::10.61.137.47:58084 CLOSE_WAIT tcp 531 0 :::10.61.137.49:8030:::10.61.137.47:42030 CLOSE_WAIT tcp 971 0 :::10.61.137.49:8030:::10.61.137.47:17692 CLOSE_WAIT tcp 361 0 :::10.61.137.49:8030:::10.61.137.47:60303 CLOSE_WAIT 10.61.137.49 -> Application IP 10.61.137.47 -> Load balancer IP Regards, Adhavan.M On Thu, May 11, 2017 at 7:06 PM, André Warnier (tomcat) <a...@ice-sa.com> wrote: > 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) > -> > > > >> 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, 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 through the Apache >>>> HTTPD load balancer to the Application running over tomcat >>>> container. This leads to slowness of the port where the >>>> Application is running and eventually the application is not >>>> accessible through that particular PORT. >>>> >>> >>> Please clarify: are the connections in the CLOSE_WAIT state owned by the >>> httpd process or the Tomcat process? >>> >>> In case of the traffic directly reaching the Application PORT >>>> without HTTPD (Load balancer) there is no CLOSE_WAIT connections >>>> created and application can handle the load seamlessly. >>>> >>> >>> - -chris >>> -BEGIN PGP SIGNATURE- >>> Comment: GPGTools - http://gpgtools.org >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>> >>> iQIyBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkUZcoACgkQHPApP6U8 >>> pFgiuA/4uARxnF+2c6E+oAIUVX+j2vb+RBicYKAuO6KW67cXtP5UBBFmR5jlLOyr >>> uz6M8qDB0H89IkEgny3oQeaZYVvDeFokthAwTe3SCrtfsWb0d39EHGUoNfxZQnCZ >>> hjygWvxmmuO84RqNrO0Q1+UNWYlPB0cK3SLFZRmh59zJg+C8FBDG2OAIEpevXw0O >>> yPdnSHq6KwX3kZA3KZWx03YUBwjjTk1TLvfq8vfmMmp96THd4QXqvhI46xOcV/sp >>> KBUrRIQhjTDPsm7EH268ffve0kgcXIkmh7qj2cCl07+CrVn6TbPXSwQEm5j5CjIF >>> toMywVs9szCwT0qRlOaLALQyXdUJnuUwBNjTp+DIPIukeUZ1BqwC/DopTHftzr6u >>> oT7ZWurZBFCZUSCsbfyi6c7FTRs/jqT3eIo2he5Q3AxtZ2CayzC4xgx2vxqrBTkV >>> OEESNhnzH3QdJTFnDDQCLtrr7lHyZ6/4MKDUK9Ax2LjVt63kRdIW31VWs0Y2KqbW >>> OGd9apwNe9FrTEGn7zAw+lXKKmWr/2DMEViawmKUxtoZMQsrW6NPTvlNmKX4zgYM >>> eU0ZHE5d1SMYwfPXzH+w/Cqv+hZMssNfKMZ9rdjPd+rf8xgzL27tvMvg/rjvrRfF >>> kuiNtfFcA34CDfR+bEed2eYAAUMizb+uzPUHhVAZMaR8T8CXGQ== >>> =nMBw >>> -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 > >
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, 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 through the Apache > > HTTPD load balancer to the Application running over tomcat > > container. This leads to slowness of the port where the > > Application is running and eventually the application is not > > accessible through that particular PORT. > > Please clarify: are the connections in the CLOSE_WAIT state owned by the > httpd process or the Tomcat process? > > > In case of the traffic directly reaching the Application PORT > > without HTTPD (Load balancer) there is no CLOSE_WAIT connections > > created and application can handle the load seamlessly. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIyBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkUZcoACgkQHPApP6U8 > pFgiuA/4uARxnF+2c6E+oAIUVX+j2vb+RBicYKAuO6KW67cXtP5UBBFmR5jlLOyr > uz6M8qDB0H89IkEgny3oQeaZYVvDeFokthAwTe3SCrtfsWb0d39EHGUoNfxZQnCZ > hjygWvxmmuO84RqNrO0Q1+UNWYlPB0cK3SLFZRmh59zJg+C8FBDG2OAIEpevXw0O > yPdnSHq6KwX3kZA3KZWx03YUBwjjTk1TLvfq8vfmMmp96THd4QXqvhI46xOcV/sp > KBUrRIQhjTDPsm7EH268ffve0kgcXIkmh7qj2cCl07+CrVn6TbPXSwQEm5j5CjIF > toMywVs9szCwT0qRlOaLALQyXdUJnuUwBNjTp+DIPIukeUZ1BqwC/DopTHftzr6u > oT7ZWurZBFCZUSCsbfyi6c7FTRs/jqT3eIo2he5Q3AxtZ2CayzC4xgx2vxqrBTkV > OEESNhnzH3QdJTFnDDQCLtrr7lHyZ6/4MKDUK9Ax2LjVt63kRdIW31VWs0Y2KqbW > OGd9apwNe9FrTEGn7zAw+lXKKmWr/2DMEViawmKUxtoZMQsrW6NPTvlNmKX4zgYM > eU0ZHE5d1SMYwfPXzH+w/Cqv+hZMssNfKMZ9rdjPd+rf8xgzL27tvMvg/rjvrRfF > kuiNtfFcA34CDfR+bEed2eYAAUMizb+uzPUHhVAZMaR8T8CXGQ== > =nMBw > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD
Thanks Guido ! On Thu, May 11, 2017 at 12:02 PM, Jäkel, Guido <g.jae...@dnb.de> 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 in this way and will use a new > connection for each request to the backend. > > Then, you'll see a lot of sockets in the TCP/IP closedown workflow between > the load balancer and the backend server. Pleases refer to TCP/IP that the > port even for a "well closed connection" will be hold some time to handle > late (duplicate) packets. Think about a duplicated, delayed RST packet - > this should not close the next connection to this port. > > Because this situation is very unlikely or even impossible on a local area > network, you may adjust the TCP stack setting of your server to use much > lower protection times (in the magnitude of seconds) and also adjust > others. And at Linux, you may also expand the range of ports used for > connections. > > BTW: If you have a dedicated stateful packet inspecting firewall between > your LB and the server, you also have to take a look on this. > > > Said that, one more cent about the protocol between the LB and the Tomcat: > I don’t know about 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: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD > > > >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 where the Application is running and eventually > the > >application is not accessible through that particular PORT. > > > >In case of the traffic directly reaching the Application PORT without > HTTPD > >(Load balancer) there is no CLOSE_WAIT connections created and > application > >can handle the load seamlessly. > > > >Thanks in advance for the support. > > > >Regards, > >Adhavan.M >
CLOSE_WAIT between Application (Tomcat) and Apache HTTPD
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 where the Application is running and eventually the application is not accessible through that particular PORT. In case of the traffic directly reaching the Application PORT without HTTPD (Load balancer) there is no CLOSE_WAIT connections created and application can handle the load seamlessly. Thanks in advance for the support. Regards, Adhavan.M
Re: Application throwing ClassCast Exception while upgrading from tomcat 8.0.18 to tomcat 8.0.30
Thanks for your answer Konstantin !. I will re-verify the code. Adhavan.M On Sat, Jan 30, 2016 at 5:56 PM, Konstantin Kolinko <knst.koli...@gmail.com> wrote: > 2016-01-20 1:47 GMT+03:00 Mark Thomas <ma...@apache.org>: > > On 19/01/2016 16:37, Adhavan Mathiyalagan wrote: > >> Thanks Mark ! Please find my answer > >> > >> Figure out what is inserting something other than String[] as the value > >> into a Map<String,String[]> instance. > >> > >> There are lot of places in Client we insert 'Integer' datatype (Also > >> other datatypes) .I fear that it is going to be more > >> tedious thing to identify and fix all the client code. > >> > >> Is there any other way or path forward to fix this ? (Like upgrading > the > >> displaytag version > >> which is currently 1.1) Or Is the modifying the Client Code is the only > >> path forward ? > > > > It depends. How are you inserting Integers into that Map? I'm trying to > > figure out if this is a client code bug or if the restriction that was > > added to Tomcat was overly strict and needs to be reverted. > > > > Looking for DisplayTag 1.1 source jar at Maven Central, it is a > rather old library. The latest version is 1.2 (released in 2008). > > 1.1 was released in 2006. Why OP haven't upgraded to 1.2 ? > > Web site: > http://www.displaytag.org/ > http://sourceforge.net/projects/displaytag/ > > That said, I do not see any obvious errors in that library. It creates > a copy of parameter map (DefaultRequestHelper.getParameterMap()). I do > not see it inserting any values into original map. I also do not see > it implementing a ServletRequestWrapper. > > So I think the error is not in the library, but in some other code. > > > I think the Tomcat code is OK. > > The official Servlet Specification javadoc says that the values in > ParameterMap are String[], and this requirement has to be enforced at > some point of time. Looking into Servlet 2.4 Javadoc (the spec > released in 2003, implemented by Tomcat 5.x) it says exactly the same. > [1][2] So a library released in year 2006 must follow it. > > > Regarding a technical way to insert incorrect parameters. In theory I > see two ways: > > 1. org.apache.catalina.core.ApplicationHttpRequest is a wrapper. The > wrapped request may be beyond our control, but it still has to follow > the spec. > > 2. The map returned by ApplicationHttpRequest class must be immutable > [2], but it is not enforced. I filed > https://bz.apache.org/bugzilla/show_bug.cgi?id=58946 > > > [1] > https://wiki.apache.org/tomcat/Specifications#Java_Servlet_Specifications > [2] > http://docs.oracle.com/javaee/1.4/api/javax/servlet/ServletRequest.html#getParameterMap%28%29 > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Application throwing ClassCast Exception while upgrading from tomcat 8.0.18 to tomcat 8.0.30
Hi Mark,
Kindly let me know if any further information required apart from the
information that i have provided in the above mail.
Thanks & Regards,
Adhavan.M
On Wed, Jan 27, 2016 at 4:09 PM, Adhavan Mathiyalagan <adhav@gmail.com>
wrote:
> Hi Mark,
>
> Kindly find my answer for your query
>
> How are you inserting Integers into that Map?
>
> Displaytag(3pp) introduces the value for the 'table name parameter
> tag'(highlighted in bold) as integer in the request .
>
> this is used as identifier for the table name.
>
> Http Request Parameter :
>
> {*d-3034713-p=1*,
> Description=[Ljava.lang.String;@9afb582,
> SuToken=[Ljava.lang.String;@6eb56ec5,
> requestMapping=[Ljava.lang.String;@497b804b,
> IVP_Code=[Ljava.lang.String;@4b23e19d,
> RequestTimeStamp=[Ljava.lang.String;@20b130f5,
> OkButton=[Ljava.lang.String;@51053597,
> FW_SubmittedFormPath=[Ljava.lang.String;@2d01760f,
> IVP_Description=[Ljava.lang.String;@3aede9de,
> SuStepName=[Ljava.lang.String;@59950c0b,
> Code=[Ljava.lang.String;@4849d41f}
>
> As the tomcat version ( greater than tomcat 8.0.18) version restricts the
> parameter value type to String only Hence the below class cast exception is
> thrown .
>
> Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast
> to [Ljava.lang.String;
> at
> org.apache.catalina.core.ApplicationHttpRequest.getParameter(ApplicationHttpRequest.java:369)
> at
> org.displaytag.util.DefaultRequestHelper.getParameterMap(DefaultRequestHelper.java:128)
> at
> org.displaytag.util.DefaultRequestHelper.getHref(DefaultRequestHelper.java:75)
> at
> com.ccc.ddd.cfw.wcs.uitemplates.taglib.displaytag.ExtendedRequestHelper.getHref(ExtendedRequestHelper.java:191)
> at org.displaytag.tags.TableTag.initHref(TableTag.java:1061)
> at
> com.ccc.ddd.cfw.wcs.uitemplates.taglib.displaytag.TableTag.initHref(TableTag.java:666)
> at org.displaytag.tags.TableTag.initParameters(TableTag.java:866)
> at org.displaytag.tags.TableTag.doStartTag(TableTag.java:722)
> at
> com.ccc.ddd.cfw.wcs.uitemplates.taglib.displaytag.TableTag.doStartTag(TableTag.java:712)
>
>
> Version of the 3PP Used :
>
> Displaytag version : displaytag 1.1
> Tomcat Version : tomcat 8.0.30
>
> Kindly suggest me the path forward for the issue.
>
> Thanks in Advance.
>
> Adhavan.M
>
>
>
> On Fri, Jan 22, 2016 at 6:46 PM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 22/01/2016 13:01, Adhavan Mathiyalagan wrote:
>> > Hi Mark,
>> >
>> > Kindly let me know if you can conclude if the issue is on the client
>> side
>> > of application or tomcat restriction that has/will be reverted.
>>
>> Until you answer my previous question, this thread is not going to
>> progress.
>>
>> Mark
>>
>>
>> >
>> > Note : As i mentioned already the application was working without issues
>> > with tomcat version <= 8.0.18
>> >
>> > Thanks ,
>> > Adhavan
>> >
>> >
>> >
>> > On Wed, Jan 20, 2016 at 4:17 AM, Mark Thomas <ma...@apache.org> wrote:
>> >
>> >> On 19/01/2016 16:37, Adhavan Mathiyalagan wrote:
>> >>> Thanks Mark ! Please find my answer
>> >>>
>> >>> Figure out what is inserting something other than String[] as the
>> value
>> >>> into a Map<String,String[]> instance.
>> >>>
>> >>> There are lot of places in Client we insert 'Integer' datatype
>> (Also
>> >>> other datatypes) .I fear that it is going to be more
>> >>> tedious thing to identify and fix all the client code.
>> >>>
>> >>> Is there any other way or path forward to fix this ? (Like upgrading
>> the
>> >>> displaytag version
>> >>> which is currently 1.1) Or Is the modifying the Client Code is the
>> only
>> >>> path forward ?
>> >>
>> >> It depends. How are you inserting Integers into that Map? I'm trying to
>> >> figure out if this is a client code bug or if the restriction that was
>> >> added to Tomcat was overly strict and needs to be reverted.
>> >>
>> >> Mark
>> >>
>> >>
>> >>>
>> >>> Thanks Again !
>> >>>
>> >>> On Tue, Jan 19, 2016 at 8:12 PM, Mark Thomas <ma...@apache.org>
>> wrote:
>> >>>
>> >>>> On 19/01/2016 13:39, Adhavan Mathiyalagan wrote:
>> >>>>
>> >>>>
&g
Re: Application throwing ClassCast Exception while upgrading from tomcat 8.0.18 to tomcat 8.0.30
Hi Mark,
Kindly find my answer for your query
How are you inserting Integers into that Map?
Displaytag(3pp) introduces the value for the 'table name parameter
tag'(highlighted in bold) as integer in the request .
this is used as identifier for the table name.
Http Request Parameter :
{*d-3034713-p=1*,
Description=[Ljava.lang.String;@9afb582,
SuToken=[Ljava.lang.String;@6eb56ec5,
requestMapping=[Ljava.lang.String;@497b804b,
IVP_Code=[Ljava.lang.String;@4b23e19d,
RequestTimeStamp=[Ljava.lang.String;@20b130f5,
OkButton=[Ljava.lang.String;@51053597,
FW_SubmittedFormPath=[Ljava.lang.String;@2d01760f,
IVP_Description=[Ljava.lang.String;@3aede9de,
SuStepName=[Ljava.lang.String;@59950c0b,
Code=[Ljava.lang.String;@4849d41f}
As the tomcat version ( greater than tomcat 8.0.18) version restricts the
parameter value type to String only Hence the below class cast exception is
thrown .
Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast
to [Ljava.lang.String;
at
org.apache.catalina.core.ApplicationHttpRequest.getParameter(ApplicationHttpRequest.java:369)
at
org.displaytag.util.DefaultRequestHelper.getParameterMap(DefaultRequestHelper.java:128)
at
org.displaytag.util.DefaultRequestHelper.getHref(DefaultRequestHelper.java:75)
at
com.ccc.ddd.cfw.wcs.uitemplates.taglib.displaytag.ExtendedRequestHelper.getHref(ExtendedRequestHelper.java:191)
at org.displaytag.tags.TableTag.initHref(TableTag.java:1061)
at
com.ccc.ddd.cfw.wcs.uitemplates.taglib.displaytag.TableTag.initHref(TableTag.java:666)
at org.displaytag.tags.TableTag.initParameters(TableTag.java:866)
at org.displaytag.tags.TableTag.doStartTag(TableTag.java:722)
at
com.ccc.ddd.cfw.wcs.uitemplates.taglib.displaytag.TableTag.doStartTag(TableTag.java:712)
Version of the 3PP Used :
Displaytag version : displaytag 1.1
Tomcat Version : tomcat 8.0.30
Kindly suggest me the path forward for the issue.
Thanks in Advance.
Adhavan.M
On Fri, Jan 22, 2016 at 6:46 PM, Mark Thomas <ma...@apache.org> wrote:
> On 22/01/2016 13:01, Adhavan Mathiyalagan wrote:
> > Hi Mark,
> >
> > Kindly let me know if you can conclude if the issue is on the client side
> > of application or tomcat restriction that has/will be reverted.
>
> Until you answer my previous question, this thread is not going to
> progress.
>
> Mark
>
>
> >
> > Note : As i mentioned already the application was working without issues
> > with tomcat version <= 8.0.18
> >
> > Thanks ,
> > Adhavan
> >
> >
> >
> > On Wed, Jan 20, 2016 at 4:17 AM, Mark Thomas <ma...@apache.org> wrote:
> >
> >> On 19/01/2016 16:37, Adhavan Mathiyalagan wrote:
> >>> Thanks Mark ! Please find my answer
> >>>
> >>> Figure out what is inserting something other than String[] as the value
> >>> into a Map<String,String[]> instance.
> >>>
> >>> There are lot of places in Client we insert 'Integer' datatype
> (Also
> >>> other datatypes) .I fear that it is going to be more
> >>> tedious thing to identify and fix all the client code.
> >>>
> >>> Is there any other way or path forward to fix this ? (Like upgrading
> the
> >>> displaytag version
> >>> which is currently 1.1) Or Is the modifying the Client Code is the
> only
> >>> path forward ?
> >>
> >> It depends. How are you inserting Integers into that Map? I'm trying to
> >> figure out if this is a client code bug or if the restriction that was
> >> added to Tomcat was overly strict and needs to be reverted.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Thanks Again !
> >>>
> >>> On Tue, Jan 19, 2016 at 8:12 PM, Mark Thomas <ma...@apache.org> wrote:
> >>>
> >>>> On 19/01/2016 13:39, Adhavan Mathiyalagan wrote:
> >>>>
> >>>>
> >>>>
> >>>>> What i could understand is application is throwing exception due to
> >>>> change
> >>>>> in the getParameter method of ApplicationHttpRequest class ,which
> >> earlier
> >>>>> was accepting all datatypes (like Integer)
> >>>>> is now restricted to 'String' datatype only .
> >>>>>
> >>>>> Kindly let me know why this change has been done ( in the
> getParameter
> >>>>> method of ApplicationHttpRequest class)
> >>>>
> >>>> If only the Apache Tomcat project used some form of version control
> >>>> system where every change to the source code was tracked along with a
> >>>> commen
Re: Application throwing ClassCast Exception while upgrading from tomcat 8.0.18 to tomcat 8.0.30
Hi Mark, Kindly let me know if you can conclude if the issue is on the client side of application or tomcat restriction that has/will be reverted. Note : As i mentioned already the application was working without issues with tomcat version <= 8.0.18 Thanks , Adhavan On Wed, Jan 20, 2016 at 4:17 AM, Mark Thomas <ma...@apache.org> wrote: > On 19/01/2016 16:37, Adhavan Mathiyalagan wrote: > > Thanks Mark ! Please find my answer > > > > Figure out what is inserting something other than String[] as the value > > into a Map<String,String[]> instance. > > > > There are lot of places in Client we insert 'Integer' datatype (Also > > other datatypes) .I fear that it is going to be more > > tedious thing to identify and fix all the client code. > > > > Is there any other way or path forward to fix this ? (Like upgrading the > > displaytag version > > which is currently 1.1) Or Is the modifying the Client Code is the only > > path forward ? > > It depends. How are you inserting Integers into that Map? I'm trying to > figure out if this is a client code bug or if the restriction that was > added to Tomcat was overly strict and needs to be reverted. > > Mark > > > > > > Thanks Again ! > > > > On Tue, Jan 19, 2016 at 8:12 PM, Mark Thomas <ma...@apache.org> wrote: > > > >> On 19/01/2016 13:39, Adhavan Mathiyalagan wrote: > >> > >> > >> > >>> What i could understand is application is throwing exception due to > >> change > >>> in the getParameter method of ApplicationHttpRequest class ,which > earlier > >>> was accepting all datatypes (like Integer) > >>> is now restricted to 'String' datatype only . > >>> > >>> Kindly let me know why this change has been done ( in the getParameter > >>> method of ApplicationHttpRequest class) > >> > >> If only the Apache Tomcat project used some form of version control > >> system where every change to the source code was tracked along with a > >> comment that explained why... > >> > >>> and the suggest me the path forward > >>> for fixing the issue. > >> > >> Figure out what is inserting something other than String[] as the value > >> into a Map<String,String[]> instance. > >> > >> Mark > >> > >> > >> - > >> 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: Application throwing ClassCast Exception while upgrading from tomcat 8.0.18 to tomcat 8.0.30
Thanks Mark ! Please find my answer Figure out what is inserting something other than String[] as the value into a Map<String,String[]> instance. There are lot of places in Client we insert 'Integer' datatype (Also other datatypes) .I fear that it is going to be more tedious thing to identify and fix all the client code. Is there any other way or path forward to fix this ? (Like upgrading the displaytag version which is currently 1.1) Or Is the modifying the Client Code is the only path forward ? Thanks Again ! On Tue, Jan 19, 2016 at 8:12 PM, Mark Thomas <ma...@apache.org> wrote: > On 19/01/2016 13:39, Adhavan Mathiyalagan wrote: > > > > > What i could understand is application is throwing exception due to > change > > in the getParameter method of ApplicationHttpRequest class ,which earlier > > was accepting all datatypes (like Integer) > > is now restricted to 'String' datatype only . > > > > Kindly let me know why this change has been done ( in the getParameter > > method of ApplicationHttpRequest class) > > If only the Apache Tomcat project used some form of version control > system where every change to the source code was tracked along with a > comment that explained why... > > > and the suggest me the path forward > > for fixing the issue. > > Figure out what is inserting something other than String[] as the value > into a Map<String,String[]> instance. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
