Not a bug - not a script problem - sourceforge issues

Was able to get to SF website just now, haven't started Mafia since about 15 hours ago. Then I started Mafia, didn't log in, opened gCLI and ran "svn update". The only scripts that updated were non-SF ones. Can't get to the SF website now.
 
Was able to get to SF website just now, haven't started Mafia since about 15 hours ago. Then I started Mafia, didn't log in, opened gCLI and ran "svn update". The only scripts that updated were non-SF ones. Can't get to the SF website now.

That has pretty much been my experience as well. There is a suggestion that the "block out" might last an hour.
 
As another experiment, I serialized the requests (it's as simple as moving the "t.start();" in SVNManager.doUpdate from line 1271 to just before the "t.join();" in the following loop).
I still got blocked after about 32 scripts, if I counted correctly and remember the count correctly.
 
As another experiment, I serialized the requests (it's as simple as moving the "t.start();" in SVNManager.doUpdate from line 1271 to just before the "t.join();" in the following loop).
I still got blocked after about 32 scripts, if I counted correctly and remember the count correctly.

What happens if you serialize and add a delay of like 1-5 seconds between each script?
 
I've been watching my once-daily svn update since this thread appeared. I've not had any errors yet. I only have 19 scripts and 9 of those are on Github.

Not sure what can be inferred from that information but thought I would toss it out there.
 
I can open several dozen browser tabs at sf.net concurrently loading all at once, so whatever it is, it's probably checking the user agent.

And I can start going down the list on script manager, right-clicking to update individual scripts. But as soon as I use "update all scripts", none of the SF scripts are updated. Appears that it shuts down all further operations on all parallel connections from the same IP as soon as the whatever threshold is reached, which then shuts down browser access too. After a few hours connections are allowed again.

It would be nice if we knew what the number of allowed concurrent connections was, and what timing was allowed, or any other criteria. That they would leave this sort of thing to trial and error... well, I'm no fan of SF already.

Meanwhile, maybe a couple of settings to help with this: number of concurrent connections to use, and time to wait until another connection is made.
 
BTW, I also managed to replicate this from normal commandline svn tool, so it's probably not anything specific to mafia's use of svnkit.
 
Update in the SourceForge ticket:
We have reverted a rate limit configuration change. I believe this should resolve the issue. Can someone confirm if it is working without issue now?

So they did implement a rate limit change which is almost certainly the source of our issue.

I just tried a SVN Update in mafia, and it worked without issue.
 
Hrm :(

Code:
       Connection has been shutdown: javax.net.ssl.SSLException:      java.net.SocketException: Connection reset
svn: E175002: OPTIONS      request failed on '/p/bale/relay/code/campground'

Oh hey now I'm getting a new one.
 
I'm having the same issues as the start of the thread as of 2 minutes ago. And I can't access SourceForge to add a me too to the ticket now...
 
Yeah, it was working for me for a while earlier, but now it's failing again. I'll poke the ticket too once I can get on their site again.

I keep Windscribe VPN on my system "just because". It can be installed in Firefox so that all the browser's traffic goes through the VPN. When I fail to connect to SoureForge, turning on the VPN will let me connect almost immediately which is how I made my report almost immediately after the failures returned.
 
Seems they may have "fixed" it again... still a bit slow to update but at least it updates now.
 
Back
Top