On Tue, Jan 25, 2011 at 1:22 AM, Andre Juffer <ajuf...@sun3.oulu.fi> 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 errors. >>> >>> However, in one case, I receive the following error: >>> >>> No 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 XIndice >>> 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 actual >>> 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 >>> at java.io.DataInputStream.readShort(DataInputStream.java:298) >>> at >>> org.apache.xindice.xml.dom.ElementImpl.loadAttributes(ElementImpl.java:175) >>> ..... >>> [WARN] ElementImpl - -ignored >>> exception<java.lang.NullPointerException>java.lang.NullPointerException >>> at >>> org.apache.xindice.xml.dom.ElementImpl.loadAttributes(ElementImpl.java:184) >>> ... >>> >>> What would be the appropriate course of action to resolve this issue. Is >>> there a way to extract the binary file in another way (not XML-based) so >>> 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 | Phone: +358-8-553 1161 >>> Biocenter Oulu and | Fax: +358-8-553-1141 >>> Department of Biochemistry | Email: andre.juf...@oulu.fi >>> University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/ >>> StruBioCat | WWW: www.strubiocat.oulu.fi >>> NordProt | WWW: www.nordprot.org >>> Triacle Biocomputing | WWW: www.triacle-bc.com >>
