On 03/30/2011 06:30 AM, Andrey Ivanov wrote: > Hi Rich, > > 2011/3/25 Rich Megginson<rmeggins@xxxxxxxxxx>: >> The 389 Project team is pleased to announce the release of >> 389-ds-base-1.2.8 Release Candidate 2. This release has fixes for bugs >> found in 1.2.8 testing and bugs from earlier releases. > i've made a rapid test compiling from today's sources (1.2.8.rc3 or > rc4 i think). I haven't seen any immediately obvious bugs. It is also > much more stable than 1.2.7.5. > > > However i've noticed that the order of operations in logs is not > always correct : > > [30/Mar/2011:14:17:03 +0200] conn=13 fd=128 slot=128 connection from > 127.0.0.1 to 127.0.0.1 > [30/Mar/2011:14:17:03 +0200] conn=13 op=0 BIND dn="" method=128 version=3 > [30/Mar/2011:14:17:03 +0200] conn=13 op=1 SRCH > base="dc=id,dc=polytechnique,dc=edu" scope=2 > filter="(&(|(objectClass=X-Misc)(objectClass=X-Object))(!(X-UniqueId=*)))" > attrs="nsUniqueId" > [30/Mar/2011:14:17:03 +0200] conn=13 op=1 RESULT err=0 tag=101 > nentries=0 etime=0.117000 notes=U > [30/Mar/2011:14:17:03 +0200] conn=13 op=2 UNBIND > [30/Mar/2011:14:17:03 +0200] conn=13 op=2 fd=128 closed - U1 > [30/Mar/2011:14:17:03 +0200] conn=13 op=0 RESULT err=0 tag=97 > nentries=0 etime=0.021000 dn="" > (the result of op=0 is after op=2) > > or > [30/Mar/2011:14:20:19 +0200] conn=19 fd=128 slot=128 connection from > local to /Local/dirsrv/var/run/slapd-dmz.socket > [30/Mar/2011:14:20:19 +0200] conn=19 AUTOBIND dn="cn=X LDAP Root" > [30/Mar/2011:14:20:19 +0200] conn=19 op=0 BIND dn="cn=X LDAP Root" > method=sasl version=3 mech=EXTERNAL > [30/Mar/2011:14:20:19 +0200] conn=19 op=1 SRCH > base="dc=id,dc=polytechnique,dc=edu" scope=2 > filter="(&(|(objectClass=X-Misc)(objectClass=X-Object))(!(X-UniqueId=*)))" > attrs="nsUniqueId" > [30/Mar/2011:14:20:19 +0200] conn=19 op=2 UNBIND > [30/Mar/2011:14:20:19 +0200] conn=19 op=2 fd=128 closed - U1 > [30/Mar/2011:14:20:19 +0200] conn=19 op=0 RESULT err=0 tag=97 > nentries=0 etime=0.012000 dn="cn=X LDAP Root" > [30/Mar/2011:14:20:19 +0200] conn=19 op=1 RESULT err=0 tag=101 > nentries=0 etime=0.108000 notes=U > (the result of op=0 and op=1 is after op=2) > > > It is not something new, i've tested on 1.2.6.1 (our production > environment) and this behavior it is also present. I observe it much > more often when the log buffering is off. Don't know if it's a bug or > it's because of several threads writing in parallel and it's an > expected phenomenon... It might be a bug in that it would be nice if they were always in order. It is just the logging that is out of order - the operations do go through in the correct order. > > @+ -- 389 announce mailing list 389-announce@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-announce
