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

[David Hinken]

Hi all,

 

The TortoiseSVN “Get Lock…” for multiple files via a Java-SSL-tunnel fails for me since v1.9.0 (build 26652) up to the latest version v1.9.4 (27285). The older version 1.8.12 (build 26645) still works perfectly. Note that a direct connection (i.e. without tunnel) to the server works fine for all versions.

 

The SSL tunnel is created via a Java applet (“SSL tunnel applet 1.0”) running in Firefox because an authentification with a collax business server is required.

 

The issue arises when I select i.e. a directory in the windows explorer (Win7, x64) and choose “TortoiseSVN->Get Lock…”. The file-locking dialog appears and displays the first more or less 20 files and then hangs with a transfer speed of 0 bytes/s. Surprisingly, the locks are assigned to each file on the server, but the TortoiseSVN-client assigns it only to some files. Consequently, a “Release lock” only releases some but not all files and a “break lock” is required afterwards.

 

Did multiple file locking somehow changed from 1.8.12 to 1.9.0? The old version seems to request the lock file-by-file and the newer one seems to send out all requests at once.

 

Is this a bug in TortoiseSVN or is it a bug in the SSL tunnel applet?

 

Thanks for any help,

Best regards,

 

David

 

[David Hinken]

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171337

To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].

[Stefan Hett]

Hi David,

Hi all,

The TortoiseSVN “Get Lock…” for multiple files via a Java-SSL-tunnel fails for me since v1.9.0 (build 26652) up to the latest version v1.9.4 (27285). The older version 1.8.12 (build 26645) still works perfectly. Note that a direct connection (i.e. without tunnel) to the server works fine for all versions.

The SSL tunnel is created via a Java applet (“SSL tunnel applet 1.0”) running in Firefox because an authentification with a collax business server is required.

The issue arises when I select i.e. a directory in the windows explorer (Win7, x64) and choose “TortoiseSVN->Get Lock…”. The file-locking dialog appears and displays the first more or less 20 files and then hangs with a transfer speed of 0 bytes/s. Surprisingly, the locks are assigned to each file on the server, but the TortoiseSVN-client assigns it only to some files. Consequently, a “Release lock” only releases some but not all files and a “break lock” is required afterwards.

Did multiple file locking somehow changed from 1.8.12 to 1.9.0? The old version seems to request the lock file-by-file and the newer one seems to send out all requests at once.

That's correct. 1.9 introduced optimizations so that multiple locks are processed simultaneously rather than sequentially to speed up that operation. See: https://subversion.apache.org/docs/release-notes/1.9.html#lock-http-pipelining and https://subversion.apache.org/docs/release-notes/1.9.html#locking-multiple-files

Can you reproduce the issue using the SVN command line client directly? Does that issue any error? If so, you could also ask for help on the svn users list, since then it would be most likely an SVN issue rather than a TSVN issue.

-- 
Regards,
Stefan Hett

[David Hinken]

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.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171349

[Stefan Hett]

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.

-- 
Regards,
Stefan Hett

[David Hinken]

Yes, correct, it's not a proof that the problem is not related to svn itself.

Thanks for your time and help!

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171360

[David Hinken]

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?

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171395

[Stefan Hett]

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

[Stefan Hett]

Hi David,

On the SVN IRC channel I've been pointed to this known JIRA issue by stsp: https://issues.apache.org/jira/browse/SVN-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

[Stefan Küng]

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.apache.org/jira/browse/SVN-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

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171515

[Stefan Hett]

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

[Stefan Küng]

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

------------------------------------------------------

http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171518

[Stefan Hett]

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

[David Hinken]

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....

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171697

[Ivan Zhakov]

On 9 May 2016 at 14:29, David Hinken <d.hi...@isfh.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

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171698

[David Hinken]

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...

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171699

[Ivan Zhakov]

On 9 May 2016 at 14:48, David Hinken <d.hi...@isfh.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

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171700

[David Hinken]

> > 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:35741/svn/Test

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

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171702

[David Hinken]

> > 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:35741/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?

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171704

[Ivan Zhakov]

On 9 May 2016 at 15:03, David Hinken <d.hi...@isfh.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:35741/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_pipelining
--
Ivan Zhakov

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171706

[David Hinken]

> > > 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...

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171707

[David Hinken]

> 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:35741/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!

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171708

[Ivan Zhakov]

On 9 May 2016 at 15:23, David Hinken <d.hi...@isfh.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

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171711

[Ivan Zhakov]

On 9 May 2016 at 15:33, David Hinken <d.hi...@isfh.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:35741/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.apache.org/docs/release-notes/1.8.html#serf-skelta-default


---
Ivan Zhakov

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171713

[David Hinken]

> 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?

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171717

[Stefan Hett]

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

[David Hinken]

> >> 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.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171846

[David Hinken]

> > 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

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171848