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 <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
>> Sent: donderdag 26 november 2015 09:54
>> To: Bert Huijben <bert_at_qqmail.nl>
>> Cc: dev_at_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 <bert_at_qqmail.nl> wrote:
>> >> -----Original Message-----
>> >> From: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
>> >> Sent: donderdag 26 november 2015 09:19
>> >> To: dev_at_subversion.apache.org; Bert Huijben <bert_at_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, <rhuijben_at_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.

>
> This is why 'in general' you get not identical error reporting on commits when you use
> svn:// (or svn+ssh://, etc.). In many cases the only failure you see is the text from the
> server as the client doesn't even know which file/directory failed during the commit.
>
> With a bit of luck you receive errors a bit earlier than the final commit step. But with
> <= 1.9.0 this didn't work for svn+ssh:// on Windows at all. (We handled the error for
> not implemented as if no data was waiting)
>
Ouch. I think it's just an example that async/delayed error handling
is very tricky.

-- 
Ivan Zhakov