Thank you Shawn for looking into this to such a depth. Let me try getting hold of someway to grab this information and use it and I may reach back to you or list for further thoughts.
Thanks again, Atita On Tue, May 8, 2018, 3:11 PM Shawn Heisey <apa...@elyograg.org> wrote: > 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 > >
