directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [jira] Closed: (DIRSERVER-950) Server Left in Unstable State
Date Sun, 03 Jun 2007 10:41:22 GMT
Ole Ersoy a écrit :

> Thanks for all the comments.  I read them carefully a few times I did 
> and I agree with everything you said.  I'll take notes in a separate 
> memo pad, and then come up with a quick concise summary for JIRA.

Thanks Ole. Doing so will help a lot !

> =======================================================================
> 3) You pointed us to a test which is somewhere on the web. Don't do 
> that, it's not convenient, because your test will be very contextual. 
> Just attach the whole working test. 
> =======================================================================
> Sure - I like quick self contained tests.  In this case "The Whole 
> Working Test" is a fairly massive test setup, along with the test.  
> Therefore there is an option I would like us to consider because I 
> would have to invest a significant amount of time in translating the 
> "Massive test setup" into a single self contained test, in addition to 
> the 2-3 hours I spent documenting and isolating this thing. 
> We could do this:
> svn co 

> das.ldap.parent

Ok, I tried, and it failed. This is one of the reason it's better to 
attach a standalone test. Anyway, here are some comments about the test :
- you have injected .classpath and .project into SVN, and this is not a 
good idea, as it may not be used directly on another version of eclipse. 
I'ts better to use mvn eclipse:eclipse which will generate those files. 
Moreover, those .classpath points to resources that are not loaded on my 
computer (old versions of apacheds and shared), mvn would have 
downloaded them.
- you are refering to incompatible versions of apacheds (namely, 1.0.). 
This is not good
- you are also refering to a lot of eclipse plugin I don't have on my 
eclipse installation (emf and xsd, using old versions of them).

This is why the URL you gave is not a good idea... There is no way I can 
run the test without a massive cleanup ...

> Import the child projects into eclipse.  Run the test described.  View 
> the context ou=objectClasses, cn=ecore, ou=schema in LS.  Verify my 
> observation, being mainly that this context is now "Broken".
> This should take about 2 minutes.  If for some reason my observation 
> is missing come back to me and ask me to code a self contained test.  

I think that what I explained in my previous point forbid me to run the 
test without some more work, and it won't be 2 minutes for me to fix it 
... I'm sorry about that !

> I'll be happy to do it.  Is this a fair request?  

I's plain fair.

> Ideally I think myself and the person fixing this would work together, 
> and come up with an integrated test suite targeted at keeping these 
> types of fixes fixed.  If I code another test it could be that the 
> person I throw it over the wall to ends up recoding it anyways.  I'll 
> be glad to help in any way I can, I just want us to be smart in terms 
> of how we work together.

The main problem is that when it comes to complex problems, you have to 
factor of complexity :
- the potential bug in the server. If the bug does not occurs in very 
specific circonstances, then writing a focused test is complex.
- the complexity of your code : it's always painfull to select the part 
of it which demonstrates the error

Now, I would say that this is fair to ask the user to make the effort 
first. The reason is that 99% of the cases, the error is hidden somwhere 
in the user code. How many times did you heard about "damn <select you 
favorite product/API>, it's fully buggy", and after a little 
investigation, you discover that the error is in the client code ? We 
see it all the times (just check MINA bug reports, it's always the same 
thing :
"Q: there is a bug in MINA, blah blah blah..."
"A: Are you sure? Can you check that and that?"
"Q: Oh, well, that fixed the bug, I mean, it's working now ..."

We have bugs in the server, that's obvious. But if we have to spend some 
time to check for every supposed bug, before discarding them, we won't 
be able to fix any real bugs ... This is very true for complex tests.

This is the reason we ask users to do their homeworks before bringing 
the problem to us, not because we are lazzy, but because of the lack of 

> =======================================================================
> Last thing : you don't have to reinstall the server : just delete the 
> data (a directory called, or whatever name you gave to 
> your partition, plus the schema directory in server-work). It will do 
> the trick.
> =======================================================================
> Oh OK - I looked under apacheds-1.5.0/var...and did not see a 
> server-work... Also all the entries created by the test are under 
> ou=schema.  Does this still apply?  I'm guessing if I delete the 
> entire schema partition, the server will just recreate it when it 
> restarts?

Sorry, it's in You have three sub-dirs, example, system and 
schema. Simply remove the directoy, the system and schema 
directories will be recreated when the server will be restarted.


View raw message