Uwe Schindler wrote:
Im using Windows and I'll try NIO, good idea, my app is already memory
hungry in other areas so I guess MMapped is a no go, doe sit use heap or
perm
memory ?
It uses address space for mapping the files into virtual memory (like a swap
file) - this is why it o
> Im using Windows and I'll try NIO, good idea, my app is already memory
> hungry in other areas so I guess MMapped is a no go, doe sit use heap or
perm
> memory ?
It uses address space for mapping the files into virtual memory (like a swap
file) - this is why it only works well for 64bit VMs. The
Uwe Schindler wrote:
That lock contention is fine there as this is the central point where all IO
is done. This does not mean that only one query is running in parallel, the
queries are still running in parallel. But there is one place where all IO
is waiting for one file descriptor. This is not
Uwe Schindler wrote:
Can you show us where it exactly blocks (e.g. use Ctrl-Break on windows to
print a thread dump)? IndexSearchers methods are not synchronized and
concurrent access is easy possible, all concurrent access is managed by the
underlying IndexReader. Maybe you synchronize somewhere
?
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Paul Taylor [mailto:paul_t...@fastmail.fm]
> Sent: Wednesday, August 25, 2010 10:26 PM
> To: java-user@lucene.apache.org
> Subject: Blocking o
Hi
My multithreaded code was always creating a new IndexSearcher for every
search, but I changed over to the recommendation of creating just one
index searcher and keeping it between searches. Now I find if I have
multiple threads trying to search they
block on the search method(), only one c
