On 5/7/2018 3:50 PM, Atita Arora wrote: > I noticed the same and hence overruled the idea to use it. > Further , while exploring the V2 api (as we're currently in Solr 6.6 and > will soon be on Solr 7.X) ,I came across the shards API which has > "property.index.version": "1525453818563" > > Which is listed for each of the shards. I wonder if I should be leveraging > this as this seem to be the index version & I dont think this number should > vary on restart.
The index version is a number that is milliseconds since the epoch -- 1970-01-01 00:00:00 UTC. This is how Java represents timestamps internally. All Lucene indexes have this information. The index version value appears to update every time the index changes, probably when a new searcher is opened. For SolrCloud collections, this information is actually already available, although getting to it may not be obvious. ZooKeeeper itself keeps track of when all znodes are created, so the /collections/xxxxx znode creation time is effectively what you're after. This can be seen in Cloud->Tree in the admin UI, which means that there is a way to obtain the information with an HTTP API. When cores are created or manipulated by API calls, the core.properties file will have a comment with a timestamp of the last time Solr wrote/changed the file. CoreAdmin operations like CREATE, SWAP, RENAME, and others will update or create the timestamp in that comment, but if the properties file doesn't ever get changed by Solr, then the comment would reflect the creation time. That makes it not entirely reliable. Also, I do not know of a way to access that information with any Solr API -- access to the filesystem would probably be required. The core.properties file could be a place to store a true creation time, using a new property that Solr doesn't need for any other purpose. Solr could look for a creation time in that file when the core is started and update it to include the current time as the creation time if it is not present, and certain CoreAdmin operations could also write that property. Retrieving the value would needed to be added to the CoreAdmin API. Thanks, Shawn
