Repo Browser takes a long time to change revisions
8 views
Skip to first unread message
fost...@gmail.com
Mar 4, 2019, 10:49:35 AM3/4/19
to TortoiseSVN
Under our server setup, it was possible for the Repo Browser to take 10+ minutes to change revisions.
The reason for this was that our SVN server (HTTPS) was behind a firewall that only allowed one SYN / second. It is an ASUS router that had DoS protection enabled.
When changing revisions, the Repo Browser would try to open several TCP connections to the server concurrently. When these SYNs wouldn't get ACKd, they'd retry once or twice. Eventually things seemed to lock up for about 10 minutes before another SYN was sent and the Repo Browser would properly update.
We've fixed the issue by identifying the firewall behavior and removing that. There are probably ways that this could be avoided from TortoiseSVN - either by having maybe an advanced option to limit the number of TCP connections per second, or trying to detect this type of limitation and adjust accordingly.
I'm not sure if there would be a different way to configure the server or client to have been able to get around this issue without adjusting the firewall. Either way, this might help someone who runs into the same issue we were seeing. Those darn firewalls!
The reason for this was that our SVN server (HTTPS) was behind a firewall that only allowed one SYN / second. It is an ASUS router that had DoS protection enabled.
When changing revisions, the Repo Browser would try to open several TCP connections to the server concurrently. When these SYNs wouldn't get ACKd, they'd retry once or twice. Eventually things seemed to lock up for about 10 minutes before another SYN was sent and the Repo Browser would properly update.
We've fixed the issue by identifying the firewall behavior and removing that. There are probably ways that this could be avoided from TortoiseSVN - either by having maybe an advanced option to limit the number of TCP connections per second, or trying to detect this type of limitation and adjust accordingly.
I'm not sure if there would be a different way to configure the server or client to have been able to get around this issue without adjusting the firewall. Either way, this might help someone who runs into the same issue we were seeing. Those darn firewalls!
Stefan
Mar 9, 2019, 3:45:11 PM3/9/19
to TortoiseSVN
On Monday, March 4, 2019 at 4:49:35 PM UTC+1, Colin Foster wrote:
We've fixed the issue by identifying the firewall behavior and removing that. There are probably ways that this could be avoided from TortoiseSVN - either by having maybe an advanced option to limit the number of TCP connections per second, or trying to detect this type of limitation and adjust accordingly.
limiting the number of connections wouldn't help with the speed.
And if it was possible to detect such firewall protections, viruses would do that too and render such protections useless.
Reply all
Reply to author
Forward
0 new messages