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

RE: slurpd blocking updates

--On Thursday, May 13, 2004 11:27 PM -0700 Howard Chu <hyc@highlandsun.com> wrote:

Well, it would look like to me then that this problem was introduced
between 2.2.6 and 2.2.11, and 2.1.25 and 2.1.29, since I have
not had any
problems on those earlier version, and I know changes were
made to slurpd
since then.  Perhaps the out-of-order fix to slurpd impacted
it, I know
that was a major bug fix...

The diff's to slurpd from 2.1.25 to 2.1.29 are largely cosmetic, mostly in comments and error message reporting. The out-of-order fix was a change to how slapd generates the replog, not a code change in slurpd. Since the slurpd code has not changed, and only the replog itself is different, one would expect all of your replicas to behave identically since they're all using the same replog.

Okay -- As I noted, I'm looking at 2.2.6 and 2.2.11 myself.

Probably you need a debug/non-optimized build of slurpd to track this down and get some good stack traces. If the stack traces aren't telling anything useful, that tends to imply that the stack itself is trashed. (The trace you provide in ITS#3123 is conspicuous in that it only goes back as far as libthread, and doesn't tell anything about the calling program.)

Yeah, I've built a debugging version of slurpd with all its lovely symbols, and that is what is running on our test master. The stack traces haven't shown anything useful.

What I know is I see this constantly on my test servers (2.2.11), which have very few updates and are particularly low volume. My production master, on the other hand, running 2.2.6, has had 10,000 updates pushed above its normal 1k or so updates a day pushed at it in the last 3 days, and has not had a single issue.


Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
ITSS/TSS/Infrastructure Operations
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html