Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace superfluous usage of Counter with Supplier #39048

Merged
merged 5 commits into from
Feb 21, 2019

Conversation

matriv
Copy link
Contributor

@matriv matriv commented Feb 18, 2019

Counter was used as a means of a functional argument to pass
around the relative cached time before Supplier iface was introduced.

`Counter` was used as a means of a functional argument to pass
the relative cached time before `Supplier` iface was introduced.
@matriv matriv added >non-issue :Core/Infra/Core Core issues without another label v8.0.0 v7.2.0 labels Feb 18, 2019
@matriv matriv requested a review from s1monw February 18, 2019 10:58
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

@matriv matriv changed the title Replace superfluous Counter with Supplier Replace superfluous usage of Counter with Supplier Feb 18, 2019
Copy link
Contributor

@s1monw s1monw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left some comments


final class DefaultSearchContext extends SearchContext {

private final long id;
private final ShardSearchRequest request;
private final SearchShardTarget shardTarget;
private final Counter timeEstimateCounter;
private final Supplier<Long> timeEstimate;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use LongSupplier instead

@@ -252,8 +252,8 @@ public long absoluteTimeInMillis() {
return cachedTimeThread.absoluteTimeInMillis();
}

public Counter estimatedTimeInMillisCounter() {
return cachedTimeThread.counter;
public Supplier<Long> estimatedTimeInMillis() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this can be removed and replaced by ThreadPool::relativeTimeInMillis on the consumer end

@@ -648,7 +648,7 @@ private DefaultSearchContext createSearchContext(ShardSearchRequest request, Tim
Engine.Searcher engineSearcher = indexShard.acquireSearcher(source);

final DefaultSearchContext searchContext = new DefaultSearchContext(idGenerator.incrementAndGet(), request, shardTarget,
engineSearcher, clusterService, indexService, indexShard, bigArrays, threadPool.estimatedTimeInMillisCounter(), timeout,
engineSearcher, clusterService, indexService, indexShard, bigArrays, threadPool.estimatedTimeInMillis(), timeout,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use threadPool::relativeTimeInMillis

return currentTimeMillis;
}
};
public Supplier<Long> estimatedTimeInMillis() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just use :: relativeTimeInMillis on the consumer end.

@matriv
Copy link
Contributor Author

matriv commented Feb 18, 2019

@s1monw Thank you! Addressed comments.

Copy link
Member

@jasontedor jasontedor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a comment about naming.


final class DefaultSearchContext extends SearchContext {

private final long id;
private final ShardSearchRequest request;
private final SearchShardTarget shardTarget;
private final Counter timeEstimateCounter;
private final LongSupplier timeEstimate;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this name is misleading because we are using a relative notion of time here whereas the name could be construed as an estimate of the absolute time (like a timestamp). In other places we use the name relativeTimeSupplier to make it clear the purpose of the variable, and to avoid a problem if in the future someone were to use this variable for another piece of code to try to get the absolute time. It would also be worthwhile to add a comment explaining why relative time is okay here. It is important to keep the two uses between absolute and relative time absolutely clear.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would just name it timeSupplier. I also think we should not expose the LongSupplier on SerachContext at all and only provide a method to access the time public long getTime() on SearchContext.java The usage is simple and can just call this method. no need to expose the supplier.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Chose getTimeInMillis() to be even more clear.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please include the word relative in the name.

Copy link
Contributor

@s1monw s1monw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left one more comment


final class DefaultSearchContext extends SearchContext {

private final long id;
private final ShardSearchRequest request;
private final SearchShardTarget shardTarget;
private final Counter timeEstimateCounter;
private final LongSupplier timeEstimate;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would just name it timeSupplier. I also think we should not expose the LongSupplier on SerachContext at all and only provide a method to access the time public long getTime() on SearchContext.java The usage is simple and can just call this method. no need to expose the supplier.

@matriv matriv requested a review from s1monw February 19, 2019 13:14
Copy link
Contributor

@s1monw s1monw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@jasontedor jasontedor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still have concerns about the naming not being explicit enough.

@matriv
Copy link
Contributor Author

matriv commented Feb 20, 2019

@jasontedor please check again

Copy link
Member

@jasontedor jasontedor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thank you for the improvement and all the iterations.

@matriv matriv merged commit 8eb649c into elastic:master Feb 21, 2019
@matriv matriv deleted the mt/replace-counter branch February 21, 2019 08:23
matriv added a commit to matriv/elasticsearch that referenced this pull request Feb 21, 2019
`Counter` was used as a means of a functional argument to pass
the relative cached time before `Supplier` iface was introduced.
matriv added a commit that referenced this pull request Feb 21, 2019
`Counter` was used as a means of a functional argument to pass
the relative cached time before `Supplier` iface was introduced.
jasontedor added a commit to DaveCTurner/elasticsearch that referenced this pull request Feb 22, 2019
* elastic/master:
  Ensure index commit released when testing timeouts (elastic#39273)
  Avoid using TimeWarp in TransformIntegrationTests. (elastic#39277)
  Fixed missed stopping of SchedulerEngine (elastic#39193)
  [CI] Mute CcrRetentionLeaseIT.testRetentionLeaseIsRenewedDuringRecovery (elastic#39269)
  Muting AutoFollowIT.testAutoFollowManyIndices (elastic#39264)
  Clarify the use of sleep in CCR test
  Fix testCannotShrinkLeaderIndex (elastic#38529)
  Fix CCR tests that manipulate transport requests
  Align generated release notes with doc standards (elastic#39234)
  Mute test (elastic#39248)
  ReadOnlyEngine should update translog recovery state information (elastic#39238)
  Wrap accounting breaker check in assertBusy (elastic#39211)
  Simplify and Fix Synchronization in InternalTestCluster (elastic#39168)
  [Tests] Make testEngineGCDeletesSetting deterministic (elastic#38942)
  Extend nextDoc to delegate to the wrapped doc-value iterator for date_nanos (elastic#39176)
  Change ShardFollowTask to reuse common serialization logic (elastic#39094)
  Replace superfluous usage of Counter with Supplier (elastic#39048)
  Disable bwc tests for elastic#39094
weizijun pushed a commit to weizijun/elasticsearch that referenced this pull request Feb 22, 2019
`Counter` was used as a means of a functional argument to pass
the relative cached time before `Supplier` iface was introduced.
weizijun pushed a commit to weizijun/elasticsearch that referenced this pull request Feb 22, 2019
`Counter` was used as a means of a functional argument to pass
the relative cached time before `Supplier` iface was introduced.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants