On 18.01.2013 12:42, Justin Erenkrantz wrote:
> On Thu, Jan 17, 2013 at 1:19 AM, Branko Čibej <br...@wandisco.com
> <mailto:br...@wandisco.com>> wrote:
>
> > 1 has not been marked as started nor been assigned but is tied to an
> > open serf issue:
> > 4274 DEFECT P3 All issues@subversion philip
> NEW 1.8.0 serf
> > client hangs when server crashes
>
> I reviewed this the other day and submitted
>
> https://code.google.com/p/serf/issues/detail?id=94
>
> as I believe the root cause is in Serf itself.
>
>
> How about this? If the connection never resulted in a successful HTTP
> response during its current lifetime (which gets zero'd in
> reset_connection), then we can return an error back upstream. I think
> we'll still be fine on Windows as the HUP should be detected *after*
> the full response is read by serf. So, in this case, we should bug
> out after a max of 2 attempts...and maybe one if OPTIONS is the first
> request on the connection.
>
> Index: outgoing.c
> ===================================================================
> --- outgoing.c (revision 1716)
> +++ outgoing.c (working copy)
> @@ -1111,7 +1111,10 @@
> /* The connection got reset by the server. On Windows this
> can happen
> when all data is read, so just cleanup the connection and open
> a new one. */
> - return reset_connection(conn, 1);
> + if (conn->completed_responses) {
> + return reset_connection(conn, 1);
> + }
> + return APR_EGENERAL;
> }
> if ((events & APR_POLLERR) != 0) {
> /* We might be talking to a buggy HTTP server that doesn't
>
Doesn't help ... apparently because we get both APR_POLLIN and
APR_POLLHUP events, and the former is processed first, the function
returns without error in the previous block:
/* If we decided to reset our connection, return now as we don't
* want to write.
*/
if ((conn->seen_in_pollset & APR_POLLHUP) != 0) {
return APR_SUCCESS;
}
I don't know enough about Serf to even begin guessing at the correct
solution.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
