Thanks for bringing closure Jason!
Mike McCandless
http://blog.mikemccandless.com
On Fri, Mar 7, 2014 at 12:30 AM, Jason Wee wrote:
> Hello Mike,
>
> Thank you and you were right in your first comment, the expected field,
> Lucene46FieldInfos is within the file _0.cfs. We have taken a closer l
Hello Mike,
Thank you and you were right in your first comment, the expected field,
Lucene46FieldInfos is within the file _0.cfs. We have taken a closer look
and in details. The problem was because copy bytes in hex form from
cassandra to the byte array was wrong because the source offset was set
Are you using or aware of Solandra? See:
https://github.com/tjake/Solandra
Solandra has been superceded by a commercial product, DataStax Enterprise
that combines Solr/Lucene and Cassandra. Solr/Lucene indexing of Cassandra
data is supported, but the actual Lucene indexes are stored in the nat
That NPE is happening inside Cassandra's sources; I think you need to
trace what's happening there and how its FileBlock can be null?
It looks like it's a bug on how CassandraDirectory handles compound
files (e.g. _0.cfs), which are somewhat tricky because it's a file
that acts itself like a Direc
Hi Mike,
Thank you.
This exception is pretty clear that during lucene execute readInternal(...)
on _0.cfs and encountered an npe. The root cause is because the object
being read, FileBlock is null. As far as i can tell, it happen only during
reading _0.cfs but not on the index files that were re
This means Lucene was attempting to open _0.fnm but somehow got the
contents of _0.cfs instead; seems likely that it's a bug in the
Cassanda Directory implementation? Somehow it's opening the wrong
file name?
Mike McCandless
http://blog.mikemccandless.com
On Fri, Feb 14, 2014 at 3:13 AM, Jason
