thanks a lot for the "hack" and jstack suggestion Uwe i will try them.
Unfortunately we are in the NFS mount since we don't have other choices.
also might be related, in the cluster(computing farm) we are indexing
parallel several size of different datasets and most them are indexed
without pr
Hi Tamer,
Actually you can skip the check with a “hack”:
You can override the check by enforcing number of threads and number of merges
at same time by setting this on your own config when using
ConcurrentMergeScheduler:
https://goo.gl/5QJpMh
If you override maxThreadCount and maxMergeCount i
thanks Uwe for reply. we are indexing data in a cluster where there are
many mount points so it is possible that one them has issue or slowness
when this check first tried but now when i execute "mount" it is
responding all the mount points.
I was wondering is there any configuration to skip t
Hi,
to figure out if you system is using an SSD drive for the index directory, the
merge scheduler has to get the underlying mount point of the index directory.
As there is no direct lookup for that, it needs to list all mount points in the
system with a Java7 FS function. And that seems to
I'm trying to index 5M Documents and currently indexing takes 13 hours. My
data source is SQL db and I've verified out of 13 hours only 30 mins is
spent in fetching data so SQL is not the bottleneck. The complete index size
is 40GB.
My application runs on Tomcat with 2GB JVM space.
Just after the
