<div class="im"><div>On 19/05/2009, at 7:56 PM, Manik Surtani wrote:</div><div><br></div><blockquote type="cite"><div><blockquote type="cite">I&#39;ve
been trying to get jbc-searchable working with JbossCache 3, but then I
noticed this thread for Infinispan.  I am trying to build a
proof-of-concept for a distributed searchable cache, and obviously
infinispan with hibernate search would be an ideal solution.  At what
stage of development is this?  Is it possible to use the existing
jbc-searchable code with infinispan?  Should I perhaps stick with jbc
for now?<br></blockquote><br>This isn&#39;t in Infinispan as yet.  The plan
is to add querying support, but it won&#39;t make our next major release.
 Unless you feel like contributing it.  :-)<br></div></blockquote><div><br></div></div><div>I&#39;d
be happy to take a look.  What would be the preferred to monitor what
data is being stored on the local node?  I took a look at the
interceptors, but Im unsure as to where to start.  In theory, I guess
you just need to know what data is being stored or evicted from the
local node and update an index accordingly.</div><div class="im"><br><blockquote type="cite"><div><blockquote type="cite">I
also tried using the jbosscache-lucene Directory implementation that
Manik wrote, but things started to die when lucene tried to merge
segments.  Has there been any work to create a infinispan-backed lucene
Directory?<br></blockquote><br>There hasn&#39;t been any effort as yet, and
with Vladimir&#39;s recent work on the lock() API, I expect Infinispan to
be a far better fit for a Lucene directory than JBoss Cache is.  So
again, if you are interested in contributing this, perhaps based on my
JBoss Cache implementation, it would be much appreciated.<br></div></blockquote>I&#39;m leaning away from storing the Directory in-grid at the moment, feels like a more complex and error-prone solution than keeping indices on each machine (no distributed locks, etc).  Redundant indices also protects against index corruption, something we seem to get a lot of in our current implementation (using ruby&#39;s ferret, although I am sure Lucene is more reliable).<br>
<br>Ray<br></div>