Quote:
that should be HS 3.3.1 right?
Correct typo.
Quote:
Sometimes someone reports issues like this, but then it usually turns out they forgot to close something in a proper finally block.
Yep i know, thats why i just wanted to make sure.
Right i have made some headway on this and need the expert view. We are seeing this on our linux server and im seeing something funny on windows(local setup).
Ill go with my local version because its easier for me to play with the setup.
Ok we index many entities but just for test case i have focused on one
I start with a clean index for my entity, after server starts i check for any file handles to the index
1 . No handles
2. Kick off batch index for this entity, handles while running but when finished no handles open. Index now exists
3. Kick off batch index again, same result as 2.
4. At end of each run there are no handles open.
Now here is the strange part and i need your input on it
1. Start server with existing index in place.
2. Check for file handles. There is file handles (Nothing triggered or running)
3. Kick off batch index for this entity. More file handles opening but when finished only what was open in step 2 is present.
4. My index entity is double in size!!!
We have a similar setup to master/slave except instead of JMS we have a custom server which checks periodically against the DB for updates. We have a custom MasterDirectory but i have switched out for the above test case and used HS version and i still see the same.
The getDirectory on the MasterDirectoryProvider is the start
And eventually SharingBufferReaderProvider and IndexReader.open
Code:
protected IndexReader readerFactory(final Directory directory) throws IOException {
return IndexReader.open( directory, true );
}
Makes my file handles look like so
Quote:
50: File C:\lucene\master\myentity\_g.nrm
54: File C:\lucene\master\myentity\_g.fdx
58: File C:\lucene\master\myentity\_g.fdt
5c: File C:\lucene\master\myentity\_g.prx
60: File C:\lucene\master\myentity\_g.frq
64: File C:\lucene\master\myentity\_g.tis
My entity however looks like so
Quote:
$ ls -l
total 30059
-r-xr-x---+ 1 mkgroup-l-d 2968775 Jul 21 18:28 _a.fdt
-r-xr-x---+ 1 mkgroup-l-d 548692 Jul 21 18:28 _a.fdx
-r-xr-x---+ 1 mkgroup-l-d 3346799 Jul 21 18:28 _a.frq
-r-xr-x---+ 1 mkgroup-l-d 1028794 Jul 21 18:28 _a.nrm
-r-xr-x---+ 1 mkgroup-l-d 1827444 Jul 21 18:28 _a.prx
-r-xr-x---+ 1 mkgroup-l-d 5618402 Jul 21 18:28 _a.tis
-r-xr-x---+ 1 mkgroup-l-d 2968775 Jul 21 18:29 _g.fdt
-r-xr-x---+ 1 mkgroup-l-d 548692 Jul 21 18:29 _g.fdx
-r-xr-x---+ 1 mkgroup-l-d 230 Jul 21 18:29 _g.fnm
-r-xr-x---+ 1 mkgroup-l-d 3346450 Jul 21 18:29 _g.frq
-r-xr-x---+ 1 mkgroup-l-d 1028794 Jul 21 18:29 _g.nrm
-r-xr-x---+ 1 mkgroup-l-d 1827444 Jul 21 18:29 _g.prx
-r-xr-x---+ 1 mkgroup-l-d 72787 Jul 21 18:29 _g.tii
-r-xr-x---+ 1 mkgroup-l-d 5618399 Jul 21 18:29 _g.tis
-r-xr-x---+ 1 mkgroup-l-d 20 Jul 21 18:29 segments.gen
-r-xr-x---+ 1 mkgroup-l-d 275 Jul 21 18:29 segments_7
So i have these handles open even though im doing nothing with the index, is this expected behaviour?? Will try the test case above on our linux server tomorrow just to confirm it but this is what im seeing on windows.
Should be an easy enough test case for you to try locally.
LL