On Thu, Jul 31, 2014 at 4:55 PM, Kiran Ayyagari <[email protected]> wrote:
> I am able to reproduce this on my dev machine, investigating further > > see https://issues.apache.org/jira/browse/DIRSERVER-1992 for updates > > this is now fixed, please see the bug report for the details. It will be great if anyone of you (David & Brad) can test the latest trunk in your environments. > > On Thu, Jul 31, 2014 at 12:54 PM, Emmanuel Lécharny <[email protected]> > wrote: > >> Crap... >> >> Sounds like we have an issue with the LRUMap we are using to store the >> Entry DN's down into the backend. >> >> Looking at the issue. >> >> >> Can someone create a JIRA for it ? >> >> Many thanks ! >> >> Le 31/07/2014 00:50, Brad a écrit : >> > I just ran into this today on version 2.0.0_M17. I am testing concurrent >> > queries and sync actions and this happens every time. My record count is >> > 150K+. >> > >> > "SEARCH_REQUEST >> > Message ID : 1 >> > SearchRequest >> > baseDn : 'ou=customers,o=acme.com' >> > filter : '(uid=*:[25043])' >> > scope : whole subtree >> > typesOnly : false >> > Size Limit : no limit >> > Time Limit : no limit >> > Deref Aliases : never Deref Aliases >> > attributes : >> > org.apache.directory.api.ldap.model.message.SearchRequestImpl@f95bfade: >> > Entry.next=null, data[removeIndex]=null previous=null >> key=5de68bc6-11ed-4010- >> > 9d48-71f5a54a94a1 [email protected],ou=customer,o=acme.com >> size=10000 >> > maxSize=10000 >> > >> > Please check that your keys are immutable, and that you have >> > used synchronization properly. If so, then please report this to >> commons- >> > [email protected] as a bug..." >> > >> > As described, the server then fails to respond to requests, until >> restart. In >> > this case I am using python's LDAP package and it returns "Other (e.g., >> > implementation specific) error'" as the error. >> > >> >> > > > -- > Kiran Ayyagari > http://keydap.com > -- Kiran Ayyagari http://keydap.com
