directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [jira] Commented: (DIRSERVER-970) Hot Partition Fails With ArrayIndexOutOfBoundsException
Date Fri, 15 Jun 2007 23:38:48 GMT
Doh!  OK - I should have checked that one more time.  I assumed that since I had a problem
with the 1.5.0 version before, and then when I checked out the trunk, rebuilt my repository,
and ran the test again, and it ran fine, that the thing was OK.  It turns out I had a 1.5.0
checkout in my workspace, and that's the one I built, thinking that it was the trunk.  Then
I looked again, and saw "Trunk with dependencies".  Double Doh!  So that fixed my initial
problem but left this one.  

I like the Swallow in a room analogy :-).  

OK - I owe a night on the house.

Cheers,
- Ole



Emmanuel Lecharny wrote:
> I did spent the two minutes to go through the steps you gave. Here is 
> what I get
> 1) I have lost 2 minutes, which is not really a pb.
> 2) Obviously, you are totally lost in your problem, trying to find a
> problem somewhere where there are not, simply because you are like a
> swallow in a room, bumping your head in all the walls trying
> desesperatly to find an exit
> 3) Simply take a break. When you can't find out the solution, but have
> a workaround, step back, breeze, have a smoke/drink/sleep/pot, and
> come back with a fresh brain
> 4) There is no problem. You simply are using an _old_ version of the
> jars, not the trunk. Your pom.xml is FU. I already told you that, but
> you were stuck in your idea that something should be wrong with the
> code. (bad attitude ...)
> Here is what I get when I run mvn eclipse:eclipse on your project :
> [INFO] Wrote Eclipse project for "archetype.instance.testing" to
> /home/elecharny/apacheds/archetype.instance.testing.
> [INFO]
>       Sources for some artifacts are not available.
>       Please run the same goal with the -DdownloadSources=true
> parameter in order to check remote repositories for sources.
>       List of artifacts without a source archive:
>         o xerces:xercesImpl:2.0.2
>         o junit:junit:3.8.1
>         o antlr:antlr:2.7.6
>         o org.apache.directory.server:apacheds-jdbm-store:1.5.0
>         o org.apache.directory.shared:shared-ldap-constants:0.9.6
>         o jdbm:jdbm:1.0
>         o org.slf4j:nlog4j:1.2.25
>         o org.apache.directory.server:apacheds-schema-extras:1.5.0
>         o commons-lang:commons-lang:2.1
>         o org.apache.directory.server:apacheds-schema-bootstrap:1.5.0
>         o org.apache.directory.server:apacheds-schema-registries:1.5.0
>         o commons-collections:commons-collections:3.0
>         o org.apache.directory.shared:shared-ldap:0.9.6
>         o org.apache.directory.server:apacheds-core-shared:1.5.0
>         o checkstyle:checkstyle:2.2
>         o org.apache.directory.server:apacheds-btree-base:1.5.0
>         o org.apache.directory.server:apacheds-bootstrap-partition:1.5.0
>         o org.apache.directory.server:apacheds-bootstrap-extract:1.5.0
>         o org.apache.directory.server:apacheds-constants:1.5.0
>         o org.apache.directory.server:apacheds-utils:1.5.0
>         o org.apache.directory.server:apacheds-core:1.5.0
>         o org.apache.directory.shared:shared-asn1:0.9.6
> 
> Obviously, 1.5.0 != 1.5.1-SNAPSHOT and 0.9.6 != 0.9.7-SNAPSHOT
> 
> try that in your pom.xml, it should be better :
> 
>    <dependency>
>        <groupId>org.apache.directory.server</groupId>
>        <artifactId>apacheds-core</artifactId>
>        <version>1.5.1-SNAPSHOT</version>
>      </dependency>
> 
> Ok, no harm. I just wanted you to realize that you _must_ analyze the
> reasons, not the symptoms. Symptoms does not generate the problem.
> They just exhibit it.
> 
> Emmanuel
> 
> 
> 
> On 6/16/07, Ole Ersoy <ole.ersoy@gmail.com> wrote:
>> Emmanuel,
>>
>> Here's the thing.  I just did a fresh checkout from the trunk.  If the 
>> logging file is there, the exception is non existent.  That means the 
>> patch works right?  If the logging file is removed or renamed, then 
>> the exception happens.  I think the only way to verify this is to go 
>> through the steps I gave.  Could you please just do the steps I gave 
>> you?  It will only take two two minutes.  I promise.
>>
>> I would do the patchy thingy, but that's a learning curve for me.  It 
>> will take me at least 20 minutes to figure out patchy stuff.  Yes it's 
>> one of those things I need to learn, but the process I gave you only 
>> takes two minutes.  I win :-)  I'll tell you what.  If you run through 
>> the steps, and the exception does not occur, I owe you a night of 
>> beers in Chicago or Paris, or some convention city, whichever        
>> comes first :-)
>>
>> Cheers,
>> - Ole
>>
>> Emmanuel Lecharny wrote:
>> > Ole Ersoy a écrit :
>> >
>> >>
>> >>
>> >> Emmanuel Lecharny wrote:
>> >>
>> >>> Ole Ersoy a écrit :
>> >>>
>> >>>> Emmanuel,
>> >>>>
>> >>>>
>> >>>> Suppose I was using an old jar.  Why does my test pass then?
>> >>>
>> >>>
>> >>> I told you three times that the bug happens ONLY if you run the test
>> >>> with a log4j in DEBUG mode, otherwise the toString() method is
>> >>> _never_ called. This is why your test pass when you don't use the
>> >>> logging file.
>> >>
>> >>
>> >> I think this is what you are missing.
>> >> 
>> ========================================================================
>> >> This is why your test pass when you don't use the logging file.
>> >> 
>> ========================================================================
>> >>
>> >> I am using the logging file.  It's only if the logging file is renamed
>> >> or removed that the exception happens.
>> >
>> > Oh, ok. I inverted the context. Nevertheless, this toString() method is
>> > only called when in DEBUG mode. So this is not something you are likely
>> > to have, unless you are in DEBUG mode.
>> >
>> >> I gave the verification process.  We've spent way more time discussing
>> >> this than it would have taken you to just run through the verification
>> >> steps.  If you tell me that renaming the logging file should cause
>> >> this exception, then I'll close the issue.
>> >
>> > I'm not telling that shooting the messenger (here, the logging file)
>> > will help at all. I just say that - and if you look carefully at the
>> > code I posted - this is definitively *not* a code in the trunk, as it
>> > has been fixed.
>> >
>> > Look at the line 320, and simply tell me if this can throw the 
>> exception
>> > or not. If the response is :"yes, this is strange, it should not but I
>> > get the excpetion", then you have *another* problem elsewhere. 
>> That's it.
>> >
>> > Do me a favor : patch the code of this method, add a try { ... } 
>> catch (
>> > ArrayOutOfBoundException e) { e.printStackTrace(); } in it, and if the
>> > stacktrace is produced, I own you a beer, ok ?
>> >
>> > Thanks.
>> > Emmanuel.
>> >
>> > PS : Chris fixed the bug 3 months ago. I applied the patch. Twice.
>> >
>> >
>> >
>>
> 
> 

Mime
View raw message