-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add a Server API to list segments that need to be refreshed for a table #14451
base: master
Are you sure you want to change the base?
Conversation
What's the difference between this and #13789? |
This API is for refresh while IIUC that PR is for reload. I should make it
clear that this PR is for refresh in the title.
…On Fri, Nov 15, 2024 at 10:00 AM Yash Mayya ***@***.***> wrote:
What's the difference between this and #13789
<#13789>?
—
Reply to this email directly, view it on GitHub
<#14451 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMP7GRJ3H2O3PHX2PI2CD32AV2HDAVCNFSM6AAAAABRYRMF3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZXHEZTSNRXGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #14451 +/- ##
============================================
+ Coverage 61.75% 63.82% +2.07%
- Complexity 207 1570 +1363
============================================
Files 2436 2674 +238
Lines 133233 146983 +13750
Branches 20636 22548 +1912
============================================
+ Hits 82274 93816 +11542
- Misses 44911 46224 +1313
- Partials 6048 6943 +895
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
12b09b3
to
71cb333
Compare
} | ||
|
||
if (Objects.isNull(source.getH3Index()) == h3Indexes.contains(columnName)) { | ||
LOGGER.debug("tableNameWithType: {}, segmentName: {}, change: h3 index changed", tableNameWithType, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Can we improve this log to also have columnName for which the index was changed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added columnName
to all debug logs
@Override | ||
public List<NeedRefreshResponse> getSegmentsForRefresh(TableConfig tableConfig, Schema schema) { | ||
List<NeedRefreshResponse> segmentsRequiringRefresh = new ArrayList<>(); | ||
List<SegmentDataManager> segmentDataManagers = acquireAllSegments(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
acquireAllSegments also increases the ref count
so we need to decrease it as well once we get the list
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, since we are running a for loop, wouldn't a better way be to acquire each segment one by one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am releasing the segments now. To acquire a segment, how do I get the segment name ? One option is to acquire all segments, convert that into a list of names and then reacquire one by one. Any other options ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point about acquireAll. Yes thats one way. If we have a large table/with a large number of segments, this check can take time. However by the time you get to the segment, that can be released? I guess acquireSegment will return null in that case.
} | ||
} | ||
if (failedParses != 0) { | ||
LOGGER.error("Unable to parse server {} / {} response due to an error: ", failedParses, serverURLs.size()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add table name to this msg
new TypeReference<List<NeedRefreshResponse>>() { })); | ||
} catch (Exception e) { | ||
failedParses++; | ||
LOGGER.error("Unable to parse server {} response due to an error: ", streamResponse.getKey(), e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add table name to this msg
public class NeedRefreshResponse { | ||
private final String _segmentName; | ||
private final boolean _needRefresh; | ||
private final String _reason; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea to add reason as well !
@Override | ||
public List<NeedRefreshResponse> getSegmentsForRefresh(TableConfig tableConfig, Schema schema) { | ||
List<NeedRefreshResponse> segmentsRequiringRefresh = new ArrayList<>(); | ||
List<SegmentDataManager> segmentDataManagers = acquireAllSegments(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point about acquireAll. Yes thats one way. If we have a large table/with a large number of segments, this check can take time. However by the time you get to the segment, that can be released? I guess acquireSegment will return null in that case.
@Produces(MediaType.APPLICATION_JSON) | ||
@ApiOperation(value = "Gets a list of segments that need to be refreshed from servers hosting the table", notes = | ||
"Gets a list of segments that need to be refreshed from servers hosting the table") | ||
public Map<String, List<NeedRefreshResponse>> getTableRefreshMetadata( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How will the user know if we got partial Vs full response.
Would it be useful to find out missing segments for which we never got a response?
After the getSegmentsForRefreshFromServer, we can get the list of segments from ideal state and do a diff. If there's a way to propagate that list, we can just retry that list in the subsequent call.
Or at least the client knows that it did not get a complete list.
The core feature in this PR is a function
BaseTableDataManager.getSegmentsForRefresh
which finds all the segments of a table that requires a refresh. It accepts a Table Config and Schema and compares that with the current state of a segment.This functionality will be used by other components such as minion tasks to decide which segments have to be refreshed.
The function is exposed by the following server API:
segmentName is the name of the segment.
reason contains a simple message for why the segment needs to be refreshed.
There is also a controller API that consolidates the responses from all servers.
Fix for #14450