[
https://issues.apache.org/jira/browse/SOLR-12521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531769#comment-16531769
]
Gus Heck commented on SOLR-12521:
---------------------------------
I had a version of this and then wrote a unit test for it. The test pointed out
that we should be clear about what we intend here. I believe this is intending
to change the semantic of the deletion time frame such that it's relative to
the youngest document received that did not exceed the maxFuture setting. This
differs from current behavior which is tied to the timestamp on the youngest
collection (when it is created), and represents a slight change in behavior.
> TRA: evaluate autoDeleteAge independently of when collections are created
> -------------------------------------------------------------------------
>
> Key: SOLR-12521
> URL: https://issues.apache.org/jira/browse/SOLR-12521
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Reporter: David Smiley
> Priority: Major
>
> Today, aging out the oldest collection due to exceeding autoDeleteAge occurs
> immediately before new collections in the Time Routed Alias are created.
> It's performed by MaintainRoutedAliasCmd. While this is fine, it would be
> better if this were evaluated at additional circumstances -- basically
> whenever we get new documents. This would make the TRA more responsive to
> dynamic changes in this metadata and it would allow more effective use of
> finer granularity of autoDeleteAge than the interval size. Furthermore, once
> we create new TRA collections preemptively (SOLR-12357), we'll probably want
> this even more since otherwise the oldest collection will tend to stick
> around longer. SOLR-12357 could probably share some logic here since both
> will involve preemptive action (action that does not delay routing the
> current document) by the TimeRoutedAliasUpdateProcessor, and both need to
> deal with not overloading the overseer with effectively redundant requests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
