For some requests it might be safe, but in general it isn’t. And since the randomization added to the hash behavior the chance that it is unsafe increased.
But I’m afraid that we originally added this feature to cover for some other stability problem. (I didn’t see many broken connections with neon before. Why do we see them for serf?)
But I think we should remove these mid-request retries.
Bert
From: Ivan Zhakov
Sent: Thursday, July 11, 2013 2:35 PM
To: dev_at_subversion.apache.org; Stefan Sperling
On Thu, Jul 11, 2013 at 2:47 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> I'd like to change an SVN_ERR_MALFUNCTION() in ra_serf into an
> error return, because aborting doesn't help with diagnosing problems.
>
> I also think that we should check for overflow in this case, since
> code further down depends on that not happening. Not very likely,
> since it's an off_t, but still.
>
> Is this patch correct?
>
> [[[
> * subversion/libsvn_ra_serf/util.c
> (svn_ra_serf__handle_xml_parser): Check for read_size overflow and
> return an EOF error in case of aborting the process.
> ]]]
>
A little bit side note, but all this retry and continue logic looks
broken me. Where is the guarantee that retried request has the same
response? I think connection close in middle of receiving response
should be considered as error.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2013-07-11 16:26:37 CEST