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 ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
