<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
>> Does it somehow involve not having cluster changes (ie intra VM policy rather than inter VM?)<br>
I don't really understand what you're asking; I hope previous example contains an answer; it just means you don't need<br>
to lock the index to make a "hotcopy" to anywhere.<br>
</blockquote><br>
<br></div>
My question is does it somehow involve interacting with the IndexWriter so that it does not do stuffs it would do otherwise.<br>
ie if I run indexing on VM1 and VM2, will copying files "from VM1" be affected by indexWriter operations from VM2</blockquote><div><br>My proposal to use Index snapshots is to avoid the DP lock when needing to copy somewhere, so indexing can go on without<br>
having to wait for file transfers: currently the FSMasterDirectoryProvider could take the lock for a long time.<br>This would be useful in the Master-Slave configuration, where the Lock I want to release eagerly is VM-local as the master<br>
is the sole VM writing to the index; so I don't see how I could introduce a multiple-VM problem.<br>Is it possible to combine cluster configurations described in reference 2.2.1 and 2.2.2?<br>I mean are we meant to support a configuration having 2+ VMs acting as Master for the same JMS topic and using the same filesystem index?<br>
But I see your point, I'm going to verify if an IndexWriter holding a snapshot will keep it's file-level locks or not, even when being closed<br>in the workspace.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
>> Not if it's updated in a cluster, right?<br>
>> Plus seeing the contention lock we have experienced (on IndexReader) in the recent test case, I want to be sure it's actually faster than opening every time.<br>
Why not? don't you update by using delete+insert in cluster too?<br>
</blockquote>
<br></div>
In a cluster, you open the IW do what you have to do protected by the global lock, then close the IW (and release the global lock) which means the IW on a other machine of the cluster can then have it.<br>
Does it work the same if you keep the IW opened? Does it release the global lock? Does it cope with other IWs updating the file system?</blockquote><div><br>So is Map<DirectoryProvider, ReentrantLock> getLockableDirectoryProviders() in SearchFactoryImpl returning distributed locks? <br>
Or are you telling me about Lucene's locks on the index?<br><br>thanks for all help,<br>Sanne<br></div></div><br>