Re: (ITS#4160) idletimeout configuration directive being processed late

[hyc@symas.com]

Quanah Gibson-Mount wrote:
> --On Tuesday, November 08, 2005 1:25 AM -0800 Howard Chu 
> <hyc@symas.com> wrote:
>> I think this is more to do with server load than anything else. Note 
>> that
>> in the absence of other activity the server only checks once every
>> (idletime/4) seconds for idle connections. So given a 30 second
>> idletimeout a lag of up to 7.5 seconds would be normal. The 41 second
>> interval there (11 second lag) does seem a bit abnormal, but the 37 and
>> 35 second intervals are fine.
>
> I dunno... Even on an extremely idle system at 4 in the morning I see:
>
> Nov  8 04:21:44 ldap9.Stanford.EDU slapd[18139]: [ID 588225 
> local4.debug] conn=2297 op=0 RESULT tag=97 err=0 text=
> Nov  8 04:22:22 ldap9.Stanford.EDU slapd[18139]: [ID 485650 
> local4.debug] conn=2297 fd=80 closed (idletimeout)
>
> Although I suppose that is close to:
>
> 44+30 = :14 +7.5 (probably rounded to 8) = :22.
>
>
> Is it perhaps doing (idletime + (idletime/4)) seconds?

Not intentionally. As I said, it will only check once every idletime/4 
seconds. The total lag depends on when the check occurs relative to when 
the last activity on a connection occurred. E.g., in the worst case the 
first check occurs ~7.4 seconds after the last activity on a connection 
(time t). So four polls will occur with no action being taken: t+7.4, 
t+14.9, t+22.4, and t+29.9. The first poll that exceeds the 30 second 
limit will be at t+37.4, giving you the worst case ~7.5 second lag.

You can redefine the SLAPD_IDLE_CHECK_LIMIT in daemon.c if you want it 
to check more frequently, but I think that would be a waste of CPU.

Showing a lag of 11 seconds implies that the listener thread got too 
busy handling connections; after waking up from select() it had too much 
to do to be able to get back to the top of the loop. That definitely 
seems unusual, but not impossible and not an indication of an actual 
software error. I would expect the Lightweight Dispatcher code to 
eliminate these occurrences, you could enable that in the RE23 build and 
see if you still notice these large delays.

At any rate, I don't think there's a bug here and this ITS should be closed.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/