Full_Name: Quanah Gibson-Mount
Version: All
OS: NA
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (171.66.155.86)
It would be nice if you could pass -u and -g options to run as another
user/group so that on systems where OpenLDAP is running as another user or
group, the files created by slapadd & slapindex have the correct ownerships
(rather than root, for example).
damonmo(a)gmail.com wrote:
> The option 'network-timeout' used to stablish a socket-level timeout on meta
> backend is missing on slapd-meta man pages.
>
Fixed in HEAD/re23. Thanks, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
Full_Name: Daniel Montero Motilla
Version: 2.3.27
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.38.203.12)
The option 'network-timeout' used to stablish a socket-level timeout on meta
backend is missing on slapd-meta man pages.
--On Monday, October 23, 2006 7:13 PM +0000 richton(a)nbcs.rutgers.edu wrote:
> I just got bit with this c_writewaiter assert. This is 2.3.27 with patch
> for #4708 and #4695. See
> https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt for
> *c (full backtrace included for good measure).
I'll note an important difference between your hitting this issue and my
hitting this issue.
In my case:
(a) I was using connection.c code from HEAD
(b) c_writewaiter was zero, …
[View More]and not one.
The issue in my case I believe was due to two things:
(1) An optimization bug in gcc, because once I rebuilt with gcc 4.1.1, I
never got this issue, and
(2) A race condition that existed in the HEAD code, that was recently fixed.
I no longer experience this problem with the updated HEAD code and gcc
4.1.1 as the compiler.
I'd actually say that your report on this issue is a new ITS. ;)
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
[View Less]
At 12:13 PM 10/23/2006, richton(a)nbcs.rutgers.edu wrote:
>I just got bit with this c_writewaiter assert. This is 2.3.27 with patch
>for #4708 and #4695. See
>https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt for
>*c (full backtrace included for good measure).
Try 2.3.28.
--Apple-Mail-2-751178356
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
> Are you patched for ITS#4708 and ITS#4695? Those are my current
> "don't try to syncrepl without it" for RE23...
No, I was using 2.3.27 "pure"
I'll give a try, THX
>
> Is this refreshAndPersist, or refreshOnly? delta-syncrepl? Do you
> use a session log? Maybe just post the relevant config entirely...
Right, and sorry
It is a syncrepl with …
[View More]RefresAndPersist, with "retry 600 +"
The enviroment is the same of ITS#4702 with 1m entry DB
Paolo
--Apple-Mail-2-751178356
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV><BLOCKQUOTE =
type=3D"cite"></BLOCKQUOTE><BR><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Are you patched for ITS#4708 and ITS#4695? Those are =
my current "don't try to syncrepl without it" for =
RE23...</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>No, I was using 2.3.27 =
"pure"=A0</DIV><DIV>I'll give a try, THX</DIV><BR><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Is this refreshAndPersist, or refreshOnly? =
delta-syncrepl? Do you use a session log? Maybe just post the relevant =
config entirely...</DIV> </BLOCKQUOTE></DIV><BR><DIV>Right, and =
sorry</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>It is a =
syncrepl with RefresAndPersist, with "retry 600 +"</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>The enviroment is the same =
of ITS#4702 with 1m entry DB</DIV><DIV><SPAN class=3D"Apple-style-span" =
style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 15px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Paolo=A0</DIV></SPAN></DIV><B=
R></BODY></HTML>=
--Apple-Mail-2-751178356--
[View Less]
At 10:14 AM 10/22/2006, ando(a)sys-net.it wrote:
>Full_Name: Pierangelo Masarati
>Version: HEAD
>OS: irrelevant
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (81.72.89.40)
>Submitted by: ando
>
>
>In proxies, we occasionally need to mark some response messages as "don't care".
> This is slightly different than "abandon", in the sense that, for performance
>and band occupation, an abandon would likely get too late to the remote server,
>but …
[View More]if the response is not removed from the list that would grow and waste
>resources.
>
>In realistic cases we profiled proxies that spend 50-60% of the CPU time running
>the list of messages to check if any of them has been abandoned.
>
>The proposed fix consists in:
>
>- keeping abandoned msgid's sorted, so that a bisection algorithm can be used to
>check if a msgid has been abandoned
>
>- add a ldap_int_abandon() call that marks a message as "abandoned" without
>actually sending an "abandon" operation. This call is, by now, private
>(ldap_int_) since its use in normal clients would make little sense. However,
>whenever it does make sense, there's no objection in making the call public
>(sort of ldap_abandon_mark()).
I rather not name this "abandon" as it doesn't send an
Abandon request. Maybe name this "discard" instead. E.g.,
ldap_int_discard().
>With this change, the overall CPU used to check response list in the very same
>test cases dropped to less than 1%.
>
>p.
[View Less]
Full_Name: Pierangelo Masarati
Version: HEAD
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando
In proxies, we occasionally need to mark some response messages as "don't care".
This is slightly different than "abandon", in the sense that, for performance
and band occupation, an abandon would likely get too late to the remote server,
but if the response is not removed from the list that would grow and waste
resources.
In realistic …
[View More]cases we profiled proxies that spend 50-60% of the CPU time running
the list of messages to check if any of them has been abandoned.
The proposed fix consists in:
- keeping abandoned msgid's sorted, so that a bisection algorithm can be used to
check if a msgid has been abandoned
- add a ldap_int_abandon() call that marks a message as "abandoned" without
actually sending an "abandon" operation. This call is, by now, private
(ldap_int_) since its use in normal clients would make little sense. However,
whenever it does make sense, there's no objection in making the call public
(sort of ldap_abandon_mark()).
With this change, the overall CPU used to check response list in the very same
test cases dropped to less than 1%.
p.
[View Less]
Are you patched for ITS#4708 and ITS#4695? Those are my current "don't try
to syncrepl without it" for RE23...
Is this refreshAndPersist, or refreshOnly? delta-syncrepl? Do you use a
session log? Maybe just post the relevant config entirely...