> -----Original Message-----
> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> Sent: donderdag 26 november 2015 10:27
> To: Bert Huijben <b...@qqmail.nl>
> Cc: dev@subversion.apache.org
> Subject: Re: svn commit: r1716575 - in
> /subversion/trunk/subversion/libsvn_ra_serf: commit.c ra_serf.h util.c
>
> On 26 November 2015 at 12:11, Bert Huijben <b...@qqmail.nl> wrote:
> >> -----Original Message-----
> >> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> >> Sent: donderdag 26 november 2015 09:54
> >> To: Bert Huijben <b...@qqmail.nl>
> >> Cc: dev@subversion.apache.org
> >> Subject: Re: svn commit: r1716575 - in
> >> /subversion/trunk/subversion/libsvn_ra_serf: commit.c ra_serf.h util.c
> >>
> >> On 26 November 2015 at 11:41, Bert Huijben <b...@qqmail.nl> wrote:
> >> >> -----Original Message-----
> >> >> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> >> >> Sent: donderdag 26 november 2015 09:19
> >> >> To: dev@subversion.apache.org; Bert Huijben <b...@qqmail.nl>
> >> >> Subject: Re: svn commit: r1716575 - in
> >> >> /subversion/trunk/subversion/libsvn_ra_serf: commit.c ra_serf.h util.c
> >> >>
> >> >> On 26 November 2015 at 11:05, <rhuij...@apache.org> wrote:
> >> >> >
> >> >> > Author: rhuijben
> >> >> > Date: Thu Nov 26 08:05:36 2015
> >> >> > New Revision: 1716575
> >> >> >
> >> >> > URL: http://svn.apache.org/viewvc?rev=1716575&view=rev
> >> >> > Log:
> >> >> > In ra_serf: when a to-be committed file has text and property
> changes
> >> to
> >> >> be
> >> >> > applied, pipeline both requests.
> >> >> >
> >> >> This could fail over HTTP/2 if both pipelined requests will be handled
> >> >> by different worker threads: FSFS doesn't allow concurrent access to
> >> >> transactions.
> >> >
> >> > I'm surprised to learn that. I would have guessed concurrent access was
> >> > always part of the design of the fs layer, by the way we use it in
> mod_dav.
> >> >
> >> > I hope we can somehow lift that restriction, as improving commit
> >> performance
> >> > over mod_dav is high on a few wish lists.
> >> >
> >> First of all I'm not sure that concurrent *writing* could speed up
> >> commit: there is no fsync() calls when working with transactions. As
> >> far I remember svn:// also waits for every TXN operation to complete
> >> before sending next one, so svn:// and http:// performance should be
> >> the same when working over high-latency network.
> >
> > No, in svn:// the client sends out all the requests and only peeks the
> > connection to see if there is waiting data (an error) during commit. The
> client
> > only waits for the server after the entire commit is completed. Not after
> every txn operation.
> Yes, you are right. But such error handling will make connection
> unusable after error, is not it? And as far I remember ra_svn doesn't
> have code to reconnect if needed.
No, it will recover just fine here. No problem at all for many versions. If it
didn't you would see a broken connection at every commit with an out of date.
The cases where the connection broke is where it sends an error where a strict
result was expected.
All cases I know of were fixed on trunk though. (I added tests to explicitly
trigger errors in each ra call)
Some fixes were backported to 1.8 / 1.9.
I did this in preparation for backporting the ra-session reuse work.
Bert
