Re: Xindice 1.1: crash with NullPointerException

Natalia,

About
> ... I can try to restore the documents ...

If you have some spare time, you could look at
    http://www.sics.se/~olleo/varia/002-xi/xi-db.tar.gz
which is a gzip of a tar of the whole Xindice database structure 
(including the db.lock file ;-) )

/olle

On 2010-06-10 19:08, Natalia Shilenkova wrote:
> On Thu, Jun 10, 2010 at 11:32 AM, Olle Olsson<[email protected]>  wrote:
>    
>> Comments inline ...
>>
>> On 2010-06-10 15:49, Natalia Shilenkova wrote:
>>      
>>>        
> --skip--
>
>    
>>> What you listed under SysSymbols collections looks kind of normal,
>>> except that it should have more documents. Based on your configuration
>>> from database.xml, there should be at least two more documents in
>>> /db/system/SysSymbols collection: w3c and w3c-local.
>>>
>>>        
>> Yes. I expected to see
>>   - w3c and the approximately  50+ collections underneath it
>>   - w3c-local and similar collections here too
>> What is interesting is that *one* of the 50+ nested subcollections appeared
>> in the SysSymbol listing
>>   - w3c-local/meta, appearing  as "w3c-local_meta"
>> but its root collection "w3c-local" does not appear ;-(
>>      
> OK, here's one more detail - only collections that actually have
> documents (as opposed to having only nested collections) are going to
> have symbol tables. So it is possible that some of the collections are
> not going to appear in SysSymbols.
>
>    
>>> Does /db/system/SysSymbols have any other documents in it?
>>>
>>>        
>> Nope, the only ones (collections and documents) visible are the ones listed
>> earlier (as "see in the Ugly Browser" in earlier message below). I also get
>> the same result when using xindiceadmin tool to list collections and
>> documents under db/ (to eliminate the risk of there just being a bug in the
>> Ugly Browser).
>>      
>>> As for your question - Xindice configuration location is hard-coded,
>>> it is always has the same structure (system/SysConfig and
>>> system/SysSymbols). To function properly, Xindice needs two pieces of
>>> information for compressed collections - binary data stored in the
>>> collection file itself (.tbl file) plus system data to know how to
>>> interpret that binary data. You can see the listing of the documents
>>> in collections, so I assume that collection file is OK.
>>>
>>>        
>> As I can access the contents of three documents under system/, it seems that
>> they at least are in a healthy state.
>>
>> So the observarions are:
>>   - application documents exist, as Xindice says that they exist. The listing
>> of document names in collections look OK
>>   - but accessing any application document fails
>>   - fails even for the single document that is in the *only* application
>> collection presented in SysSymbols (w3c-local/meta)
>>
>> It seems more likely that the SysSymbols data is broken, than that each and
>> every application document has been corrupted.
>>      
> --skip--
>
>    
>> Maybe there is still metadata information (about application documents)  in
>> this file, but it has become inaccessible due to some storage index getting
>> weird.
>>
>> Theoretically speaking, it might be possible to patch this storage file back
>> into working order, but I have no idea how to approach this challenge. Only
>> someone with inside knowledge about how storage is used can do something
>> sensible.
>>      
> I am familiar with internal database structure and I can try to
> restore the documents but it depends on how sensitive the data is (if
> you can share it) and how important the data is for you (I don't know
> if you have any backups, or if you can import the documents again,
> basically, just rebuild the database).
>
>    
>> /olle
>>
>>      
> Regards,
> Natalia
>    


-- 
------------------------------------------------------------------
Olle Olsson   [email protected]   Tel: +46 8 633 15 19  Fax: +46 8 751 72 30
         [Svenska W3C-kontoret: [email protected]]
SICS [Swedish Institute of Computer Science]
Box 1263
SE - 164 29 Kista
Sweden
------------------------------------------------------------------