Skip to content

Persist currently started allocation IDs to index metadata #14964

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

Merged

Conversation

ywelsch
Copy link
Contributor

@ywelsch ywelsch commented Nov 24, 2015

These allocation IDs serve as candidates to decide future primary shards

Subtask of #14739

@@ -218,6 +226,7 @@ private IndexMetaData(String index, long version, State state, Settings settings
this.settings = settings;
this.mappings = mappings;
this.customs = customs;
this.primaryCandidateAllocationIds = primaryCandidateAllocationIds;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should make this unmodifiable here at least?

@s1monw
Copy link
Contributor

s1monw commented Nov 24, 2015

left minor comments LGTM otherwise

private IndexMetaData(String index, long version, State state, Settings settings, ImmutableOpenMap<String, MappingMetaData> mappings, ImmutableOpenMap<String, AliasMetaData> aliases, ImmutableOpenMap<String, Custom> customs) {
private IndexMetaData(String index, long version, State state, Settings settings, ImmutableOpenMap<String, MappingMetaData> mappings,
ImmutableOpenMap<String, AliasMetaData> aliases, ImmutableOpenMap<String, Custom> customs,
Set<String> primaryCandidateAllocationIds) {
Copy link
Contributor

Choose a reason for hiding this comment

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

can we call these "activeAllocationIds" ?

Copy link
Contributor

Choose a reason for hiding this comment

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

also we need those PER shard.. so the allocation ids for shard 0, alloc ids for shard 1 etc.

@bleskes
Copy link
Contributor

bleskes commented Nov 24, 2015

This looks good. I left some minor suggestion. Note the comment about storing allocation ids per shard in the meta data. I know the allocation Ids are unique so in theory we can throw them in one big pile, but I think it will be clearer in terms of code and API later on to have them separated.

@ywelsch
Copy link
Contributor Author

ywelsch commented Nov 25, 2015

Pushed a larger set of changes, please have another look @bleskes and @s1monw. I store the allocation ids now on a per shard id basis and introduced a new class that helps with the serialization / cluster diffs.

entry.getValue().writeTo(out);
}
}
}

private static abstract class StringKeyedMapDiff<T extends Diffable<T>, M> extends MapDiff<String, T, M> {
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we should follow the OpenIntMap and call this StringMapDiff , just to key things shorter.

clusterState = ClusterState.builder(clusterState).routingResult(rerouteResult).build();

// active allocation ids should not be updated
assertThat(clusterState.getRoutingTable().shardsWithState(UNASSIGNED).size(), equalTo(3));
Copy link
Contributor

Choose a reason for hiding this comment

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

cool. Thanks!

@bleskes
Copy link
Contributor

bleskes commented Nov 30, 2015

Nice one @ywelsch . Left some minor comments.

@ywelsch
Copy link
Contributor Author

ywelsch commented Nov 30, 2015

@bleskes Another set of changes:

  • Reworked DiffableTests so that it now parameterizes over the following:
    • map implementation type (JDK Map, ImmutableOpenMap, ImmutableOpenIntMap)
    • map value type (Diffable or non-diffable)
    • specific values that are added / removed. We now compare randomly-generated sets.
  • Moved value extraction from IndexMetaData constructor to its builder
  • supportsDiffableValues() is now applied after equals check
  • removed unnecessary builder methods

*
* Note: this implementation is ignoring the key.
*/
public static class DiffablePrototypeValueReader<K, V extends Diffable<V>> extends DiffableValueSerializer<K, V> {
Copy link
Contributor

Choose a reason for hiding this comment

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

DiffablePrototypeValueReader -> DiffablePrototypeValue_Serializer_ for consistency

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The prototype is only used for the "reading" part, hence the name.

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah, got it- just found it confusing.

@bleskes
Copy link
Contributor

bleskes commented Dec 1, 2015

LGTM. Left some minor suggestions (first on the commit - sorry for the noise). I would love it if @s1monw or @imotov will also look at the changes to the diff infra as the were involved in it as well.

@ywelsch
Copy link
Contributor Author

ywelsch commented Dec 1, 2015

pushed minor changes to address @bleskes's suggestions

  • check correctness of diffmap
  • randomize serialization

return diffs;
}

public Map<K, T> getUpserts() {
Copy link
Contributor

Choose a reason for hiding this comment

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

can we have some javadocs what that is?

@s1monw
Copy link
Contributor

s1monw commented Dec 2, 2015

I will look again this afternoon... sorry for the delay

/**
* Writes value as diff to stream if this serializer supports diffable values
*/
void writeDiffTo(Diff<V> value, StreamOutput out) throws IOException;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think write and read would be enough as method names? the Diff & To part is implicit from the args?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense to throw the To and From part away. I want to keep writeDiff and readDiff though. For readDiff, it's necessary as it has the same method signature as read (except return type). To keep things symmetric for write and make it more verbose in the code of the MapDiff implementation, I'll use writeDiff.

@s1monw
Copy link
Contributor

s1monw commented Dec 2, 2015

i left some cosmetic comments LGTM in general

@ywelsch ywelsch force-pushed the feature/persist-allocid-indexmetadata branch from 7aab1a5 to 601a119 Compare December 3, 2015 09:30
@s1monw
Copy link
Contributor

s1monw commented Dec 4, 2015

LGTM

Yannick Welsch added 2 commits December 4, 2015 11:24
- Supports ImmutableOpenIntMap besides java.util.Map and ImmutableOpenMap
- Map keys can be any value (not only String)
- Map values do not have to implement Diffable interface. In that case custom value serializer needs to be provided.
@ywelsch ywelsch force-pushed the feature/persist-allocid-indexmetadata branch from 601a119 to fef043a Compare December 4, 2015 10:32
ywelsch pushed a commit that referenced this pull request Dec 4, 2015
…etadata

Persist currently started allocation IDs to index metadata
@ywelsch ywelsch merged commit 0c2c7e7 into elastic:master Dec 4, 2015
@lcawl lcawl added :Distributed Indexing/Distributed A catch all label for anything in the Distributed Indexing Area. Please avoid if you can. and removed :Allocation labels Feb 13, 2018
@clintongormley clintongormley added :Distributed Coordination/Allocation All issues relating to the decision making around placing a shard (both master logic & on the nodes) and removed :Distributed Indexing/Distributed A catch all label for anything in the Distributed Indexing Area. Please avoid if you can. labels Feb 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Coordination/Allocation All issues relating to the decision making around placing a shard (both master logic & on the nodes) >enhancement v5.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants