Login | Register
My pages Projects Community openCollabNet

Discussions > users > TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Project highlights: :. Download .: :. Support .: :. FAQ .: :. Translations .: :. Donate .: :. Report Bug .:

tortoisesvn
Discussion topic

Hide all messages in topic

All messages in topic

RE: Re: Re: Re: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author david81
Full name David Hinken
Date 2016-05-10 06:32:38 PDT
Message > > Okay, great, this is a good hint to the problem. I will try to contact with the Java-Tunnel developers.
> >
> Please post results of your findings!

It seems quite difficult to contact the developers because it a proprietary development of one of our service providers. I will stay for the moment with svn <1.9.0 and hope that the tunnel will be fixed in the future.

Thanks again,

David

RE: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author david81
Full name David Hinken
Date 2016-05-10 06:20:48 PDT
Message > >> This could happen for three reasons:
> >> 1. The file is already locked before executing 'svn lock'.
> >> 2. 'Java SSL Tunnel' mixes-up HTTP requests and send one LOCK request
> >> multiple times.
> >> 3. There is bug in ra_serf/serf and it sends the same requests more
> >> than once in some circumstances.
> >>
> >> I assume that you're using clean repository for tests, so (1) is not
> >> likely the case. Bug in ra_serf/serf (3) is also possible, but I don't
> >> think it's very likely since issue doesn't trigger when accessing
> >> server directly. So in my opinion it's problem in Java SSL Tunnel (2).
> >> HTTP proxies/filters known to be working really bad with HTTP
> >> pipelining.
> > Yes, a clean repository was used.
> >
> > If http proxies are known to work really bad with http pipelining it might be a nice svn-feature to switch pipelining on and off?
> Given that SVN 1.9 is already out for several months and your report is
> the first one which seems to be related to some http pipelining
> problems, I wouldn't draw the conclusion that http proxies are in
> general known to work bad with http pipelining. Do you have any other
> reason to come to that conclusion?

This (general) statement was taken from Ivans answer. Maybe he has some more details about this topic?

Correct, it might be that the Java-Tunnel used in my case is quite particular and does not provide or badly implements http pipelining.

