lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <apa...@elyograg.org>
Subject Re: Determine Solr Core Creation Timestamp
Date Tue, 08 May 2018 09:41:20 GMT
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


Mime
View raw message