[GitHub] [lucenenet] jeme commented on issue #494: IndexReader locks files

[GitBox <gi...@apache.org>]

jeme commented on issue #494:
URL: https://github.com/apache/lucenenet/issues/494#issuecomment-868469000


   @rclabo I don't think either of those are directly applicable here since he mentions using two different applications/processes, one for the updating and one for the reading.
   
   @mikeplacko I am not sure there is much of a change really, I am very much seeing the issue with locked files in v3 as well, we see it every time we redeploy our software as there tends to be an overlap between the new version starting up while the old one shuts down, and here we run into locked files just as well. We don't see that as an issue though but just have a retry loop that pools for this until files are no longer locked, then we know the old process is fully shut down.
   
   Som options as I see them:
   A) If your trying to use a single process to maintain the index (update it) and then push that so one or more applications can access that, I guess the Replicator is the way to go. This could allow you to update the index in one place and distribute the index to multiple other nodes for searching.
   
   B) Move your indexing into your IIS application and switch to NRT - @rclabo outlines the Lucene part of this in more detail so look at his response. You need to consider running as "Always on" in the IIS and consider how you recycle the process carefully or disable that all together.
   
   C) Move your searching/reading into your indexing process (windows process?) and then forward queries from you IIS site to that process. Again utilizing NRT.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org