On Fri, 2007-03-23 at 12:31 +0100, Joan Balagueró wrote:
> Hello,
>
> Thanks for these replies, but I think that my code complies with your
> requeriments. Just take a look to my (simplified) code:
>
> 1. This is the main servlet:
>
> public class cacheServlet extends HttpServlet
> {
> (...)
> public static dtoAdmin objAdmin; // STATIC !!!
>
>
> 2. This is the "dtoAdmin" object:
>
> public class dtoAdmin
> {
> (...)
> // Hashtable with every interface
> public Hashtable<String, dtoInterface> interfaces;
>
>
> 3. And finally this is the "dtoInterface" object:
>
> public class dtoInterface implements java.io.Serializable
> {
> (...)
> // HTTP object
> public HttpClient objHttp;
>
> // Constructor
> public dtoInterface(int connectionTimeout, int responseTimeout)
> {
> try
> {
> this.objHttp = httpUtils.getHttpClient(connectionTimeout,
> responseTimeout);
> (...)
>
> The question is the HashTable of dtoInterface is filled just at the init of
> this servlet and, for each interface, I create an objHttp (this is just an
> instance of httpclient). That means that I have 1 instance of multithreaded
> http connection manager per dtoInterface.
>
> Then, the servlet service() method just gets the corresponding dtoInterface:
>
> public void service(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException
> {
> dtoInterface objInterface = null; //
>
> try
> {
> objInterface = objAdmin.interfaces.get(request.getParameter("url"));
>
> (...)
>
>
> When I send 10 simultaneous requests OF THE SAME INTERFACE, I'm always using
> the same httpClient instance (that belonging to this interface), that has a
> limit of 1 connection. In fact, if for every request I print the httpClient
> instance id, I always get the same id.
>
Joan,
Apparently the same instance HttpConnection gets re-used and all worker
threads essentially serialize on it.
> Probably I'm wrong in any point, but I'm not able to see where...
>
> I need you help because my app is in production with httpClient version
> 3.0.1. My client has 10 requests per second (more or less), and in this
> moment the computer has more than 500!!!!!! http connections opened (and the
> 90% of them are in TIME_AWAIT??)
>
I am not a TCP/IP expert by any stretch of imagination but I think many
sockets in the TIME_WAIT state problem has nothing to do with
HttpClient. Please note the _same_ HttpConnection instance can
instantiate hundreds of sockets during its life time. HttpConnection !=
java.net.Socket. Why those sockets stay in the TIME_WAIT state is a
whole different story [1] and the problem is very likely to be caused by
the TCP/IP stack configuration of the OS you are using.
Oleg
[1] http://www.developerweb.net/forum/showthread.php?t=2941
> Thanks a lot,
>
> Joan.
>
>
>
>
>
>
>
> -----Mensaje original-----
> De: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
> Enviado el: viernes, 23 de marzo de 2007 12:07
> Para: HttpClient User Discussion
> Asunto: RE: PROBLEM WITH setMaxTotalConnections
>
> On Fri, 2007-03-23 at 11:58 +0100, Cordes, Hans-Dieter wrote:
> > Hello,
> >
> > usually there is only one Servlet object instance in a Servlet container,
> however, I assume that the code you have showed "lives" in one of the
> "doGet()/doPost()" etc. Servlet methods. Keep in mind that the Servlet's
> code is called in a multithreaded way, so at the same time there can be
> several running "doGet()/doPost()" etc methods, and each of them has its own
> stack, and on that stack you create different "HttpClient" objects that in
> turn have there own "MultiThreadedHttpConnectionManager()" object. You limit
> the maxConnection to 1, but that does not have any effect in this context.
> >
> > What you probably need is a static "HttpClient" object in your Servlet
> that does your communication. But keep in mind to "synchronize" access to
> it! (I have, however, no idea whether this can really work depending on your
> needs.)
> >
>
> Sharing HttpClient instance between multiple worker threads is indeed
> the way to go. HttpClient is perfectly thread-safe when used with
> multithreaded HTTP connection manager. No additional synchronization is
> necessary.
>
> Oleg
>
>
> > Regards,
> > Hans-Dieter Cordes
> >
> > -----Original Message-----
> > From: sebb [mailto:[EMAIL PROTECTED]
> > Sent: Freitag, 23. März 2007 11:43
> > To: HttpClient User Discussion
> > Subject: Re: PROBLEM WITH setMaxTotalConnections
> >
> > Surely if you make 10 requests to the servlet there will be 10 servlet
> instances?
> >
> > It looks like each has its own connection manager ...
> >
> > On 23/03/07, Joan Balagueró <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > >
> > >
> > > I'm trying to limit the total number of http connections in my
> > > httpclient instance. I'm using a multithreaded http connection
> > > manager. The code is the
> > > following:
> > >
> > >
> > >
> > > HttpClient objHttp = new HttpClient(new
> > > MultiThreadedHttpConnectionManager());
> > >
> > >
> > > objHttp.getHttpConnectionManager().getParams().setMaxTotalConnections(
> > > 1);
> > >
> > >
> > > objHttp.getHttpConnectionManager().getParams().setConnectionTimeout(co
> > > nnecti
> > > onTimeout);
> > >
> > >
> > > objHttp.getHttpConnectionManager().getParams().setSoTimeout(responseTi
> > > meout)
> > > ;
> > >
> > >
> > > objHttp.getHttpConnectionManager().getParams().setStaleCheckingEnabled
> > > (true)
> > > ;
> > >
> > > objHttp.getParams().setCookiePolicy(CookiePolicy.RFC_2109);
> > >
> > >
> > >
> > > This is part of a servlet that receives a request and sends an http
> > > request to another server using this httpclient. As you can see, I'm
> > > limiting the total number to 1 in order to make a test.
> > >
> > >
> > >
> > > But, if I send to this servlet many simultaneous requests (10 or
> > > more), no errors happens and httpclient opens 10 (or more) http
> > > connections, ignoring my limit of 1.
> > >
> > >
> > >
> > > I suppose that I'm misunderstanding something, but I don't know what.
> > > Can anybody help me?
> > >
> > >
> > >
> > > Thanks,
> > >
> > >
> > >
> > > Joan.
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
