[CalendarServer-dev] [CalendarServer] #260: OpenLDAP directory service

CalendarServer trac at macosforge.org
Thu Oct 15 13:21:19 PDT 2009


#260: OpenLDAP directory service
---------------------------------------+------------------------------------
 Reporter:  jusiskin@…                 |       Owner:  sagen@…           
     Type:  Feature                    |      Status:  new               
 Priority:  2: Expected                |   Milestone:  CalendarServer-2.x
Component:  Calendar Server            |    Severity:  Other             
 Keywords:                             |  
---------------------------------------+------------------------------------

Comment(by rahul@…):

 I have figured out the problem. I could probably say the problem is with
 the client (Thunderbird beta+Lightning). When connection to the calendar
 server fails because the username does not exist or if the authentication
 fails because the wrong password was saved in Thunderbird, the client
 should stop connecting (or try after some time). But instead it kept on
 trying to reconnect which affected the calendar server in two ways:

 1. The major affect was when clients which were configured with usernames
 not existing in the ldap directory kept trying to connect. As the username
 was not found in the cache, the entire cache for users was being refreshed
 by the ldap patch in this page. And as the client kept on trying to
 reconnect upon failure, the cache was refreshed continuously which
 increased the cpu usage tremendously.

 2. Also upon authentication failure, the client kept retrying which also
 lead to an increase in CPU usage. But this overload was not as high as in
 the previous case.

 The obvious fix is to fix the code with client (Thunderbird and/or
 Lightning). When connection fails 2 or 3 times for whatever reason
 (username does not exist, wrong password entered, etc.), connection
 attempts should be stopped.

 Also some code modification could be done on the server side to limit
 connections from such misconfigured clients so that other users do not
 face any inconvenience because of these small number of badly configured
 clients


 Replying to [comment:34 rahul@…]:
 > I would like to know whether anyone is using this patch in a production
 environment. I am using this patch with calendarserver in a company with
 about 250 users simultaneously connected with Lightning. The error log
 shows that authentication has failed for about 4-5 users and it keeps on
 retrying continuously. The calendar server process initially starts
 normally but suddenly its cpu usage goes to above 90%.
 >
 > The server is a Intel Core 2 1.86 Ghz CPU with more than 3 GB RAM.
 >
 > I am trying to figure out the possible reason for the high CPU usage.
 >
 > 1. The server configuration is not sufficient for 250 simultaneous
 users.
 > 2. The ldap patch is coded in a way which is leading to the high CPU
 usage.
 > 3. The repeated authentication attempts is leading to the high CPU
 usage.
 >
 > Any help in this regard would be highly appreciated.

-- 
Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:35>
CalendarServer </>
HTTP/WebDAV/CalDAV Server


More information about the calendarserver-dev mailing list