Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of nkadel@gmail.com designates
 209.85.217.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABw-3Yfvu0tztNxoSd3j3MyS1s6xn8iLCDxGLf_D7AyJ-jWntg@mail.gmail.com>
References: <52035462.1030802@viscomvisual.com>
	<20130808083618.GJ31959@ted.stsp.name>
	<CABw-3Yfvu0tztNxoSd3j3MyS1s6xn8iLCDxGLf_D7AyJ-jWntg@mail.gmail.com>
Date: Thu, 8 Aug 2013 07:04:16 -0400
Message-ID: 
 <CAOCN9rxojhOg0_2BuzzBx35u9eHj=hYHp+nGbjm+Hip_Xb49mQ@mail.gmail.com>
Subject: Re: svn client 1.8.1: Tries to log-in forever, hammering the server,
 eating memory and cpu
From: Nico Kadel-Garcia <nkadel@gmail.com>
To: Ivan Zhakov <ivan@visualsvn.com>
Cc: Elias Gerber <eg@viscomvisual.com>, users@subversion.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 8, 2013 at 5:32 AM, Ivan Zhakov <ivan@visualsvn.com> wrote:
> On Thu, Aug 8, 2013 at 12:36 PM, Stefan Sperling <stsp@elego.de> wrote:
>> On Thu, Aug 08, 2013 at 10:18:42AM +0200, Elias Gerber wrote:
>>> Since svn 1.8.x we experience the following:
>>> Clients that are part of the domain can log in without any problems.
>>> Clients that are not part of the domain try to log-in forever using
>>> the local account. The server rejects those credentials - it only
>>> knows about domain-users, not about local users. The client does not
>>> stop to log in then, but tries forever: At the server we see
>>> thousands of rejected log-in requests, at the client we see that it
>>> uses one core of the cpu 100% and eats more and more memory and
>>> never (? - I killed it when it reached more than one Gigabyte of
>>> memory) stops.
>>
>> My guess would be this issue in serf:
>> http://code.google.com/p/serf/issues/detail?id=77
>>
>> The 1.7 client uses neon instead of serf and optionally supports serf,
>> but not many people used serf with 1.7 clients.
>> Support for neon has been removed as of 1.8. The serf developers are
>> working hard on issues that pop up now that people are actually using it.
>>
> This is definitely serf issue 77. Issue should be fixed in r2112. And
> most likely will be backported to next serf 1.3.x release.

Can you and your colleagues switch to svn+ssh protocol? They don't get
the trivial single-sign-on for HTTPS access, but it would prevent this
issue in the meantime.