(ITS#5152) too much logging
by babu.suresh＠pacificlife.com
Full_Name: Babu
Version: 2.3.32
OS: RedHAT3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (198.181.11.27)
Hello,
We are having hell of problems in production with # logs getting
generated..almost 4Gig worth of transaction binary/BDB logs in a day(4000 10mb
files).
No debugging/logging turned in slapd.
Log rotate scripts is moving the logs to diff location to keep the prod up..but
few times we ran of space and I don't find any clue on minimize and log only for
updated transactions. It seems BDB is recording every read/write(not sure)..I
can't enable Auto_Achieve as need them for recovery.
Any known issue in the space? How to turn of unwanted logging of BDB?
==================Here are the detail of prod volume & DB_CONFIG file=====
openldap-2.3.32&BDB 4.5.20
our ldap/BDB is generating too many logs file.
Total records in ldap/BDB - 110k
Reads - 10k/day
Updates - 1k/day
=================DB_CONFIG=======
# one 0.25 GB cache
#set_cachesize 0 268435456 1
set_cachesize 0 5242880 1
# Data Directory
set_lk_max_locks 8000
set_lk_max_lockers 8000
set_lk_max_objects 8000
set_lg_max 8048576
===============SLAPD.conf========
Nothing special in and inxed we have are========
#index
index uid eq
index cn eq
index uniqueMember eq
index objectClass pres,eq
=============
thank you
# Transaction Log settings
set_lg_regionmax 262144
set_lg_bsize 2097152
15 years, 8 months
Re: (ITS#5142) and (ITS#5143) Why I think these bugs are important to have fixed.
by tan7f＠virginia.edu
--Apple-Mail-1--260703270
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
Hello OpenLdap Developers,
I haven't heard anything about the two bugs I've submitted in the
jldap libraries, so I'd like to explain why I feel that these two
issues are important to have fixed.
I'd like to create a new LdapConnection with a custom
LdapSocketFactory and I want a timeout value set on the socket so
that the connect method will timeout in case there is no route to the
host or some other networking issue. The documentation leads me to
believe that I can do the following.
LdapConnection.setSocketFactory(new LDAPJSSESecureSocketFactory());
int timeout = 5000; // 5 second timeout
lc = new LdapConnection(timeout);
lc.connect ("127.0.0.1", 636);
This won't work because the LdapConnection(int) constructor
disregards the LdapSocketFactory that is set with the
setSocketFactory method and instead uses the default non-SSL
encrypted socket. Ok, lets try a workaround.
lc = new LdapConnection(new LDAPJSSESecureSocketFactory());
int timeout = 5000; // 5 second timeout
lc.setTimeout(timeout); // <--- causes a nullPointerException
lc.connect("127.0.0.1", 636); // Program never even gets here.
Ok, this is even worse. I now get a nullPointerException in the
jldap library itself. Again, nothing in the documentation says to
avoid setting the timeout until after you call connect()
lc = new LdapConnection(new LDAPJSSESecureSocketFactory());
int timeout = 5000; // 5 second timeout
lc.connect("127.0.0.1", 636);
lc.setTimeout(timeout);
Well, that works, but I'm not setting the timeout until after the
connect which isn't what I need. What follows is the only way I can
think of getting it to work.
class TimeoutLdapSocketFactory extends LDAPJSSESecureSocketFactory {
m_timeout = 0;
TimeoutLdapSocketFactory() {
super ();
}
TimeoutLdapSocketFactory(int timeout) {
this();
m_timeout = timeout;
}
Socket createSocket (host, port) {
Socket socket = super.createSocket(host,port);
if (timeout > 0) socket.setSoTimeout(m_timeout);
return socket;
}
lc = new LdapConnection(new TimeoutLdapSocket(timeout));
lc.connect("127.0.0.1", 636);
That's a lot of code to do what is already there in the
LdapConnection class. If either of the two bugs I've submitted is
fixed, then the above use case would be easy to do with-out the
uglyness above. I believe #5142 to be a serious bug indeed since it
can lead to a nullPointerException in the library.
Thank you,
Tim Nowaczyk
--
Timothy Nowaczyk
Network Systems Engineer
University of Virginia - ITC
tan7f(a)virginia.edu
--Apple-Mail-1--260703270
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Disposition: attachment;
filename=smime.p7s
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPujCCBIIw
ggNqoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZ8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJn
aW5pYTEYMBYGA1UEBxMPQ2hhcmxvdHRlc3ZpbGxlMR8wHQYDVQQKExZVbml2ZXJzaXR5IG9mIFZp
cmdpbmlhMRswGQYDVQQDExJVVkEgVVNIRVIgUEtQIENBIDExJTAjBgkqhkiG9w0BCQEWFnBraW1h
c3RlckB2aXJnaW5pYS5lZHUwHhcNMDcwNzEyMjEyNzE0WhcNMjYwMjI1MDAwMDAwWjCBrzELMAkG
A1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRgwFgYDVQQHEw9DaGFybG90dGVzdmlsbGUxHzAd
BgNVBAoTFlVuaXZlcnNpdHkgb2YgVmlyZ2luaWExJTAjBgkqhkiG9w0BCQEWFnBraW1hc3RlckB2
aXJnaW5pYS5lZHUxKzApBgNVBAMTIlVWQSBTdGFuZGFyZCBBc3N1cmFuY2UgVVNIRVIgU0tQIDEw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDbO90WPYQnSOSvhwkIlhh3fLVaHi6X2v2+
kJ7njhzZg8zYoTwMa/sag84dgGu9CCmkzvYryD23mwdQ5oZX58ZyrYCETkcuV5Aycbi70ekTrQPP
1b4x4/sK3PDFSn2S2RB1sNlYy15DI6sIO5mVrV16ML+DGBSJbwGoJRjd+2L5MxkhPJraw5+k2us7
ABxvRpFgaA4TXwJiM8/idtsTNMv2XTR6zUJ9FPq8uOMLtiupbWe2K2tXDDeBSzBu7Z7RzNzxSsZz
72PjtEHhuNQ4I1hsKx/HT2gdxrCb6KxSyGo+QbYxwj5znRkIAFNEQPh6U6EPeDuzJbY/VuFfpsil
3tPZAgMBAAGjgbYwgbMwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFAGp
d8MuTIwww/Lbfd5nlCrBvuQZMB8GA1UdIwQYMBaAFDdB3axEwhAHmpxMkx2UHyiXRyUxMFMGA1Ud
IARMMEowSAYJKwYBBAG0dgEBMDswOQYIKwYBBQUHAgEWLWh0dHA6Ly93d3cucGtpLnZpcmdpbmlh
LmVkdS9zdGFuZGFyZC9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEAfEvJKxRHr9gy0MufEFva
x+QQs2dUN8oocl8jxWsQrQt5Hc6Azzfn2Zp3es10iYkCGNOqj+cRtwoljuWv2yVWm869+xgxskjn
uHPnaat84VzXN85i8ILbBZkVYPk1bO2SHjL97RrGvUqi2bJf8cSlzO7g+yTX9/yX0r0QKL4UNHdI
p3l3OeTZ0PBLKNhlr1wb6LRpl5+lRZQPWeCij/4e3wA7v9OmWXvevT9YprYTwEmCypPUbnjFeMnP
F+hwSgCC+Yov12kP3M+kDwXWpidFGk5p6nQ5c/cGGPd+x8Ek4VjjCw+7TfumwxEJSIX0NmjM+lDx
ykVtAMDS11nQ65/VEjCCBVwwggREoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMC
VVMxITAfBgNVBAoTGFVTIEhpZ2hlciBFZHVjYXRpb24gUm9vdDEMMAoGA1UECxMDQ0ExMRUwEwYD
VQQDEwxVU0hFUiBDQTEgdjEwHhcNMDcwNzExMjIyOTQ3WhcNMjYwMjI2MTgwMDAwWjCBnzELMAkG
A1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRgwFgYDVQQHEw9DaGFybG90dGVzdmlsbGUxHzAd
BgNVBAoTFlVuaXZlcnNpdHkgb2YgVmlyZ2luaWExGzAZBgNVBAMTElVWQSBVU0hFUiBQS1AgQ0Eg
MTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZpcmdpbmlhLmVkdTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBANnbscQ3ClhftaALCDqjnqvzU1MVfDmnSNFjSBcGyRRKxNEduA/O4/iD
CQ3lKJkRdjhIXN5e5UTe6LsmMY14uPBJOVINmFPiGfsi22LxslYiaGMStWIj3lNF+ZawyUX53WDD
IrjlYaBn3wi/m0tkWPLzsgeiRIovL0KVG4XRlkJ70upNCIv6GHP4W6rsa2hqC/gU1QdL+V2XJzE7
sT7l6CysRr01FiyRTOxdoSz+jJFmTTt892sWVry8B7nocD/ltffQ1pQJta4Ve/xWT+TvRPF3X7jn
ggOPIYbq0mYRAhWduV1BzlBA8bkTc8AHf8ukjRGydCAPc4OXMamhJ4uETCECAwEAAaOCAeowggHm
MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQ3Qd2sRMIQB5qcTJMd
lB8ol0clMTB9BgNVHSMEdjB0gBQmnSLq7LAPayEK9tkvIMplUOwb06FZpFcwVTELMAkGA1UEBhMC
VVMxITAfBgNVBAoTGFVTIEhpZ2hlciBFZHVjYXRpb24gUm9vdDEMMAoGA1UECxMDQ0ExMRUwEwYD
VQQDEwxVU0hFUiBDQTEgdjGCAQQweAYIKwYBBQUHAQEEbDBqMDMGCCsGAQUFBzAChidodHRwOi8v
aDEudXNoZXJjYS5vcmcvYWlhL2NhMS1jZXJ0cy5wN2IwMwYIKwYBBQUHMAKGJ2h0dHA6Ly9oMi51
c2hlcmNhLm9yZy9haWEvY2ExLWNlcnRzLnA3YjBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vaDEu
dXNoZXJjYS5vcmcvY3JsL2NhMS5jcmwwJ6AloCOGIWh0dHA6Ly9oMi51c2hlcmNhLm9yZy9jcmwv
Y2ExLmNybDBOBgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cudXNo
ZXJjYS5vcmcvcHJhY3RpY2VzL2NhMS9jcHMucGRmMA0GCSqGSIb3DQEBBQUAA4IBAQCHbtcZxR5o
9B0MgMds0g3g9DBLZSJEi6kRY6heNocsmSsRxEsqE37R6gVtRg3xfTcjJG9E4J4fClB8EK5EDPRo
UAJZExJE47aHNXT7KtHgYKqU5dQUXlGi/ZyPpJOA5Nm8xQ+wiDw3kg8AAnM1WrPNnTUiTCYEUqBI
KY8AABaJ9CwVHsnu0wV04z4DtbiZgEhxBOczp8L+AveIsJhCTRc3VNlDmHPu9bh4VoyMnbzwlYKk
ItLkehDC5xE2ZPTMfC0VYtL+LEDlbGfR0YpzbTzxP3X3dxsmFbIyXAfNvj5gTqViDcgN9CTzblDv
oseZLtO0Te+e/YFeTRUBe/CcmUlmMIIF0DCCBLigAwIBAgIDAgQUMA0GCSqGSIb3DQEBBQUAMIGv
MQswCQYDVQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxs
ZTEfMB0GA1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFz
dGVyQHZpcmdpbmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBT
S1AgMTAeFw0wNzA4MDgxMzAzMDBaFw0wODA4MDgxMzAzMDBaMIGVMQswCQYDVQQGEwJVUzEfMB0G
A1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTEeMBwGA1UECxMVVVZBIFN0YW5kYXJkIFBLSSBV
c2VyMSEwHwYJKoZIhvcNAQkBFhJ0YW43ZkB2aXJnaW5pYS5lZHUxIjAgBgNVBAMTGVRpbW90aHkg
QWxsZW4gTm93YWN6eWsgMTMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKEo43l7/lWiNKOe
vtraIMIje77qJCSifhZ0CtrBT15E8HPQajBcFnqJ3U//6vvrEeN79de3Gvwygia0SwkgzjtFEsh8
/fLHKvYUDDlhyJxgbaVw3Ay1Ii9cHTyA8hopglAhyVweu08hwrnmSUDBsV+ugqV3AANQ0QwkXPDs
WbIbAgMBAAGjggKPMIICizALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF
BwMEMB0GA1UdDgQWBBSt9bmjP/g2cbvyzw+7IfnWfnDliDAJBgNVHRMEAjAAMB8GA1UdIwQYMBaA
FAGpd8MuTIwww/Lbfd5nlCrBvuQZMEEGA1UdEQQ6MDigIgYKKwYBBAGCNxQCA6AUDBJ0YW43ZkBW
aXJnaW5pYS5FRFWBEnRhbjdmQFZpcmdpbmlhLkVEVTCCAXgGA1UdHwSCAW8wggFrMH2ge6B5hnds
ZGFwOi8vd3d3LnBraS52aXJnaW5pYS5lZHUvYz1VUyxvPVVuaXZlcnNpdHklMjBvZiUyMFZpcmdp
bmlhLG91PVVWQSUyMFN0YW5kYXJkJTIwQXNzdXJhbmNlJTIwVVNIRVIlMjBTS1AlMjAxLGNuPTAy
MDQxNDB9oHugeYZ3bGRhcDovL3d3dy5wa2kudmlyZ2luaWEuZWR1L2NuPTAyMDQxNCxvdT1VVkEl
MjBTdGFuZGFyZCUyMEFzc3VyYW5jZSUyMFVTSEVSJTIwU0tQJTIwMSxvPVVuaXZlcnNpdHklMjBv
ZiUyMFZpcmdpbmlhLGM9VVMwa6BpoGeGZWh0dHA6Ly93d3cucGtpLnZpcmdpbmlhLmVkdS9jZ2kt
YmluL2dldC1jcmw/b3U9VVZBJTIwU3RhbmRhcmQlMjBBc3N1cmFuY2UlMjBVU0hFUiUyMFNLUCUy
MDEmY249MDIwNDE0MFMGA1UdIARMMEowSAYJKwYBBAG0dgEBMDswOQYIKwYBBQUHAgEWLWh0dHA6
Ly93d3cucGtpLnZpcmdpbmlhLmVkdS9zdGFuZGFyZC9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOC
AQEAY0SUBCrlT0E9VPUQy3lTVDYNQ+ewR3dPa+D4U+gqThk3mbOWSXWEOsYTw9BYOljv4UClAY5M
Uhp1Iyj7twzIG8lJnZhVP3G/ToU+8fkCCPUdAH+MJ6eshdZaeEEA/a2RzB0XvvmAfYK5x3e2yYLM
tOvfBHrRAl6m5O7wU2t6iykU6vGdL+MB9iqlylY2bxQ0x0NaW5KPL0XuPLgwxVvcds7eIDGOoy7+
WMDaY0miUqsq4PKjg98dnY5BaSUwGFyxhFocw8xtTVdls5VKh3jEvhYyq9ejTHFv49dEnXdmSZ1Y
Z3p98sEfQ12+CtFUbzlwphhJELXdC4nm71zFPcXg8zGCA1cwggNTAgEBMIG3MIGvMQswCQYDVQQG
EwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxsZTEfMB0GA1UE
ChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZpcmdp
bmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBTS1AgMQIDAgQU
MAkGBSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA3MDkyNDE1MjI1OFowIwYJKoZIhvcNAQkEMRYEFD9bKXbPWwwDKjUSyibAUFSKfHnjMIHIBgkr
BgEEAYI3EAQxgbowgbcwga8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJnaW5pYTEYMBYGA1UE
BxMPQ2hhcmxvdHRlc3ZpbGxlMR8wHQYDVQQKExZVbml2ZXJzaXR5IG9mIFZpcmdpbmlhMSUwIwYJ
KoZIhvcNAQkBFhZwa2ltYXN0ZXJAdmlyZ2luaWEuZWR1MSswKQYDVQQDEyJVVkEgU3RhbmRhcmQg
QXNzdXJhbmNlIFVTSEVSIFNLUCAxAgMCBBQwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYD
VQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxsZTEfMB0G
A1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZp
cmdpbmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBTS1AgMQID
AgQUMA0GCSqGSIb3DQEBAQUABIGAKppmxD98ZrUSeu76i+2qXl3WV18+NCFKNFF//HeUl4aTKtEq
x7K/BLdtJWyU8P+5SqoLRWG/86hBb2ERZNDozP5/6BC/0Gwuh9TUfVyRgxldQL9z8RNoMfv5T9g4
RlrQB9LGxVyAz3t7w3go8xkTBuRR2zLEn183lLBLY6CCpB8AAAAAAAA=
--Apple-Mail-1--260703270--
15 years, 8 months
(ITS#5151) certificateListValidate rejects valid lists
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: HEAD/re24
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (76.168.84.21)
Submitted by: hyc
I ran into a couple problems; the check for timestamps doesn't take into account
that Time is a CHOICE of UTCTime and GeneralizedTime. Also the check for the
revocation list doesn't verify that it's a SEQUENCE OF SEQUENCE, so it
mistakenly skips over closing signatureAlgorithm if the revocation list is
absent. Will be fixed in HEAD shortly.
15 years, 8 months
Re: (ITS#5070) Issues in X.509 certificate parsing
by hyc＠symas.com
ando(a)sys-net.it wrote:
> ando(a)sys-net.it wrote:
>
>> I've an issue with X.509 certificate parsing in HEAD/re24. The certificate,
>> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails
>> to parse it because it is an integer with length equal to 9, which is larger
>> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER
>> encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time
>> to get past the sizeof(ber_int_t) limitation...
>
> ... which would violate RFC 4511 where it states that INTEGER means from
> 0 up to 2^31-1... I have a simple solution for this problem, at the
> cost of partially violating rfc 4523: if an integer is larger than
> 2^31-1, it could be represented in the certificateExactMatch
> normalization in hexadecimal form, much like OpenSSL does. This would
> increase interoperability with OpenSSL and be at least self-consistent,
> since all serialNumbers that large would be consistently expanded that
> way. Another solution, preserving the decimal representation, would
> probably require some arbitrary precision support from external
> libraries. If there's consensus, I'd post my simple patch.
I just got tripped trying to import an LDIF with a cert with 16 byte
SerialNumber. I've patched this to just use the same hexadecimal format that
OpenSSL uses when the number is larger than ber_int_t. We really don't want
the format to change just because someone has a BigNum library available; it
needs to stay consistent.
Normalizing to a string format like this still seems pretty gross, but I guess
that's the best we can do given dumb clients that aren't aware of schema.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 8 months
Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it
Ralf Haferkamp wrote:
> Please note that test020 currently fails in HEAD sometime. I think this
> depends on the order in which the results for queries that hit the
> sizelimit are returned.
I added tests for sizelimit that were consistent with my changes;
however, I'm now short of time to work on this, so feel free to back out
those test changes if you believe the code is working correctly, while
we design test improvements that are consistent with all fixes.
Thanks, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
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
---------------------------------------
15 years, 8 months
Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com
hyc(a)symas.com wrote:
> Ralf Haferkamp wrote:
>> On Freitag, 21. September 2007, hyc(a)symas.com wrote:
>>> It seems to be failing for me more often than not. Why is it
>>> non-deterministic?
>> It seems that the order in which the entries are inserted into the cache is
>> non-deterministic. Because of that the order in which they are returned from
>> cache varies as well. The final test that compares the ldapsearch results
>> with proxycache.out relies on the order.
>>
>> I get a lot of DB_LOCK_DEADLOCK in slapd.2.log and if I don't missread the log
>> it seems that sometimes the entries from Query 9 get inserted into the cache
>> before the entry from Query 5 ("cn=Bjorn Jensen,ou=Information Technology
>> Division, ...") and sometimes after. Depending on that the test either fails
>> or succeeds.
>>
> OK, I see that as well. In fact setting a breakpoint on the Deadlock result, I
> see 3 threads still trying to add entries to the cache when the deadlock
> occurs. This appears to be a consequence of letting the client continue on
> before the pcache overlay has finished its work. But, I thought you were
> locking the cache so that requests would not run while query processing was
> incomplete?
I see, you're only locking individual queries. That's certainly inadequate,
you'll probably have to lock the entire cache as a whole. Remember that an
entry that you're adding may actually satisfy multiple queries.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 8 months
Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com
Ralf Haferkamp wrote:
> On Freitag, 21. September 2007, hyc(a)symas.com wrote:
>> rhafer(a)suse.de wrote:
>>> Please note that test020 currently fails in HEAD sometime. I think this
>>> depends on the order in which the results for queries that hit the
>>> sizelimit are returned.
>> It seems to be failing for me more often than not. Why is it
>> non-deterministic?
> It seems that the order in which the entries are inserted into the cache is
> non-deterministic. Because of that the order in which they are returned from
> cache varies as well. The final test that compares the ldapsearch results
> with proxycache.out relies on the order.
>
> I get a lot of DB_LOCK_DEADLOCK in slapd.2.log and if I don't missread the log
> it seems that sometimes the entries from Query 9 get inserted into the cache
> before the entry from Query 5 ("cn=Bjorn Jensen,ou=Information Technology
> Division, ...") and sometimes after. Depending on that the test either fails
> or succeeds.
>
OK, I see that as well. In fact setting a breakpoint on the Deadlock result, I
see 3 threads still trying to add entries to the cache when the deadlock
occurs. This appears to be a consequence of letting the client continue on
before the pcache overlay has finished its work. But, I thought you were
locking the cache so that requests would not run while query processing was
incomplete?
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 8 months
Re: (ITS#5150) Patch to add a new config option to force the return of operational attributes in rootDSE
by hyc＠symas.com
mspeder(a)syrtis.net wrote:
> Full_Name: Matthieu Speder
> Version: Latest HEAD
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/Matthieu-Speder-070922.patch
> Submission from: (NULL) (82.224.96.182)
>
>
> This patch adds a new global option in configuration
> (forceopattrs/olcForceOpAttrs { on | off }).
Thanks for the patch. Still, the behavior you're introducing is a violation of
the protocol spec. The fact that other vendors don't care to implement
conformant servers doesn't really have any bearing on this; clients that
expect this behavior are broken and should be fixed.
> When answering a search query to rootDSE with an empty attribute query,
> forceopattrs forces slapd to return all operational attributes. By default
> forceopattrs is off and slapd only returns operational attributes when query
> contains a plus (+), see RFC 4533.
>
> Unfortunately the default behavior is different from other directories (both AD
> & Sun) and confuses some client applications which expect the operational
> attributes with a blank query. This new config option fixes the issue if
> required by client app.
>
> This patch does NOT change slapd default behavior.
>
> The patch contains both minor changes to result.c, proto-slap.h, bconfig.c and
> the required additions to docs (man & guide).
There's no reason to break the core code with misfeatures like this. If you
need this behavior, write an overlay that intercepts the relevant searches and
replaces the empty attribute list with "*" and "+".
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 8 months
(ITS#5150) Patch to add a new config option to force the return of operational attributes in rootDSE
by mspeder＠syrtis.net
Full_Name: Matthieu Speder
Version: Latest HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/Matthieu-Speder-070922.patch
Submission from: (NULL) (82.224.96.182)
This patch adds a new global option in configuration
(forceopattrs/olcForceOpAttrs { on | off }).
When answering a search query to rootDSE with an empty attribute query,
forceopattrs forces slapd to return all operational attributes. By default
forceopattrs is off and slapd only returns operational attributes when query
contains a plus (+), see RFC 4533.
Unfortunately the default behavior is different from other directories (both AD
& Sun) and confuses some client applications which expect the operational
attributes with a blank query. This new config option fixes the issue if
required by client app.
This patch does NOT change slapd default behavior.
The patch contains both minor changes to result.c, proto-slap.h, bconfig.c and
the required additions to docs (man & guide).
15 years, 8 months
