hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From harshal82 <harsha...@gmail.com>
Subject RE: Understand cause and properly handle Connection reset
Date Fri, 01 Oct 2010 20:06:36 GMT

Hi Oleg,

When I am posting file of the size of <100kb everything works fine.

But when I am posting file of the size of 1.5Mb connection reset happens.

I have a apache httpclient which is posting xml to wcf(.net) webservice.

I tried wire log using below 

"debug");	InputStream responsexml=null;

But I got a below response from the server.

Post Form HTTP/1.1 404 Not Found

Below is the java code.

DefaultHttpClient httpclient = new DefaultHttpClient();
        java.net.URI uri = URIUtils.createURI("blabla");
        httpclient.setKeepAliveStrategy(new ConnectionKeepAliveStrategy() {
        public long getKeepAliveDuration(HttpResponse response, HttpContext
context) {
            HeaderElementIterator it = new BasicHeaderElementIterator(
            while (it.hasNext()) {
                HeaderElement he = (HeaderElement) it.nextElement();
                String param = he.getName(); 
                String value = he.getValue();
                if (value != null && param.equalsIgnoreCase("timeout")) {
                    try {
                        return Long.parseLong(value) * 1000;
                    } catch(NumberFormatException ignore) {
            HttpHost target = (HttpHost) context.getAttribute(
                return 80 * 1000;

        BufferedHttpEntity entity = new
        System.out.println("Post Form " + response.getStatusLine());
        if (entity != null) {
    	 responsexml = entity.getContent();
		byte[] fileBArrayrawxml = new byte[(int)entity.getContentLength()];
		System.out.println(new String(fileBArrayrawxml));

olegk wrote:
> On Thu, 2010-06-10 at 20:28 +0200, Hubert, Eric wrote:
>> Hi Oleg,
>> please find attached a client log including wire logs as well as
>> org.apache.commons.httpclient.HttpMethodDirector on DEBUG level.
>> In the log pattern you find a unique request id in brackets just next to
>> the thread name. This can be used to easily correlated request/response
>> pairs.
>> At the beginning you find a request which encounters a Connection reset
>> which the HttpMethodDirector retries. Request id is
>> [e8b9b677-2451-477f-aef7-b41d86ccf2bd].
>> The retried request succeeds and receives a response.
>> Another request with id [df776149-976e-444b-b7b7-b7148d9847ea] is a
>> working example (request/response), no retry.
>> Request with id [6ce80d68-56f9-4829-829a-ad54410f2bc5] is an example of a
>> request with no retry and no reply which pops up at the client-side as an
>> error.
>> Reason:
>> Method retry handler returned false. Automatic recovery will not be
>> attempted
>> The problem is although I think I understand what happens on the
>> client-side I'm still not sure where and how to look for the actual cause
>> of the problem.
>> Acording to the current test results it looks like the requests do not
>> reach the Synapse nodes. So maybe the HWLB closes the connection for some
>> reason?
>> Any help how to best proceed with the analysis is greatly appreciated.
>> Regards,
>>    Eric
> Eric
> I think what you are seeing is a general limitation of the HTTP
> protocol, which was never designed and meant to be used it is being used
> nowadays. Basically, HTTP provides no mechanism to inform the client
> that the server is about to close the connection. 
> So, the server shuts down the connection and the client has no idea
> whether the request has been processed or not. In case of the first
> request the connection reset occurred before the entire message body had
> been written out (while flushing the buffer) and therefore the request
> was assumed safe to retry. In the second case I suppose the entire
> message was not written out to the underlying connection and therefore
> the request was assumed unsafe to retry automatically.
> What is unclear to me is why Synapse dropped both requests prematurely
> without sending a response of some sort given the fact those connections
> were non-persistent.
> Basically when using HTTP as a transport for transactional applications
> one must choose between one of two models:
> * either be prepared to deal with the fact that some requests may never
> be received and processed
> * or be prepared to deal with the fact that the same request may be
> received multiple times and the application must be able to recover from
> such situations.
> I see no other alternatives.
> Hope this helps
> Oleg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org

View this message in context: http://old.nabble.com/Understand-cause-and-properly-handle-Connection-reset-tp28828989p29859318.html
Sent from the HttpClient-User mailing list archive at Nabble.com.

To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

View raw message