On 18/02/2009, Oleg Kalnichevski <ol...@apache.org> wrote:
> Joan Balagueró wrote:
>
> > Hello Oleg,
> >
> > I've been making some tests about the NoHttpResponseException problem, and
> I
> > can't find any reason why HC4 gives some random errors with this
> exception.
> >
> >
>
> Joan
>
> As I said this is _very_ unlikely to be a problem on the client side
>
>
>
> > But I need your opinion about the following. I've made a very simple test
> > sending a request to this "problematic" server. This is the code
> > (simplified):
> >
> > long start;
> >
> > try
> > {
> > (... Some operations ...)
> > start =
> Calendar.getInstance().getTimeInMillis();
> >
> > this.objHttp.execute(objPost);
> >
> > (... Some operations ...)
> > }
> > catch (NoHttpResponseException nhre) {
> > System.out.println("Time (ms) = " +
> > (Calendar.getInstance().getTimeInMillis() - start));
> >
> > nhre.printStackTrace(); }
> >
> >
> > And this is the result in console:
> >
> > Time (ms) = 2
> > org.apache.http.NoHttpResponseException: The target
> server failed to respond
> > (...)
> >
> >
> > As you can see, the process just takes 2 ms. since we send the request
> until
> > we receive the error. With this time of 2ms, my opinion is that the
> request
> > is not sent and the execute method fails with this exception.
> >
> >
>
> I doubt this is the case. NoHttpResponseException can only be thrown by the
> HttpResponseParser after a request has been written to the connection
> socket.
>
>
>
> > Keep in mind that I'm in Barcelona and I'm sending the request to a server
> > located in Madrid, and I'm using an ADSL line shared with many other
> users.
> >
> > But I'm not really sure. What do you think about this?
> >
> >
>
> I have nothing new to add. The problem is likely to occur because the
> connection gets dropped before the server is able to send back a response of
> any kind, either due to a problem on the server side, due to a firewall,
> ADSL modem issue or whatever. This does not seem to be an issue with
> HttpClient code.
If you can install a product such as Wireshark, you could use that to
record the actual traffic to/from the server. This should help show
where the problem is occurring.
> Oleg
>
>
>
>
> > Thanks,
> > Joan.
> >
> >
> > -----Mensaje original-----
> > De: Oleg Kalnichevski [mailto:ol...@apache.org] Enviado el: sábado, 07 de
> febrero de 2009 14:08
> > Para: HttpClient User Discussion
> > Asunto: Re: NO_HTTP_RESPONSE_EXCEPTION
> >
> > sebb wrote:
> >
> > > On 06/02/2009, Oleg Kalnichevski <ol...@apache.org> wrote:
> > >
> > > > Joan Balagueró wrote:
> > > >
> > > >
> > > > > Thanks Oleg. It seems strange to me because HttpClient3 (sending
> > > > >
> > > >
> > >
> > requests
> >
> > >
> > > > to
> > > >
> > > > > the same server) never fails. I'll take a look at the code again and
> > > > >
> > > >
> > >
> > I'll
> >
> > >
> > > >
> > > > > comment you something else.
> > > > >
> > > > >
> > > > >
> > > > I do not know why the server chokes on packets generated by
> HttpClient
> > > >
> > >
> > 4,
> >
> > >
> > > > but this is clearly a server side problem. The server should return a
> non
> > > > 2xx response if something is not okay, not just drop the connection.
> > > >
> > > > HTTP/1.0 can be a problem or absence of User-Agent header. Whatever.
> At
> > > >
> > >
> > any
> >
> > >
> > > > rate the server is broken.
> > > >
> > > >
> > > >
> > > >
> > > > > Just another question. When I modify a connection or response
> timeout
> > > > > setting another value (for example, from 5000 to 2000) HttpClient4
> > > > >
> > > >
> > >
> > applies
> >
> > >
> > > >
> > > > > this new value correctly (as expected, obviously). But not the same
> with
> > > > > maxConnections. If I set MaxConnections from 100 to 1 using
> > > > > ConnManagerParams.setMaxTotalConnections, then:
> > > > >
> > > > > DefaultHttpClient object --> DefaultParams --> parameters -->
> > > > > http.conn-manager.max-total=1 --> OK!
> > > > >
> > > > > But DefaultHttpClient object --> connManager --> connectionPool -->
> > > > > maxTotalConnections still to 100 --> BAD!
> > > > >
> > > > > And if I send 50 simultaneous request, HttpClient processes all of
> them
> > > > >
> > > > even
> > > >
> > > > > with maxTotalConnections to 1.
> > > > >
> > > > > Is this a bug? Or after
> > > > >
> > > > "ConnManagerParams.setMaxTotalConnections" I must
> > > >
> > > > > set the new "param" values to the HttpClient object with
> > > > > "this.objHttp.setParams(set the "params" object with the new value
> of
> > > > > MaxConnections)"?
> > > > >
> > > > >
> > > > >
> > > > This happens because the connection manager does not reset the
> existing
> > > > connection pools for established routes. One can see this as a bug or
> a
> > > > 'feature' as one can look at it from different perspectives. To me
> this
> > > >
> > >
> > is
> >
> > >
> > > > an expected behavior. MaxTotalConnections parameter is expected to be
> set
> > > >
> > >
> > at
> >
> > >
> > > > the start up time and to not mutate afterwards.
> > > >
> > > Maybe this could be added to the Javadoc?
> > >
> > >
> >
> > Opened a JIRA for this issue
> >
> > https://issues.apache.org/jira/browse/HTTPCLIENT-823
> >
> > Oleg
> >
> >
> > >
> > > > Oleg
> > > >
> > > >
> > > >
> > > >
> > > > > Thanks,
> > > > >
> > > > > Joan.
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > > httpclient-users-unsubscr...@hc.apache.org
> > > > For additional commands, e-mail:
> > > > httpclient-users-h...@hc.apache.org
> > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> httpclient-users-unsubscr...@hc.apache.org
> > > For additional commands, e-mail:
> httpclient-users-h...@hc.apache.org
> > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> httpclient-users-unsubscr...@hc.apache.org
> > For additional commands, e-mail:
> httpclient-users-h...@hc.apache.org
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> httpclient-users-unsubscr...@hc.apache.org
> > For additional commands, e-mail:
> httpclient-users-h...@hc.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail:
> httpclient-users-h...@hc.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
