directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Release troubles and failing tests
Date Thu, 10 May 2012 12:51:52 GMT
Le 5/10/12 9:58 AM, Emmanuel Lécharny a écrit :
> Le 5/10/12 7:57 AM, Selcuk AYA a écrit :
>> The problem seems to be caused by the test
>> testPagedSearchWrongCookie(). This tests failure in pages search by
>> sending a bad cookie. After failing, it relies on ctx.close() to
>> cleanup the session. Cleanup of the session will close all the cursors
>> related to paged searches through the session.
>> It seems that somehow ctx.close does not result in an unbind message
>> at the server side time to time. I do not know what causes this but
>> this leaves a cursor open(specifically a NoDups cursor on rdn index).
>> Eventually as changes happen to the Rdn index, we run out of freeable
>> cache headers. After ignoring this test, pagedsearchit and searchit
>> pass fine together. It would be good to understand why arrival of
>> unbind message is a hit and miss case in this test.
> It's absolutly strange... Neither an UnbindRequest nor an 
> AbandonRequest is sent by JNDI when closing the context, which is a 
> huge bug.
> I have checked the other tests, and an Ubind request is always sent 
> when we close teh context, except when we get an UnwillingToPerform 
> exception.
> It seems like the context is in a state where it considers that no 
> unbind should be send after an exception. Although I can do a lookup 
> (and get back the correct response from the server after this 
> excption), the connection is still borked :/
> I'll try to rewite the test using our API to see if it works better, 
> and investigate with som Sun guys to see if there is an issue in JNDI.
Ok, we have had a long discussion with Alex about this problem...

The thing is that even for standard PagedSearch, where everything goes 
fine (ie, when the client is done, he has correctly closed the 
connextion, which sends a UbindRequest, which close the cursor etc), we 
may have dozens of opened cursors for some extend period of time.

At some point, we may have a exhausted cache, with no way to evict any 
elements from it, leading to a server freeze.

Not something we can accept from a LDAP server...

A suggestion would be to add some parameter in the OperationContext 
telling the underlying layer that a search is done outside of any 
transaction. When we fetch an ID from an index, and we try to get the 
associated Entry from the master table, if we get an error  because the 
ID does not exist anymore, then we should just ignore the error, and 
continue the search.

But we still want to be sure that in some case, inside the server, we 
still can have transactions over some searches.

Thoughts ?

Emmanuel Lécharny

View raw message