SOLR-17187: make replica poll interval configurable#3144
SOLR-17187: make replica poll interval configurable#3144gerlowskija merged 15 commits intoapache:mainfrom
Conversation
A supplied `commitPollInterval` in `updateHandler` this has precendence over one calculated from hard/soft commit settings
Also add tests for retrieving and selecting the commit interval
Co-authored-by: Christine Poerschke <cpoerschke@apache.org>
Co-authored-by: Christine Poerschke <cpoerschke@apache.org>
Co-authored-by: Christine Poerschke <cpoerschke@apache.org>
- Move poll interval determination into single method
Resolved Conflicts: solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java
epugh
left a comment
There was a problem hiding this comment.
Thanks for picking up this PR that has languished for a long time!
| pollIntervalStr = calculatedPollIntervalString; | ||
| } | ||
| final SolrConfig.UpdateHandlerInfo uinfo = core.getSolrConfig().getUpdateHandlerInfo(); | ||
| final String pollIntervalStr = determinePollInterval(uinfo); |
| boolean hardCommitNewSearcher = uinfo.openSearcher; | ||
| String pollIntervalStr = null; | ||
| if (hardCommitMaxTime != -1) { | ||
| String customCommitPollInterval = uinfo.commitPollInterval; |
There was a problem hiding this comment.
with the comment about the never null, do we need some sort of assert in here?
There was a problem hiding this comment.
I've added an assert right before this method returns; think that should be sufficient?
|
|
||
| private Long readIntervalNs(String interval) { | ||
| @VisibleForTesting | ||
| public static Long readIntervalNs(String interval) { |
There was a problem hiding this comment.
do you need the public if you have @VisibleForTesting, or is that just to remind us why it's public?
There was a problem hiding this comment.
indeed; it explains why it's more open than it otherwise needs to be
There was a problem hiding this comment.
[Q] Is the @VisibleForTesting explanation accurate though? Maybe we do call it in our tests, but we also call it in ReplicateFromLeader
Unless there's something I'm missing we should probably nuke the annotation.
| private String jettyTestMode; | ||
|
|
||
| @Before | ||
| public void setUp() { |
There was a problem hiding this comment.
don't we have some sort of Rule thing these days for this? @dsmiley ???
There was a problem hiding this comment.
Indeed we do. Firstly, all Solr tests ought to extend SolrTestCase, at least indirectly. This test doesn't; it should be modified. Secondly, STCJ4 includes:
@Rule public TestRule solrTestRules = RuleChain.outerRule(new SystemPropertiesRestoreRule());
That obsoletes the setup & tearDown here.
So for now, I suggest removing the setup & teardown here and subclass STCJ4. It's a TODO for me in my work on making SolrTestCase a better base class to transition that line from STCJ4 to STC.
| A hard commit means that, if a server crashes, Solr will know exactly where your data was stored; a soft commit means that the data is stored, but the location information isn't yet stored. | ||
| The tradeoff is that a soft commit gives you faster visibility because it's not waiting for background merges to finish. | ||
|
|
||
| In a TLOG/PULL replica setup, the commit configuration also influences the interval at which the replica is polling the shard leader. You may optionally configure a custom `commitPollInterval`. |
There was a problem hiding this comment.
Please start new sentences on new lines. Not sure if this style choice is stated somewhere. Goal is reducing diffs and reducing need for line wrap.
|
|
||
| private Long readIntervalNs(String interval) { | ||
| @VisibleForTesting | ||
| public static Long readIntervalNs(String interval) { |
There was a problem hiding this comment.
indeed; it explains why it's more open than it otherwise needs to be
| private String jettyTestMode; | ||
|
|
||
| @Before | ||
| public void setUp() { |
There was a problem hiding this comment.
Indeed we do. Firstly, all Solr tests ought to extend SolrTestCase, at least indirectly. This test doesn't; it should be modified. Secondly, STCJ4 includes:
@Rule public TestRule solrTestRules = RuleChain.outerRule(new SystemPropertiesRestoreRule());
That obsoletes the setup & tearDown here.
So for now, I suggest removing the setup & teardown here and subclass STCJ4. It's a TODO for me in my work on making SolrTestCase a better base class to transition that line from STCJ4 to STC.
|
This PR has had no activity for 60 days and is now labeled as stale. Any new activity will remove the stale label. To attract more reviewers, please tag people who might be familiar with the code area and/or notify the dev@solr.apache.org mailing list. To exempt this PR from being marked as stale, make it a draft PR or add the label "exempt-stale". If left unattended, this PR will be closed after another 60 days of inactivity. Thank you for your contribution! |
|
Looks like most of the work has been done.... @cpoerschke do you want to take this over the finish line, or I'm happy to... |
Thanks @epugh! Yes, please feel free to continue with this. |
gerlowskija
left a comment
There was a problem hiding this comment.
Took the liberty of tackling the last few TODOs here. If either of you two (@cpoerschke , @epugh ) want to take this back over, go for it. Otherwise I'll aim to commit in the next few days.
Thanks for getting the ball rolling on this @tboeghk - apologies it's taken a bit to get merged.
|
|
||
| private Long readIntervalNs(String interval) { | ||
| @VisibleForTesting | ||
| public static Long readIntervalNs(String interval) { |
There was a problem hiding this comment.
[Q] Is the @VisibleForTesting explanation accurate though? Maybe we do call it in our tests, but we also call it in ReplicateFromLeader
Unless there's something I'm missing we should probably nuke the annotation.
| boolean hardCommitNewSearcher = uinfo.openSearcher; | ||
| String pollIntervalStr = null; | ||
| if (hardCommitMaxTime != -1) { | ||
| String customCommitPollInterval = uinfo.commitPollInterval; |
There was a problem hiding this comment.
I've added an assert right before this method returns; think that should be sufficient?
| A hard commit means that, if a server crashes, Solr will know exactly where your data was stored; a soft commit means that the data is stored, but the location information isn't yet stored. | ||
| The tradeoff is that a soft commit gives you faster visibility because it's not waiting for background merges to finish. | ||
|
|
||
| In a TLOG/PULL replica setup, the commit configuration also influences the interval at which the replica is polling the shard leader. You may optionally configure a custom `commitPollInterval`. |
|
(Tests, check, and precommit pass locally. I'll add a CHANGES.txt entry right before merge.) |
A supplied `commitPollInterval` in `updateHandler` now takes precedence over the default (which is calculated based on hard/soft commit settings). --------- Co-authored-by: Torsten Bøgh Köster <torsten.koester2@otto.de> Co-authored-by: Torsten Bøgh Köster <tbk@thiswayup.de> Co-authored-by: Christine Poerschke <cpoerschke@apache.org> Co-authored-by: Jason Gerlowski <gerlowskija@apache.org>
A supplied `commitPollInterval` in `updateHandler` now takes precedence over the default (which is calculated based on hard/soft commit settings). --------- Co-authored-by: Torsten Bøgh Köster <torsten.koester2@otto.de> Co-authored-by: Torsten Bøgh Köster <tbk@thiswayup.de> Co-authored-by: Christine Poerschke <cpoerschke@apache.org> Co-authored-by: Jason Gerlowski <gerlowskija@apache.org>
Continuation of @tboeghk's #2316 as a new pull request since pushing to the PR's branch is not possible (due to org vs. individual repo fork).
origin/mainhttps://issues.apache.org/jira/browse/SOLR-17187