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
System.setProperty("org.apache.commons.logging.Log",
"org.apache.commons.logging.impl.SimpleLog");
System.setProperty("org.apache.commons.logging.simplelog.showdatetime",
"true");
System.setProperty("org.apache.commons.logging.simplelog.log.httpclient.wire.header",
"debug");
System.setProperty("org.apache.commons.logging.simplelog.log.org.apache.commons.httpclient",
"debug"); InputStream responsexml=null;
But I got a below response from the server.
Post Form HTTP/1.1 404 Not Found
null
0
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(
response.headerIterator(HTTP.CONN_KEEP_ALIVE));
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(
ExecutionContext.HTTP_TARGET_HOST);
return 80 * 1000;
}
});
BufferedHttpEntity entity = new
BufferedHttpEntity(response.getEntity());
System.out.println("Post Form " + response.getStatusLine());
if (entity != null) {
entity.consumeContent();
}
System.out.println(entity.getContentType());
try{
responsexml = entity.getContent();
if(response!=null){
System.out.println(entity.getContentLength());
}
byte[] fileBArrayrawxml = new
byte[(int)entity.getContentLength()];
responsexml.read(fileBArrayrawxml,0,(int)entity.getContentLength());
System.out.println(new String(fileBArrayrawxml));
responsexml.close();
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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
>
--
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: [email protected]
For additional commands, e-mail: [email protected]
