Bug #22331, Was: [VOTE] 1.1 Release Plan

[Vadim Gritsenko <va...@verizon.net>]

Mario Cormier wrote:

> Hi guys,
>
> Any chance of getting the patches that fix bugs 22317 and 22321 in 
> there?  For my use, Xindice is unworkable without both of these and 
> I'd like to be able to stop maintaining a fork of the code (even there 
> aren't that many changes) for much longer.
>
> While I'm on the soap box, might as well try and get someone in the 
> know to look at bug #22331, because I'm having a really hard time 
> figuring this one out and I'm afraid it's corrupting my data.  It's 
> worth a try anyway... :-) 


Write a test reproducing the bug which can be included as part of the 
Xindice test suite. Once bug is reproduced in the test environment, it 
is so much easier to fix it.

Thanks,
Vadim

Re: Bug #22331, Was: [VOTE] 1.1 Release Plan

[Mario Cormier <mc...@miranda.com>]

Vadim Gritsenko wrote:

> Mario Cormier wrote:
>
>> Hi guys,
>>
>> Any chance of getting the patches that fix bugs 22317 and 22321 in 
>> there?  For my use, Xindice is unworkable without both of these and 
>> I'd like to be able to stop maintaining a fork of the code (even 
>> there aren't that many changes) for much longer.
>>
>> While I'm on the soap box, might as well try and get someone in the 
>> know to look at bug #22331, because I'm having a really hard time 
>> figuring this one out and I'm afraid it's corrupting my data.  It's 
>> worth a try anyway... :-) 
>
>
>
> Write a test reproducing the bug which can be included as part of the 
> Xindice test suite. Once bug is reproduced in the test environment, it 
> is so much easier to fix it.
>
> Thanks,
> Vadim 

Thanks for the quick reply Vadim!

I really wish I could write a test case that reproduces the bug, but at 
this point I can't.  I don't know what the cause is and it seems to 
appear randomly, but frequently enough (I can see it happen in less than 
an hour).  I have yet to find what triggers it, and even if I did it 
would be difficult to write a standalone test case without modifying the 
Xindice code because it's one of those exceptions that is caught and 
ignored.  At least it's not silently ignored anymore.

For instance, it just occured again.  The index pattern is "*@*" and the 
complete document that was being inserted this time is:

<?xml version="1.0" encoding="UTF-8"?>
<entry timestamp='1061221843585' 
deviceURI='appserver_toto_Densite_SLOT_4_31' 
deviceClass='densite.SCP1121_31' 
alarmURI='appserver_toto_Densite_SLOT_4_31@aChan1_mnLvl_ST' 
alarmName='Ch1 Min Level' eventTypeID='alarm'><group 
path="iControl/appserver_toto_Densite_SLOT_4_31" /><extra><alarm><state 
type='current'>-3</state><state 
type='previous'>10000</state></alarm></extra></entry>

I can't see anything obviously wrong with this document, but maybe 
someone on the list will...  Looking through the stack, I believe it 
fails while indexing the "deviceURI" attribute, whose value is 
'appserver_toto_Densite_SLOT_4_31'.  In Btree.BTreeNode.addValue(), 
ph.getStatus() returns BRANCH, and getChildNode() returns null for 
idx==2.  The value of pointer is -1000.  The 'values' array has 2 values.

I know how difficult (impossible?) it is to try and identify a problem 
without being able to reproduce it, and that's why I'm trying to give as 
much information as I can until I can find a way to consistently 
reproduce the problem in a test case.  Hopefully someone in the know 
will spot something obvious.

Thanks for the help!

Mario