Besides it seems to be a propriatory development from one of our service providers and it seems quite difficult to contact the developers. So in my case I will stay with svn <1.9.0 for the moment and test again in some months.

Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author Stefan Hett <stefan at egosoft dot com>
Full name Stefan Hett <stefan at egosoft dot com>
Date 2016-05-10 02:33:37 PDT
Message On 5/9/2016 3:20 PM, David Hinken wrote:
>> On 9 May 2016 at 15:23, David Hinken <d dot hinken at isfh dot de> wrote:
>>>>>> Thanks for suggesting these options. The SVN server is a visual svn server,
>>>>>> standard edition. I think that checking the logs and setting both options
>>>>>> might be difficult (?) but I will give it a try. I hope playing with these settings
>>>>>> does not have any side effects...
>>>>> VisualSVN Server always logs all errors to 'Application and Services'
>>>>> | 'VisualSVN Server' log in Event Viewer.
>>>> I will check that.
>>> The logs are full with 'Failed to create new lock. [423, #160035]' messages,
>>> followed by 'Path '/trunk/svn_test/992.txt' is already locked by user '...' in filesystem
>>> '...' [423, #160035]' messages... Not sure if this is the problem itself or just a
>>> follow-up because some of the files cannot be released (a 'break lock') is required.
>>>
>> This could happen for three reasons:
>> 1. The file is already locked before executing 'svn lock'.
>> 2. 'Java SSL Tunnel' mixes-up HTTP requests and send one LOCK request
>> multiple times.
>> 3. There is bug in ra_serf/serf and it sends the same requests more
>> than once in some circumstances.
>>
>> I assume that you're using clean repository for tests, so (1) is not
>> likely the case. Bug in ra_serf/serf (3) is also possible, but I don't
>> think it's very likely since issue doesn't trigger when accessing
>> server directly. So in my opinion it's problem in Java SSL Tunnel (2).
>> HTTP proxies/filters known to be working really bad with HTTP
>> pipelining.
> Yes, a clean repository was used.
>
> If http proxies are known to work really bad with http pipelining it might be a nice svn-feature to switch pipelining on and off?
Given that SVN 1.9 is already out for several months and your report is
the first one which seems to be related to some http pipelining
problems, I wouldn't draw the conclusion that http proxies are in
general known to work bad with http pipelining. Do you have any other
reason to come to that conclusion?

--
Regards,
Stefan Hett
Attachments

RE: Re: Re: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author david81
Full name David Hinken
Date 2016-05-09 06:20:33 PDT
Message > On 9 May 2016 at 15:23, David Hinken <d dot hinken at isfh dot de> wrote:
> >> > > Thanks for suggesting these options. The SVN server is a visual svn server,
> >> > > standard edition. I think that checking the logs and setting both options
> >> > > might be difficult (?) but I will give it a try. I hope playing with these settings
> >> > > does not have any side effects...
> >> > VisualSVN Server always logs all errors to 'Application and Services'
> >> > | 'VisualSVN Server' log in Event Viewer.
> >>
> >> I will check that.
> >
> > The logs are full with 'Failed to create new lock. [423, #160035]' messages,
> > followed by 'Path '/trunk/svn_test/992.txt' is already locked by user '...' in filesystem
> > '...' [423, #160035]' messages... Not sure if this is the problem itself or just a
> > follow-up because some of the files cannot be released (a 'break lock') is required.
> >
> This could happen for three reasons:
> 1. The file is already locked before executing 'svn lock'.
> 2. 'Java SSL Tunnel' mixes-up HTTP requests and send one LOCK request
> multiple times.
> 3. There is bug in ra_serf/serf and it sends the same requests more
> than once in some circumstances.
>
> I assume that you're using clean repository for tests, so (1) is not
> likely the case. Bug in ra_serf/serf (3) is also possible, but I don't
> think it's very likely since issue doesn't trigger when accessing
> server directly. So in my opinion it's problem in Java SSL Tunnel (2).
> HTTP proxies/filters known to be working really bad with HTTP
> pipelining.

Yes, a clean repository was used.

If http proxies are known to work really bad with http pipelining it might be a nice svn-feature to switch pipelining on and off?

Re: Re: Re: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author Ivan Zhakov <ivan at visualsvn dot com>
Full name Ivan Zhakov <ivan at visualsvn dot com>
Date 2016-05-09 06:12:17 PDT
Message On 9 May 2016 at 15:33, David Hinken <d dot hinken at isfh dot de> wrote:
>> On 9 May 2016 at 15:03, David Hinken <d dot hinken at isfh dot de> wrote:
>> >> > Ivan suggested to use the svn command-line tool. I just tried it using a batch file
>> >> > and passed all 1000 text files to 'svn lock a b c ...'. It works fine without any trouble!
>> >> > It seems to work file-by-file and thus takes is slower is quite slow but work without problem.
>> >> It's really strange, because TortoiseSVN uses the same API in the same
>> >> way as Subversion command line client.
>> >>
>> >> What svn.exe version you're testing? You may use 'svn.exe --version'
>> >> command to find Subversion command line client version.
>> >
[...]

>> >> I'm not familiar with Java-Tunnel. Could you please share URL you're
>> >> using to checkout Subversion working copy.
>> >
>> > The URL is
>> > https://localhost:35​741/svn/Test
>> >
>> > and redirects via the Java-Tunnel (running in Firefox) to the SVN server.
>> >
>> Now it's more clear: Java-Tunnel acts as a proxy and forwards all
>> requests to SVN Server. The most likely problem that Java-Tunnel
>> doesn't implement HTTP pipelining [1] properly. HTTP pipelining is a
>> technique in which multiple HTTP requests are sent on a single TCP
>> connection without waiting for the corresponding responses. svn
>> lock/unlock uses HTTP pipelining to lock/unlock multiple files since
>> Subversion 1.9.0. HTTP pipelining is also used by 'svn checkout', but
>> this can be disabled on server or client-side.
>>
>> I suggest you report this problem to Java-Tunnel developers.
>
> HTTP pipelining can only be disabled for 'svn checkout' and not for 'svn lock' ?
>
Yes, it only can be disabled for 'svn checkout'/'svn update', but not
for 'svn lock'/'svn unlock'. Actually there is no option to control
HTTP pipelining. There is an option to control what kind of protocol
to use for 'svn checkout'/'svn update' [1]. But essentially it
controls using HTTP pipelining, since only one protocol uses multiple
HTTP requests.

> Okay, great, this is a good hint to the problem. I will try to contact with the Java-Tunnel developers.
>
Please post results of your findings!

[1] https://subversion.a​pache.org/docs/relea​se-notes/1.8.html#se​rf-skelta-default


---
Ivan Zhakov

Re: Re: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author Ivan Zhakov <ivan at visualsvn dot com>
Full name Ivan Zhakov <ivan at visualsvn dot com>
Date 2016-05-09 06:04:51 PDT
Message On 9 May 2016 at 15:23, David Hinken <d dot hinken at isfh dot de> wrote:
>> > > Thanks for suggesting these options. The SVN server is a visual svn server,
>> > > standard edition. I think that checking the logs and setting both options
>> > > might be difficult (?) but I will give it a try. I hope playing with these settings
>> > > does not have any side effects...
>> > VisualSVN Server always logs all errors to 'Application and Services'
>> > | 'VisualSVN Server' log in Event Viewer.
>>
>> I will check that.
>
> The logs are full with 'Failed to create new lock. [423, #160035]' messages,
> followed by 'Path '/trunk/svn_test/992.txt' is already locked by user '...' in filesystem
> '...' [423, #160035]' messages... Not sure if this is the problem itself or just a
> follow-up because some of the files cannot be released (a 'break lock') is required.
>
This could happen for three reasons:
1. The file is already locked before executing 'svn lock'.
2. 'Java SSL Tunnel' mixes-up HTTP requests and send one LOCK request
multiple times.
3. There is bug in ra_serf/serf and it sends the same requests more
than once in some circumstances.

I assume that you're using clean repository for tests, so (1) is not
likely the case. Bug in ra_serf/serf (3) is also possible, but I don't
think it's very likely since issue doesn't trigger when accessing
server directly. So in my opinion it's problem in Java SSL Tunnel (2).
HTTP proxies/filters known to be working really bad with HTTP
pipelining.

--
Ivan Zhakov

RE: Re: Re: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author david81
Full name David Hinken
Date 2016-05-09 05:33:25 PDT
Message > On 9 May 2016 at 15:03, David Hinken <d dot hinken at isfh dot de> wrote:
> >> > Ivan suggested to use the svn command-line tool. I just tried it using a batch file
> >> > and passed all 1000 text files to 'svn lock a b c ...'. It works fine without any trouble!
> >> > It seems to work file-by-file and thus takes is slower is quite slow but work without problem.
> >> It's really strange, because TortoiseSVN uses the same API in the same
> >> way as Subversion command line client.
> >>
> >> What svn.exe version you're testing? You may use 'svn.exe --version'
> >> command to find Subversion command line client version.
> >
> > Sorry, my mistake, I had two versions of subversion installed.
> >
> > svn version 1.8.13 (r1667537) works file-by-file and works without any problem.
> >
> > svn version 1.9.4 (r1740329) shows a similar behaviour as TSVN. It tries to lock
> > about 30-40 files at once and then hangs without any sign of progress.
> >
> Does it hang after successfully locking 30-40 files or it doesn't work
> completely when attempt to lock more than 30-40 files at once?

Not sure. I attempt to lock about 1000 files. It seems that the first 30-40 files are locked correctly 'Message is: Locked by ...'. Then it hangs for about 5 minutes and after that continues. I then have a lock for nearly all of the files except for some, which are locked but 'in another working copy', as stated by svn. For these files I have to break the locks.


> >> I'm not familiar with Java-Tunnel. Could you please share URL you're
> >> using to checkout Subversion working copy.
> >
> > The URL is
> > https://localhost:35​741/svn/Test
> >
> > and redirects via the Java-Tunnel (running in Firefox) to the SVN server.
> >
> Now it's more clear: Java-Tunnel acts as a proxy and forwards all
> requests to SVN Server. The most likely problem that Java-Tunnel
> doesn't implement HTTP pipelining [1] properly. HTTP pipelining is a
> technique in which multiple HTTP requests are sent on a single TCP
> connection without waiting for the corresponding responses. svn
> lock/unlock uses HTTP pipelining to lock/unlock multiple files since
> Subversion 1.9.0. HTTP pipelining is also used by 'svn checkout', but
> this can be disabled on server or client-side.
>
> I suggest you report this problem to Java-Tunnel developers.

HTTP pipelining can only be disabled for 'svn checkout' and not for 'svn lock' ?

Okay, great, this is a good hint to the problem. I will try to contact with the Java-Tunnel developers.

Thanks to all of you for the fast support!

RE: Re: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author david81
Full name David Hinken
Date 2016-05-09 05:23:16 PDT
Message > > > Thanks for suggesting these options. The SVN server is a visual svn server,
> > > standard edition. I think that checking the logs and setting both options
> > > might be difficult (?) but I will give it a try. I hope playing with these settings
> > > does not have any side effects...
> > VisualSVN Server always logs all errors to 'Application and Services'
> > | 'VisualSVN Server' log in Event Viewer.
>
> I will check that.

The logs are full with 'Failed to create new lock. [423, #160035]' messages, followed by 'Path '/trunk/svn_test/992.txt' is already locked by user '...' in filesystem '...' [423, #160035]' messages... Not sure if this is the problem itself or just a follow-up because some of the files cannot be released (a 'break lock') is required.

I cannot find any other error...

VisualSVNServer is of version 3.5.2. But it already happened in an older version as well...

Re: Re: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author Ivan Zhakov <ivan at visualsvn dot com>
Full name Ivan Zhakov <ivan at visualsvn dot com>
Date 2016-05-09 05:18:28 PDT
Message On 9 May 2016 at 15:03, David Hinken <d dot hinken at isfh dot de> wrote:
>> > Ivan suggested to use the svn command-line tool. I just tried it using a batch file
>> > and passed all 1000 text files to 'svn lock a b c ...'. It works fine without any trouble!
>> > It seems to work file-by-file and thus takes is slower is quite slow but work without problem.
>> It's really strange, because TortoiseSVN uses the same API in the same
>> way as Subversion command line client.
>>
>> What svn.exe version you're testing? You may use 'svn.exe --version'
>> command to find Subversion command line client version.
>
> Sorry, my mistake, I had two versions of subversion installed.
>
> svn version 1.8.13 (r1667537) works file-by-file and works without any problem.
>
> svn version 1.9.4 (r1740329) shows a similar behaviour as TSVN. It tries to lock
> about 30-40 files at once and then hangs without any sign of progress.
>
Does it hang after successfully locking 30-40 files or it doesn't work
completely when attempt to lock more than 30-40 files at once?

>> I'm not familiar with Java-Tunnel. Could you please share URL you're
>> using to checkout Subversion working copy.
>
> The URL is
> https://localhost:35​741/svn/Test
>
> and redirects via the Java-Tunnel (running in Firefox) to the SVN server.
>
Now it's more clear: Java-Tunnel acts as a proxy and forwards all
requests to SVN Server. The most likely problem that Java-Tunnel
doesn't implement HTTP pipelining [1] properly. HTTP pipelining is a
technique in which multiple HTTP requests are sent on a single TCP
connection without waiting for the corresponding responses. svn
lock/unlock uses HTTP pipelining to lock/unlock multiple files since
Subversion 1.9.0. HTTP pipelining is also used by 'svn checkout', but
this can be disabled on server or client-side.

I suggest you report this problem to Java-Tunnel developers.

[1] https://en.wikipedia​.org/wiki/HTTP_pipel​ining
--
Ivan Zhakov

RE: Re: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author david81
Full name David Hinken
Date 2016-05-09 05:10:18 PDT
Message > > Thanks for suggesting these options. The SVN server is a visual svn server,
> > standard edition. I think that checking the logs and setting both options
> > might be difficult (?) but I will give it a try. I hope playing with these settings
> > does not have any side effects...
> VisualSVN Server always logs all errors to 'Application and Services'
> | 'VisualSVN Server' log in Event Viewer.

I will check that.

> I'm still do not understand what is 'Java-SSL-Tunnel' and how it
> works. Does it act as proxy server? What URL do you use as URL for
> Subversion client (http:// or https://)?

https://localhost:35​741/svn/Test

The svn server cannot directly be accessed via internet, only via the Java-tunnel. To create that tunnel I have to log into a web interface. After a successfull login the tunnel can be created. So I suppose (without too much technical knowledge) that the svn-server is running behind a firewall and the tunnel acts as a proxy?

RE: Re: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author david81
Full name David Hinken
Date 2016-05-09 05:03:20 PDT
Message > > Ivan suggested to use the svn command-line tool. I just tried it using a batch file
> > and passed all 1000 text files to 'svn lock a b c ...'. It works fine without any trouble!
> > It seems to work file-by-file and thus takes is slower is quite slow but work without problem.
> It's really strange, because TortoiseSVN uses the same API in the same
> way as Subversion command line client.
>
> What svn.exe version you're testing? You may use 'svn.exe --version'
> command to find Subversion command line client version.

Sorry, my mistake, I had two versions of subversion installed.

svn version 1.8.13 (r1667537) works file-by-file and works without any problem.

svn version 1.9.4 (r1740329) shows a similar behaviour as TSVN. It tries to lock about 30-40 files at once and then hangs without any sign of progress.

> I'm not familiar with Java-Tunnel. Could you please share URL you're
> using to checkout Subversion working copy.

The URL is

https://localhost:35​741/svn/Test

and redirects via the Java-Tunnel (running in Firefox) to the SVN server.

Re: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author Ivan Zhakov <ivan at visualsvn dot com>
Full name Ivan Zhakov <ivan at visualsvn dot com>
Date 2016-05-09 05:00:43 PDT
Message On 9 May 2016 at 14:48, David Hinken <d dot hinken at isfh dot de> wrote:
> Thanks for suggesting these options. The SVN server is a visual svn server,
> standard edition. I think that checking the logs and setting both options
> might be difficult (?) but I will give it a try. I hope playing with these settings
> does not have any side effects...
VisualSVN Server always logs all errors to 'Application and Services'
| 'VisualSVN Server' log in Event Viewer.

I'm still do not understand what is 'Java-SSL-Tunnel' and how it
works. Does it act as proxy server? What URL do you use as URL for
Subversion client (http:// or https://)?

--
Ivan Zhakov

RE: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author david81
Full name David Hinken
Date 2016-05-09 04:48:44 PDT
Message Thanks for suggesting these options. The SVN server is a visual svn server, standard edition. I think that checking the logs and setting both options might be difficult (?) but I will give it a try. I hope playing with these settings does not have any side effects...

Re: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author Ivan Zhakov <ivan at visualsvn dot com>
Full name Ivan Zhakov <ivan at visualsvn dot com>
Date 2016-05-09 04:40:03 PDT
Message On 9 May 2016 at 14:29, David Hinken <d dot hinken at isfh dot de> wrote:
> Thanks Stefan for posting this issue in the SVN group. I was not subscribed
> so far to this list so unfortunately I cannot directly answer to that thread.
>
> Ivan suggested to use the svn command-line tool. I just tried it using a batch file
> and passed all 1000 text files to 'svn lock a b c ...'. It works fine without any trouble!
> It seems to work file-by-file and thus takes is slower is quite slow but work without problem.
It's really strange, because TortoiseSVN uses the same API in the same
way as Subversion command line client.

What svn.exe version you're testing? You may use 'svn.exe --version'
command to find Subversion command line client version.

>
> TSVN instead fails with the transfer-speed-zero-problem. It again seems that TSVN
> tries to lock many files at once and then becomes blocked.
>
> 'https' is used in the Java-Tunnel....
>
I'm not familiar with Java-Tunnel. Could you please share URL you're
using to checkout Subversion working copy.

--
Ivan Zhakov

RE: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author david81
Full name David Hinken
Date 2016-05-09 04:29:20 PDT
Message Thanks Stefan for posting this issue in the SVN group. I was not subscribed so far to this list so unfortunately I cannot directly answer to that thread.

Ivan suggested to use the svn command-line tool. I just tried it using a batch file and passed all 1000 text files to 'svn lock a b c ...'. It works fine without any trouble! It seems to work file-by-file and thus takes is slower is quite slow but work without problem.

TSVN instead fails with the transfer-speed-zero-problem. It again seems that TSVN tries to lock many files at once and then becomes blocked.

'https' is used in the Java-Tunnel....

Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author Stefan Hett <stefan at egosoft dot com>
Full name Stefan Hett <stefan at egosoft dot com>
Date 2016-05-06 05:34:47 PDT
Message On 5/6/2016 2:28 PM, Stefan Küng wrote:
> On 06.05.2016 13:43, Stefan Hett wrote:
>
>>> TSVN of course uses the svn library APIs to do the locking.
>>> It passes all files to be locked to the API at once, and then the API
>>> would do the locking.
>> With regards to determine the impact from the Subversion project point
>> of view: Do you know whether that API was available in 1.8 already (aka:
>> passing multiple files to be locked) or whether that API was introduced
>> in 1.9 (and TSVN 1.8 used a different API)?
> The API was available in 1.8 as well (actually, the API hasn't changed
> since version 1.2). But the underlying protocol and how the svn lib
> handles the locks have changed. For example, when the API was introduced
> svn still used the neon lib for DAV requests, then came serf, and then
> neon was dropped. So a lot has changed under the hood.
K, that's changing the impact IMO.
Aka in this case it could be argued a regression in SVN 1.9 itself
(rather than only a bug) since the same API worked fine under the same
environment in 1.8 while it doesn't with 1.9... Let's see what the SVN
developers make out of that.

--
Regards,
Stefan Hett, Developer/Administrator

EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473
Attachments

Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author steveking
Full name Stefan Küng
Date 2016-05-06 05:28:13 PDT
Message On 06.05.2016 13:43, Stefan Hett wrote:

>> TSVN of course uses the svn library APIs to do the locking.
>> It passes all files to be locked to the API at once, and then the API
>> would do the locking.

> With regards to determine the impact from the Subversion project point
> of view: Do you know whether that API was available in 1.8 already (aka:
> passing multiple files to be locked) or whether that API was introduced
> in 1.9 (and TSVN 1.8 used a different API)?

The API was available in 1.8 as well (actually, the API hasn't changed
since version 1.2). But the underlying protocol and how the svn lib
handles the locks have changed. For example, when the API was introduced
svn still used the neon lib for DAV requests, then came serf, and then
neon was dropped. So a lot has changed under the hood.

> Also FWIW: After thinking further about the impact on SVN I went ahead
> and forwarded the issue to the SVN user's list referencing this thread
> here. Topic on the SVN list: "Problem with locking multiple files."

Ok, thanks.

Stefan

--
        ___
   oo // \\ "De Chelonian Mobile"
  (_,\/ \_/ \ TortoiseSVN
    \ \_/_\_/> The coolest interface to (Sub)version control
    /_/ \_\ http://tortoisesvn.net

Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author Stefan Hett <stefan at egosoft dot com>
Full name Stefan Hett <stefan at egosoft dot com>
Date 2016-05-06 04:43:03 PDT
Message Hi Stefan and David,
> On 06.05.2016 13:12, Stefan Hett wrote:
>> Hi David,
>>> Hi David,
>>>> I run another check with 1000 files in a test directory:
>>>> -> Just saying 'svn lock *' works fine, it locks file after file and gives a good visual feedback of what is happening.
>>>> -> TortoiseSVN (v1.9.4) instead shows up nearly immeadiatly "Locked by ... file ..." for about 37 files, then pauses with transfer-speed-zero. If waiting long enough (about 5 min) it continues working but throws an already-locked-error for about 50 files and then continues locking the missing ones correctly.
>>>>
>>>> For me it seems that TortoiseSVN somehow tries to lock a bunch of files immeadiatly but can't receive all server-answers on a slow (bad?) connection (Java-SSL-Tunnel) and finally times out. SVN instead seems to work file-by-file (as did Tortoise 1.8.12) and manages to lock all files without problems.
>>>>
>>>> Could this be a possible explanation? Is there a possibility (i.e. a setting) to switch back to the "old" file-by-file locking?
>>>>
>>> That's kind of my suspicion here too (aka: some operation fails/breaks
>>> on the server or the transmission is lost, client waits for a time out
>>> and then you have the hang which you are describing).
>>>
>>> Maybe Stefan Küng can confirm whether TSVN just utilizes the SVN
>>> library here directly (rather than doing some special things itself).
>>> If so, it's worth moving that on to the SVN users list, I guess...
> TSVN of course uses the svn library APIs to do the locking.
> It passes all files to be locked to the API at once, and then the API
> would do the locking.
With regards to determine the impact from the Subversion project point
of view: Do you know whether that API was available in 1.8 already (aka:
passing multiple files to be locked) or whether that API was introduced
in 1.9 (and TSVN 1.8 used a different API)?

Also FWIW: After thinking further about the impact on SVN I went ahead
and forwarded the issue to the SVN user's list referencing this thread
here. Topic on the SVN list: "Problem with locking multiple files."


--
Regards,
Stefan Hett
Attachments

Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author steveking
Full name Stefan Küng
Date 2016-05-06 04:34:59 PDT
Message On 06.05.2016 13:12, Stefan Hett wrote:
> Hi David,
>> Hi David,
>>> I run another check with 1000 files in a test directory:
>>> -> Just saying 'svn lock *' works fine, it locks file after file and gives a good visual feedback of what is happening.
>>> -> TortoiseSVN (v1.9.4) instead shows up nearly immeadiatly "Locked by ... file ..." for about 37 files, then pauses with transfer-speed-zero. If waiting long enough (about 5 min) it continues working but throws an already-locked-error for about 50 files and then continues locking the missing ones correctly.
>>>
>>> For me it seems that TortoiseSVN somehow tries to lock a bunch of files immeadiatly but can't receive all server-answers on a slow (bad?) connection (Java-SSL-Tunnel) and finally times out. SVN instead seems to work file-by-file (as did Tortoise 1.8.12) and manages to lock all files without problems.
>>>
>>> Could this be a possible explanation? Is there a possibility (i.e. a setting) to switch back to the "old" file-by-file locking?
>>>
>> That's kind of my suspicion here too (aka: some operation fails/breaks
>> on the server or the transmission is lost, client waits for a time out
>> and then you have the hang which you are describing).
>>
>> Maybe Stefan Küng can confirm whether TSVN just utilizes the SVN
>> library here directly (rather than doing some special things itself).
>> If so, it's worth moving that on to the SVN users list, I guess...

TSVN of course uses the svn library APIs to do the locking.
It passes all files to be locked to the API at once, and then the API
would do the locking.


> On the SVN IRC channel I've been pointed to this known JIRA issue by
> stsp: https://issues.apach​e.org/jira/browse/SV​N-4557
> This could be the problem you are facing.
>
> The underlying change between SVN 1.8 and 1.9 here is that 1.9 can
> produce an http-header section which is much larger than it would be
> with the 1.8 client. That however depends on some changes in TSVN and I
> can't confirm whether that really is the case (maybe someone else can do).

To test that, you could configure Apache with a higher value of the
LimitRequestFieldSize
configuration.

> For instance if SVN 1.9 would introduce a new API supporting the
> multi-lock-case and TSVN 1.9 makes use of that (while TSVN 1.8 would use
> the older SVN API) the net result is that with 1.9 you run into the
> header-issue described in SVN-4557 while with TSVN 1.8 you wouldn't.
>
> Given that you state you don't have any issues when not using the
> SSL-tunnel, I could imagine that the SSL-tunnel protocol/server is
> having trouble with passing on the longer http-header section in 1.9.
> Maybe that's a lead helping you to find a workaround?

the svn 'servers' config file has a few options which might help here as
well:
http-chunked-requests
and
http-bulk-updates

not sure if those are even in play here, but worth a try.


Stefan

--
        ___
   oo // \\ "De Chelonian Mobile"
  (_,\/ \_/ \ TortoiseSVN
    \ \_/_\_/> The coolest interface to (Sub)version control
    /_/ \_\ http://tortoisesvn.net

Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author Stefan Hett <stefan at egosoft dot com>
Full name Stefan Hett <stefan at egosoft dot com>
Date 2016-05-06 04:12:08 PDT
Message Hi David,
> Hi David,
>> I run another check with 1000 files in a test directory:
>> -> Just saying 'svn lock *' works fine, it locks file after file and gives a good visual feedback of what is happening.
>> -> TortoiseSVN (v1.9.4) instead shows up nearly immeadiatly "Locked by ... file ..." for about 37 files, then pauses with transfer-speed-zero. If waiting long enough (about 5 min) it continues working but throws an already-locked-error for about 50 files and then continues locking the missing ones correctly.
>>
>> For me it seems that TortoiseSVN somehow tries to lock a bunch of files immeadiatly but can't receive all server-answers on a slow (bad?) connection (Java-SSL-Tunnel) and finally times out. SVN instead seems to work file-by-file (as did Tortoise 1.8.12) and manages to lock all files without problems.
>>
>> Could this be a possible explanation? Is there a possibility (i.e. a setting) to switch back to the "old" file-by-file locking?
>>
> That's kind of my suspicion here too (aka: some operation fails/breaks
> on the server or the transmission is lost, client waits for a time out
> and then you have the hang which you are describing).
>
> Maybe Stefan Küng can confirm whether TSVN just utilizes the SVN
> library here directly (rather than doing some special things itself).
> If so, it's worth moving that on to the SVN users list, I guess...
On the SVN IRC channel I've been pointed to this known JIRA issue by
stsp: https://issues.apach​e.org/jira/browse/SV​N-4557
This could be the problem you are facing.

The underlying change between SVN 1.8 and 1.9 here is that 1.9 can
produce an http-header section which is much larger than it would be
with the 1.8 client. That however depends on some changes in TSVN and I
can't confirm whether that really is the case (maybe someone else can do).

For instance if SVN 1.9 would introduce a new API supporting the
multi-lock-case and TSVN 1.9 makes use of that (while TSVN 1.8 would use
the older SVN API) the net result is that with 1.9 you run into the
header-issue described in SVN-4557 while with TSVN 1.8 you wouldn't.

Given that you state you don't have any issues when not using the
SSL-tunnel, I could imagine that the SSL-tunnel protocol/server is
having trouble with passing on the longer http-header section in 1.9.
Maybe that's a lead helping you to find a workaround?
You could also check your server logs to see whether that's the actual
problem and where it is located (for instance for Apache 2.4 it could
report something like: Request header exceeds LimitRequestFieldSize). If
so and it's a feasible option for you, you could tweak the corresponding
server side setting.

--
Regards,
Stefan Hett
Attachments

Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author Stefan Hett <stefan at egosoft dot com>
Full name Stefan Hett <stefan at egosoft dot com>
Date 2016-05-06 03:07:23 PDT
Message Hi David,
> I run another check with 1000 files in a test directory:
> -> Just saying 'svn lock *' works fine, it locks file after file and gives a good visual feedback of what is happening.
> -> TortoiseSVN (v1.9.4) instead shows up nearly immeadiatly "Locked by ... file ..." for about 37 files, then pauses with transfer-speed-zero. If waiting long enough (about 5 min) it continues working but throws an already-locked-error for about 50 files and then continues locking the missing ones correctly.
>
> For me it seems that TortoiseSVN somehow tries to lock a bunch of files immeadiatly but can't receive all server-answers on a slow (bad?) connection (Java-SSL-Tunnel) and finally times out. SVN instead seems to work file-by-file (as did Tortoise 1.8.12) and manages to lock all files without problems.
>
> Could this be a possible explanation? Is there a possibility (i.e. a setting) to switch back to the "old" file-by-file locking?
>
That's kind of my suspicion here too (aka: some operation fails/breaks
on the server or the transmission is lost, client waits for a time out
and then you have the hang which you are describing).

Maybe Stefan Küng can confirm whether TSVN just utilizes the SVN library
here directly (rather than doing some special things itself). If so,
it's worth moving that on to the SVN users list, I guess...

--
Regards,
Stefan Hett
Attachments

RE: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author david81
Full name David Hinken
Date 2016-05-04 10:47:19 PDT
Message I run another check with 1000 files in a test directory:
-> Just saying 'svn lock *' works fine, it locks file after file and gives a good visual feedback of what is happening.
-> TortoiseSVN (v1.9.4) instead shows up nearly immeadiatly "Locked by ... file ..." for about 37 files, then pauses with transfer-speed-zero. If waiting long enough (about 5 min) it continues working but throws an already-locked-error for about 50 files and then continues locking the missing ones correctly.

For me it seems that TortoiseSVN somehow tries to lock a bunch of files immeadiatly but can't receive all server-answers on a slow (bad?) connection (Java-SSL-Tunnel) and finally times out. SVN instead seems to work file-by-file (as did Tortoise 1.8.12) and manages to lock all files without problems.

Could this be a possible explanation? Is there a possibility (i.e. a setting) to switch back to the "old" file-by-file locking?

RE: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author david81
Full name David Hinken
Date 2016-05-04 06:04:36 PDT
Message Yes, correct, it's not a proof that the problem is not related to svn itself.

Thanks for your time and help!

Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author Stefan Hett <stefan at egosoft dot com>
Full name Stefan Hett <stefan at egosoft dot com>
Date 2016-05-04 05:29:14 PDT
Message Oh right. Didn't know that svn lock doesn't provide a command line
option to apply locks recursively.
Your test run however doesn't proof that the issue wouldn't be in the
svn library (rather than in TSVN).

If nobody can help you here, it would be worth to raise the issue also
on the SVN user list. Since you already tested that there's no problem
with the 1.8 client and there's also no problem when you bypass the
SSL-Tunnel and use a direct connection, it at least hints towards some
issue on the SVN side, IMO.

> Thanks, Stefan, for pointing out the SVN problem.
>
> As far as I know I can't use 'svn' to lock files within subdirectories recursively, so I can't directly test that approach. But I created a test repository to run 'svn lock' on many (nearly empty) files and first tried to test with TortoiseSVN if the same problem reappears (all testing done with the Java-SSL-Tunnel):
>
> Original Directory with 681 files, 64 folders, 29.2MB total size
> -> locking (TortoiseSVN v1.9.4) hangs with transfer-speed=0bytes/s
>
> Test Directory with 1601, 15 folders, 8KB Total size
> -> locking (TortoiseSVN v1.9.4) works fine
>
> Such it seems to be a problem with my file/directory structure.
>
> I tried a fresh checkout of that repository. A first run with TortoiseSVN v1.9.4 did succeed for all files! However, a second run failed again with the transfer-speed-zero problem.
>
> Does this still point to a problem in SVN? Or is it more likely a TortoiseSVN problem? Or the tunnel itself?
>
> Thanks for helping.
>
> Best regards,
> David
>
> P.S. Sorry for posting the question twice. Can you as admin delete the second question? Thanks.
>
> --------------------​--------------------​--------------
> http://tortoisesvn.t​igris.org/ds/viewMes​sage.do?dsForumId=40​61&dsMessageId=3​171349
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe@t​ortoisesvn.tigris.or​g].
>


--
Regards,
Stefan Hett
Attachments

RE: Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

Author david81
Full name David Hinken
Date 2016-05-04 04:59:16 PDT
Message Thanks, Stefan, for pointing out the SVN problem.

As far as I know I can't use 'svn' to lock files within subdirectories recursively, so I can't directly test that approach. But I created a test repository to run 'svn lock' on many (nearly empty) files and first tried to test with TortoiseSVN if the same problem reappears (all testing done with the Java-SSL-Tunnel):

Original Directory with 681 files, 64 folders, 29.2MB total size
-> locking (TortoiseSVN v1.9.4) hangs with transfer-speed=0bytes/s

Test Directory with 1601, 15 folders, 8KB Total size
-> locking (TortoiseSVN v1.9.4) works fine

Such it seems to be a problem with my file/directory structure.

I tried a fresh checkout of that repository. A first run with TortoiseSVN v1.9.4 did succeed for all files! However, a second run failed again with the transfer-speed-zero problem.

Does this still point to a problem in SVN? Or is it more likely a TortoiseSVN problem? Or the tunnel itself?

Thanks for helping.

Best regards,
David

P.S. Sorry for posting the question twice. Can you as admin delete the second question? Thanks.
Page: of 2 « Previous | Next »
Messages per page: