openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

RE: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by evaristo-jose.camarero＠ericsson.com 10 Aug '09

10 Aug '09

=20 It looks that I sent an email that was unreadable. Sorry for that. I recap the content: The traffic model we are testing contains search and modify operations. = The search response contains usually a single entry about 3KB in LDIF = format. There is only a reduce number of LDAP clients (usually one or = two), that are using async LDAP API and sending a lot of operations per = second (> 1000 TPS per client). The client side is an OS Delta box. Under these conditions we have tested that increasing the sending buffer = of the server has improved the performance. That's the reason I am = proposing this feature request. Pierangelo's proposal allowing hard-set the buffer sizes looks ok. Regards, Evaristo ----- Mensaje reenviado ---- De: Pierangelo Masarati <masarati(a)aero.polimi.it> Para: evaristojosec(a)yahoo.es CC: openldap-its(a)openldap.org Enviado: martes, 4 de agosto, 2009 9:54:19 Asunto: Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST Your message was unreadable, you should use text form for messages sent = to the ITS. In any case, according to many sources, the default values for TCP = buffers can be pretty small. Usually, they can be configured = system-wide at the OS level (see tcp(7)), or even auto-tuned. Personally, I have no objections in optionally allowing to hard-set the = buffer sizes to values one considers appropriate for the intended use of = slapd. Since the optimal size roughly depends on latency and bandwidth, = this may probably need to be configured on a per-listener basis, = actually. However, in deployments where this problem becomes critical, usually = hardware dedicated to slapd is used, so system-wide tuning (and = auto-tuning) would be the preferred option anyway. Manual setting = should be used only when system-wide or auto-tuning is not available or = accessible for some reason. p. =20

1 0

Re: (ITS#6245) back-config allows empty add operation
by quanah＠zimbra.com 08 Aug '09

08 Aug '09

--On Saturday, August 08, 2009 10:07 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.17 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) I guess they may be liberally legal.. It also updates the contextCSN and the accesslog database. dn: reqStart=20090808223406.000005Z,cn=accesslog objectClass: auditModify reqStart: 20090808223406.000005Z reqEnd: 20090808223409.000000Z reqType: modify reqSession: 214 reqAuthzID: cn=config reqDN: cn=zimbra reqResult: 0 reqMod: entryCSN:= 20090808223406.630393Z#000000#000#000000 reqMod: modifiersName:= cn=config reqMod: modifyTimestamp:= 20090808223406Z Seems janky to me. :P --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6245) back-config allows empty add operation
by quanah＠zimbra.com 08 Aug '09

08 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) [zimbra@freelancer ~]$ ldapmodify -x -H ldapi:/// -D cn=config -W Enter LDAP Password: dn: olcDatabase={2}hdb,cn=config changetype:modify add: modifying entry "olcDatabase={2}hdb,cn=config" dn: olcDatabase={2}hdb,cn=config changetype:modify add: modifying entry "olcDatabase={2}hdb,cn=config" Log shows it happening, too: Aug 8 15:08:50 freelancer slapd[1937]: conn=16 fd=23 ACCEPT from PATH=/opt/zimbra/openldap-2.4.17.8z/var/run/ldapi (PATH=/opt/zimbra/openldap-2.4.17.8z/var/run/ldapi) Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 BIND dn="cn=config" method=128 Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 RESULT tag=97 err=0 text= Aug 8 15:08:52 freelancer slapd[1937]: conn=16 op=1 MOD dn="olcDatabase={2}hdb,cn=config" Aug 8 15:08:52 freelancer slapd[1937]: conn=16 op=1 RESULT tag=103 err=0 text= Aug 8 15:08:56 freelancer slapd[1937]: conn=16 op=2 MOD dn="olcDatabase={2}hdb,cn=config" Aug 8 15:08:56 freelancer slapd[1937]: conn=16 op=2 RESULT tag=103 err=0 text= Aug 8 15:09:33 freelancer slapd[1937]: conn=16 fd=23 closed (connection lost)

1 0

