this make sense now. Thanks! why I got on this idea is:
In our system we have large customer base and lots of cores, each customer may have multiple cores. there are also a lot of processes running in our system processing the data for these customers, and once a while, they would ask a center piece of webapp that we wrote to commit on a core. In this center piece webapp, I deploy it with solr in same tomcat container, its task is mainly a wrapper around the local cores to manage monitoring of the core size, merge cores if needed etc. I also have controls over the commit requests this webapp receives from time to time, try to space the commit out. In the case where multiple processes asking commits to the same core , my webapp will guarantee only one commit in x mintues interval get executed and drop the other commit requests. Now I just discovered some of the processes send in large amount of commit requests on many cores which never had any changes in the last interval. This was due to a bug in those other processes but the programmers there are behind on fixing the issue. this triggers me to the idea of verifying the incoming commit requests by checking the physical index files to see if any updates really occurred in the last interval. I was searching for any solr core admin RESTful api to get some meta data about the core such as 'last modified timestamp' ... but did not have any luck. I thought I could use 'index' folder timestamp to get accurate last modified time, but with what you just explained, it would not be the case. I will have to traverse through the files in the folder and figure out the last modified file. any input will be appreciated. Thanks a lot! Renee -- View this message in context: http://lucene.472066.n3.nabble.com/any-easy-way-to-find-out-when-a-core-s-index-physical-file-has-been-last-updated-tp4227044p4227084.html Sent from the Solr - User mailing list archive at Nabble.com.
