hyc@symas.com wrote:
Ralf Haferkamp wrote:
On Freitag, 21. September 2007, hyc@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.