Yes I agree, good catch.
Additionally I could add some minor performance improvement
using a background thread in SharingBufferReaderProvider,
(to have the file-closing operations of unneeded segments run async)
but didn't implement that as I was lacking a shutdown hook.
But DirectoryProvider(s) are doing the same stuff using a "stop()" method,
however I like the "destroy()" name more.
I think for consistency they should be named the same.
As the "stop" feature for DirectoryProviders is new in Search 3.1,
maybe it's still ok to change it's name?
2008/7/19 Emmanuel Bernard <email@example.com
Should we need a readerProvider.destroy()?
ReaderProvider typically keep IndexReaders open till they are in use or if the index has been updated. But it has no hook to close the "current" IndexReaders when Hibernate Search goes down.
I imagine the current code can become problematic on some VMs if we do lots of hot redeployments.
hibernate-dev mailing list