Robert Engels wrote:
The reason for using Nio and not IO is IO requires multiple file handles per file. There are already numerous bugs/work-arounds in Lucene to limit the use of file handles (as this is a OS limited resource), so I did not wish to further increase the number of file descriptors needed.
Yes, but it appears to me that the submitted NioFile class opens a new file handle per channel. So I don't see how this addresses that.
Your statement that a raid system would be needed to exploit the added concurrency is not exactly correct. By using multiple threads, even if the disk is busy handling a request, the OS can combine the pending requests and perform more efficient reads to the disk subsystem when it becomes available.
Perhaps. It would be nice to see a benchmark demonstrating this.
I also dispute the performance numbers cited. In my testing the 'user level' cache improved performance of query operations nearly 100%. I will write a testcase to demonstrate the increased performance. This testcase can be written independent of Lucene.
Can you provide your benchmark results? Thanks, Doug --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
