Fair question. All I did/need was take SegmentInfos and instead of subclassing Vector I made it contain a Vector. Went from subclassing to aggregation. As far as I could tell from reading the code it would make no difference to anyone and should have no performance impact (good or bad). It just allowed me to cluster the IndexWriter with a RAMDirectory.
Maybe a little background would help. Our clustering product doesn't use java serialization and has no API. We just use a little config where one points us to what you want clustered and what java synchronization needs to be shared. One of the limitations that currently exists is that we don't support clustering subclasses of java collections. At this point I'm just experimenting to see if our product can cluster lucene in a useful/performant way. When my experimenting is complete, if everything is positive, I am going to write a blog on clustering lucene indexes but it would be awkward to do that if the people who run through the example have to change lucene code. Does this help? Cheers, Steve On 9/21/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: Questions: : Is this useful in the real world : Would it be possible to get that one small thing changed. I'm not really clear on what the "small thing" is that you are asking about ... you mentioned SegmentInfos subclassing Vector, are you proposing an alternative? If you've got a patch that doesn't break existing functionality or have a negative impact on performance and makes lucene more usable in some way it would certainly be considered ... i'm just not really clear on what change you're suggesting and how it helps make Lucene more usable for you. -Hoss --------------------------------------------------------------------- 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]
