[389-users] Skipped request ...

[Reinhard Nappert]

Hi all,

I have seen a weird behavior of my DS (1.1.2). It has a very small database (only about 2300 objects). A client performed a one-level search retrieving the children. The server find 114 objects, but the search was very slow:

[06/May/2010:12:23:11 +0000] conn=127 op=149 SRCH base=<base> scope=1 filter="(&(&(objectClass=<xyz>)(<att1>=value))(!(<att2>=TRUE)))"

yes, the filter is a bit complex, but both attribute types <att1> and <att2> are indexed. This search usually is fast. It looks to me that the server is already in a funny state.
...
[06/May/2010:12:23:17 +0000] conn=127 op=149 RESULT err=3 tag=101 nentries=114 etime=7

When the client gets the results, it iterates over those and gets its children, like:

[06/May/2010:12:23:17 +0000] conn=127 op=150 SRCH base=<dn of result from previous SRCH> scope=1 filter="(&(&(objectClass=<uvw>)(<attr3>=*))(!(<attr2>=TRUE)))" attrs=ALL.
Those searches are quick:
[06/May/2010:12:23:17 +0000] conn=127 op=150 RESULT err=0 tag=101 nentries=1 etime=0

but somehow the server does not process on of the requests, when the client iterates over the results:

[06/May/2010:12:23:18 +0000] conn=127 op=263 SRCH base=<dn of result from previous SRCH> scope=1 filter="(&(&(objectClass=<uvw>)(<attr3>=*))(!(<attr2>=TRUE)))" attrs=ALL.
[06/May/2010:12:23:18 +0000] conn=127 op=263 RESULT err=0 tag=101 nentries=1 etime=0
[06/May/2010:12:23:26 +0000] conn=127 op=265 SRCH base=<dn of result from previous SRCH> scope=1 filter="(&(&(objectClass=<uvw>)(<attr3>=*))(!(<attr2>=TRUE)))" attrs=ALL.
[06/May/2010:12:23:26 +0000] conn=127 op=265 RESULT err=0 tag=101 nentries=0 etime=0
You can see that the server skipped op=264. It looks to me that the request came in, but somehow the server joked up, before it could log the request in access.

Has anybody seen such a behavior before?

Thanks,
-Reinhard


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20100511/26cb1dcb/attachment.html>