Re: (ITS#6215) liblber problems
by Kurt＠OpenLDAP.org 07 Aug '09

07 Aug '09

On Aug 7, 2009, at 11:16 AM, h.b.furuseth(a)usit.uio.no wrote: >> - decode.c is quite lax about what it accepts. Should we tighten >> that when feasible, or remain "liberal in what we accept"? Decoding needs to be liberal here. Otherwise interoperability will suffer as it is well established that there exists many implementations which are not strict in what they send. -- Kurt

1 0

Re: (ITS#6215) liblber problems
by h.b.furuseth＠usit.uio.no 07 Aug '09

07 Aug '09

Fixed the above, including malformed bitstrings and set/sequences. Except: Need decision on decode(bad INTEGER/BOOLEAN) and encode(bad tag): > - decode.c is quite lax about what it accepts. Should we tighten > that when feasible, or remain "liberal in what we accept"? > > E.g. it accepts BER INTEGER length 0 and BOOLEAN length != 1, and > wrong CONSTRUCTED/PRIMITIVE encoding bit. > > - encode.c willingly stores broken identifier octets if passed an > invalid tag, e.g. a single octet with low bits 0x1F implying long tag > format. I'm inclined to leave that alone, caller's responsibility. API matters: I'll export the new function ber_peek_element(). And if nobody disagrees, the matching function ber_skip_element() even though that is nearly a duplicate of ber_get_stringbv(,, LBER_BV_NOTERM). -- Hallvard

1 0

Re: (ITS#6227) autogroup overlay breaks all searches
by ryans＠aweber.com 07 Aug '09

07 Aug '09

I can confirm that the segfault on slapadd, slapcat, and friends were in fact a result of this bug. I don't have the strace handy which confirmed it, but after applying Howard's patch and repackaging the .deb (Ubuntu Jaunty), I see none of the aforementioned segfaults. Regards, Ryan -- Ryan Steele ryans-at-aweber-dot-com Systems Administrator +1 215-825-2196 x758 AWeber Communications http://www.aweber.com

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 06 Aug '09

06 Aug '09

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 06 Aug '09

06 Aug '09

masarati(a)aero.polimi.it wrote: >> http://purgatory.spnet.net/~karavelov/faillog >> > > There is no corruption. What happens is that back-bdb, when returning the > entry from the cache, correctly locates it based on the indexed attrs used > in the filter, but at some point decides that the entry is outside the > scope of your search: > > Aug 5 16:44:22 work slapd[17541]: bdb_search: 87 scope not okay > > This should not happen, since your search is performed with exactly the > same parameters used for the original one, and the scope is 1 (onelevel). > > I wonder what happens there. Could you walk through the failing request > with a debugger, and print some values? I'd like to see, from within > bdb_search(), line 780 of back-bdb/search.c of re23, the value of > > op->o_request->oq_search > > base > > *ei->ei_parent > > p. > > OK, I will try to attach a debugger when it happens. Next time I will also copy the BDB database and dump it in order to see the failing record. Luben

1 0

Re: (ITS#6242) PCache cache corruption
by masarati＠aero.polimi.it 06 Aug '09

06 Aug '09

> http://purgatory.spnet.net/~karavelov/faillog There is no corruption. What happens is that back-bdb, when returning the entry from the cache, correctly locates it based on the indexed attrs used in the filter, but at some point decides that the entry is outside the scope of your search: Aug 5 16:44:22 work slapd[17541]: bdb_search: 87 scope not okay This should not happen, since your search is performed with exactly the same parameters used for the original one, and the scope is 1 (onelevel). I wonder what happens there. Could you walk through the failing request with a debugger, and print some values? I'd like to see, from within bdb_search(), line 780 of back-bdb/search.c of re23, the value of op->o_request->oq_search base *ei->ei_parent p.

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by quanah＠zimbra.com 06 Aug '09

06 Aug '09

--On August 6, 2009 7:25:16 PM +0200 masarati(a)aero.polimi.it wrote: >> I'm also curious why back-monitor develops stats for the other caches but >> specifically not for entry cache. > > I haven't looked in detail, but it makes sense that some operation occurs > within the glue database which requires caching something, but not > entries. > > - The entry cache monitor shows the value of bdb->bi_cache.c_cursize; > > - the DN cache monitor shows the value of bdb->bi_cache.c_eiused, which > should be the number of entryinfo structures used; > > - the IDL cache monitor shows the value of bdb->bi_idl_cache_size. > > In my very simple tests, I only saw something populating the DN cache, > which means some internal operation required to allocate some entryinfo > structures that remain 'round. > > In any case, it's only showing information related to its database > structure, it is by no means collecting info from the glued databases. Ok, this makes sense, as the numbers it was reporting definitely seemed smaller than I was expecting. I bet they are for pieces in the rootDSE. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs