Sure, I'm fairly new to Lucene but what I was trying to do was make it so that an index could be shared among multiple nodes. If an index is updated in any way it would be updated across the cluster coherently. In my first version I was really only taking advantage of the fact that we detect fine grained changes and can extend synchronization across the cluster but if I can prove to myself that this is actually useful I'll go back and mark some of the synchronize blocks/methods as read locks to improve concurrency and reduce instrumentation to only what is needed.
If I'm going to be able to publish the config for what I'm doing I would need to change that one class that I mentioned above becuase we won't support subclasses of collections for a few more months. I'm not a very good writer. Does any of that make sense? Summary would be: Goals, Usefully cluster luncene indexes for across multiple nodes. Questions: Is this useful in the real world Would it be possible to get that one small thing changed. Cheers, Steve On 9/21/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 9/20/06, Steve Harris <[EMAIL PROTECTED]> wrote: > Is clustering the IndexWriter really all I need to do? Hi Steve, Could you explain the details of what "clustering" really means in this context? -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
