[
https://issues.apache.org/jira/browse/HTTPCLIENT-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuan Wang updated HTTPCLIENT-817:
---------------------------------
Description:
Our environment uses httpclient-3.x to implement a connection pool between
servers. However, we experienced a problem when the following case happened.
When our server has very high traffic (tomcat on a linux box), the file
descriptors will be maxed out (because the upper bound is set too low).
At this moment, the
org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket
will fail due to the following problem:
The org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket
throws an exception (eg. java.net.UnknownHostException) and the flag
REFLECTION_FAILED will be set to true. After this point, the
ReflectionSocketFactory will never be usable even when the system resources
gets back to normal. Due to this problem, a conner issue of the tomcat
classloader will be triggered so that the singleton class
org.apache.commons.httpclient.protocol.ControllerThreadSocketFactory will fail
to loaded in the subsequent calls. And then, our system will be trapped and can
not make any new connections with the connection manager (We are using
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager).
Looks like the implementation of ReflectionSocketFactory with the static flag
REFLECTION_FAILED is problematic. This class is a singleton and the fact that a
single exception can completely disable the instance just doesn't seem
correct.
was:
Our environment uses httpclient-3.x to implement a connection pool between
servers. However, we experienced a problem when the following case happened.
When our server has very high traffic (tomcat on a linux box), the file
descriptors will be maxed out (because the upper bound is set too low).
At this moment, the
org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket
will fail due to the following problem:
The org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket
throws an exception (eg. java.net.UnknownHostException) and the flag
REFLECTION_FAILED will be set to true. After this point, the
ReflectionSocketFactory will never be usable even when the system resources
gets back to normal. Due to this problem, a conner issue of the tomcat
classloader will be triggered so that the singleton class
org.apache.commons.httpclient.protocol.ControllerThreadSocketFactory will fail
to loaded in the subsequence calls. And then, our system will be trapped and
can not make any new connections with the connection manager (We are using
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager).
Looks like the implementation of ReflectionSocketFactory with the static flag
REFLECTION_FAILED is problematic. This class is a singleton and the fact that a
single exception can completely disable the instance just doesn't seem
correct.
> Singleton ReflectionSocketFactory will not be usable once some exception
> happens
> --------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-817
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-817
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 3.1 Final
> Environment: Tomcat 6.0 with jdk1.6 on linux redhat 2.5
> Reporter: Yuan Wang
> Fix For: 3.1.1
>
>
> Our environment uses httpclient-3.x to implement a connection pool between
> servers. However, we experienced a problem when the following case happened.
> When our server has very high traffic (tomcat on a linux box), the file
> descriptors will be maxed out (because the upper bound is set too low).
> At this moment, the
> org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket
> will fail due to the following problem:
> The
> org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket
> throws an exception (eg. java.net.UnknownHostException) and the flag
> REFLECTION_FAILED will be set to true. After this point, the
> ReflectionSocketFactory will never be usable even when the system resources
> gets back to normal. Due to this problem, a conner issue of the tomcat
> classloader will be triggered so that the singleton class
> org.apache.commons.httpclient.protocol.ControllerThreadSocketFactory will
> fail to loaded in the subsequent calls. And then, our system will be trapped
> and can not make any new connections with the connection manager (We are
> using org.apache.commons.httpclient.MultiThreadedHttpConnectionManager).
> Looks like the implementation of ReflectionSocketFactory with the static flag
> REFLECTION_FAILED is problematic. This class is a singleton and the fact that
> a single exception can completely disable the instance just doesn't seem
> correct.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
