hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 35815] - Race condition when reading chunked responses
Date Fri, 22 Jul 2005 06:54:22 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35815>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35815





------- Additional Comments From klaus.kopruch@materna.de  2005-07-22 08:54 -------
(In reply to comment #6)
> (In reply to comment #0)
> 
> > a) Thread-1 sends a post to the server.
> > b) Thread-2 sends a post to the server using the same connection as Thread-1.
> > c) Thread-1 begins to read the response while Thread-2 is in b)
> > d) Thread-2 begins to read the response while Thread-1 is in c)
> >
> 
> Klaus,
> 
> MTHCM will NEVER release a connection from the connection pool if it has already
> been borrowed. One MUST call HttpMethod#releaseConnection in order to return the
> connection back to its connection manager. Among many things the
> releaseConnection method ensures that response is consumed ENTIRELY prior to
> returning the connection back to the pool.
> 
> So basically the situation you are describing is not very likely (or possible at
> all)
> 
> This said, I'll see if I can spot anything suspicious in the logs

(In reply to comment #6)
> (In reply to comment #0)
> 
> > a) Thread-1 sends a post to the server.
> > b) Thread-2 sends a post to the server using the same connection as Thread-1.
> > c) Thread-1 begins to read the response while Thread-2 is in b)
> > d) Thread-2 begins to read the response while Thread-1 is in c)
> >
> 
> Klaus,
> 
> MTHCM will NEVER release a connection from the connection pool if it has already
> been borrowed. One MUST call HttpMethod#releaseConnection in order to return the
> connection back to its connection manager. Among many things the
> releaseConnection method ensures that response is consumed ENTIRELY prior to
> returning the connection back to the pool.
> 
> So basically the situation you are describing is not very likely (or possible at
> all)
> 
> This said, I'll see if I can spot anything suspicious in the logs

I forgot to say that the POST requests are send via the following code fragment:

try {
  int status = client.executeMethod(m);
  if (status == HttpStatus.SC_OK) {
    log.debug("Execution status of http request is OK!");
    String response;
    response = m.getResponseBodyAsString();

    ...

    return response;
  } else {
    final String err_log = "Execution status of http request is: " + status;
    log.warn(err_log);
    throw new HttpCommunicationException(err_log, ObsErrorCodes.SYSTEM_ERROR,
client);
  }
} catch (HttpRecoverableException e) {
  String err_log = "Remote system " + uri.toString() + " temporarily not
available: reason code = " + e.getReasonCode() + ", reason text = " + e.getReason();
  log.error(err_log, e);
  throw new HttpCommunicationException(err_log,
ObsErrorCodes.SERVICE_TEMP_NOT_AVAILABLE, client);
} catch (IOException e) {
  final String errMsg = e.getMessage();
  String err_log = "Error sending request to " + uri.toString();
  if (errMsg != null) {
    err_log += ": " + e.getMessage();
  }
  log.error(err_log, e);
  throw new HttpCommunicationException(err_log, ObsErrorCodes.SYSTEM_ERROR, client);
} finally {
  // be sure the connection is released back to the connection manager
  m.releaseConnection();
}

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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


Mime
View raw message