Re: No inline metadata reader available for version 109

On Tue, Jan 25, 2011 at 1:22 AM, Andre Juffer <[email protected]> wrote:
> On 01/25/2011 04:50 AM, Natalia Shilenkova wrote:
>>
>> On Jan 24, 2011, at 12:27 PM, Andre Juffer wrote:
>>
>>> Due to an expected crash of a server, a few (3) entries in the XML
>>> database were corrupted. All but one could be restored from backup, by
>>> deleting the affected entry and uploading the entry from backup. In all
>>> these cases, the affected entry lost some data, causing XML parsing err=
ors.
>>>
>>> However, in one case, I receive the following error:
>>>
>>> =A0No inline metadata reader available for version 109
>>>
>>> This prevents me to read or write that entry in question. All actions
>>> cause the above error message to appear. This is very unfortunate as XI=
ndice
>>> has been extremely stable for years now. For the backup, I also extract=
 all
>>> entries into the separate location (in addition to just copying the act=
ual
>>> database), but now of course the extraction actually fails:
>>>
>>>
>>> [WARN] XMLCompressedInput - -invalid node type : 5
>>> [WARN] XMLCompressedInput - -invalid node type : 5
>>> [WARN] ElementImpl - -ignored
>>> exception<java.io.EOFException>java.io.EOFException
>>> =A0 =A0 =A0 =A0at java.io.DataInputStream.readShort(DataInputStream.jav=
a:298)
>>> =A0 =A0 =A0 =A0at
>>> org.apache.xindice.xml.dom.ElementImpl.loadAttributes(ElementImpl.java:=
175)
>>> .....
>>> [WARN] ElementImpl - -ignored
>>> exception<java.lang.NullPointerException>java.lang.NullPointerException
>>> =A0 =A0 =A0 =A0at
>>> org.apache.xindice.xml.dom.ElementImpl.loadAttributes(ElementImpl.java:=
184)
>>> ...
>>>
>>> What would be the appropriate course of action to resolve this issue. I=
s
>>> there a way to extract the binary file in another way (not XML-based) s=
o
>>> that I manually delete the affected entry.
>>>
>>> XIndice version: v1.1b5-dev
>>>
>>
>> Andre,
>>
>> Are you trying to retrieve the corrupted document from the database or
>> just delete it? If it is the latter, then the simplest way, I think, is =
to
>> create new empty collection and load the existing documents.
>
> Yes, I thought already that is probably the way to go. It will be
> cumbersome.

Yes, it can take a while, depending on the size of a collection... I
think it may be possible to delete the corrupted entry using low-level
API that doesn't try to interpret the data, but I would strongly
recommend rebuilding the collection anyway, just to be sure that there
are no hidden problems.

Regards,
Natalia

>> Does the exception for XMLCompressedInput happen for the same collection
>> and the same corrupt document or for some unrelated backup collection?
>
> The backup is fine. It was created before the crash. The entry in the db
> itself is corrupted. I manage to 'isolate' the corrupted entry such that
> users are not anymore affected.
>
>>
>> Regards,
>> Natalia
>>
>>> --
>>> Andre H. Juffer =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone: +358-8-553 1161
>>> Biocenter Oulu and =A0 =A0 =A0 =A0 =A0 | Fax: +358-8-553-1141
>>> Department of Biochemistry =A0 | Email: [email protected]
>>> University of Oulu, Finland =A0| WWW: www.biochem.oulu.fi/Biocomputing/
>>> StruBioCat =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | WWW: www.strubiocat.ou=
lu.fi
>>> NordProt =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | WWW: www.nordprot.or=
g
>>> Triacle Biocomputing =A0 =A0 =A0 =A0 | WWW: www.triacle-bc.com
>>