[
https://issues.apache.org/jira/browse/SOLR-11670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16388379#comment-16388379
]
Shalin Shekhar Mangar commented on SOLR-11670:
----------------------------------------------
Thanks Andrzej! A few comments:
* Autoscaling.java -- the constant AUTO_ADD_REPLICAS_LISTENER_NAME is not used
anywhere
* ExecutePlanAction -- the counter appended to the asyncId has been removed. It
is not useful today I agree but it will be needed again when SOLR-11605 is
implemented
* InactiveShardCleanupAction -- It is not safe to compare nanotime if the
overseer leader changed between the shard split and the cleanup task. Perhaps
we stick to currentTimeMillis() here?
* Perhaps we should let InactiveShardCleanupAction only produce operations that
are later executed by ExecutePlanAction? The advantage is that those operations
(and others created by clean up tasks in future) can be performed in parallel
once SOLR-11605 comes in. But more importantly, an exception thrown in one
clean up action will not cause the action processing to be aborted. This point
is moot however if you envision each future clean up action to have its own
scheduled trigger (in which case we should increase the schedule interval for
this one to something very large e.g. once a day). It is also possible that
future clean up tasks do not produce solrj requests at all. I'm curious to know
what you think about this.
* Exceptions thrown from the delete shard API should also be added to context
properties so that they can be sent to listeners
* SimSolrCloudTestCase -- many unused imports
> Implement a periodic house-keeping task
> ---------------------------------------
>
> Key: SOLR-11670
> URL: https://issues.apache.org/jira/browse/SOLR-11670
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Major
> Attachments: SOLR-11670.patch, SOLR-11670.patch
>
>
> Some high-impact cluster changes (such as split shard) leave the original
> data and original state that is no longer actively used. This makes sense due
> to safety reasons and to make it easier to roll-back the changes.
> However, this unused data will accumulate over time, especially when actions
> like split shard are invoked automatically by the autoscaling framework. We
> need a periodic task that would clean up this kind of data after a certain
> period.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
