On 03/30/2011 06:30 AM, Andrey Ivanov wrote:
Hi Rich,
2011/3/25 Rich Megginsonrmeggins@redhat.com:
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@lists.fedoraproject.org