[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: 2.4.16: sizelimit broken due to ors_slimit is set to SLAPD_DEFAULT_SIZELIMIT

--On Sunday, June 14, 2009 12:41 AM +0200 Christian Fischer <Christian.Fischer@fischundfischer.com> wrote:

Hi all,

I've upgraded from 2.3.43 to 2.4.16 on gentoo amd64.

Syncrepl could not finnish its initial replication due to a sizelimit of
500  entries.

This is a bit amazing because I've set sizelimit to unlimited, and I had
no  such trouble with 2.3.43.

I've played a bit with the sizelimit statement.
If sizelimit is set to a value >=0<500 the behavior is as expected,
unlimited  (-1) and values >500 are ignored.

I've turned on args debugging to see if something is different between
both  versions.

With version 2.3.43 op->ors_slimit is set to 0 if do_search() is
executed,  with version 2.4.16 op->ors_slimit is set to 500

That explains the different behavior of limits_check().

With ors_slimit set to SLAPD_DEFAULT_SIZELIMIT it runs into
servers/slapd/limits.c:1294 and ors_slimit will only set to
ors_limit->lms_s_soft if the value of ors_limit->lms_s_soft is between 1

I don't know why you have set ors_slimit to SLAPD_DEFAULT_SIZELIMIT but
this  breaks unlimited sizelimit or size limits > SLAPD_DEFAULT_SIZELIMIT.
I think that lms_s_soft should initially be set to

But as said, I don't know why you have done this and probably you had
good  reasons to do so. I'm a bit confused that nobody but me had such
limit  problems with 2.4.16 till now.

Attached my config snippet.

You don't show what sizelimit is in place on the *provider* which is what would determine how syncrepl is affected.



Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
Zimbra ::  the leader in open source messaging and collaboration