directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [jira] Commented: (DIRSERVER-970) Hot Partition Fails With ArrayIndexOutOfBoundsException
Date Fri, 15 Jun 2007 22:59:30 GMT

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 :-)

- 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.

View raw message