Description
It should be enough to have ShardId + nodeId key in routingToDataPath to find the necessary data path.
Changing the key would allow us to minimize the size of ClusterInfo size and find the data path when shard changes its status.
ClusterInfo might be sent over the wire when cluster allocation explain is executed with includeDiskInfo=true.
ShardRouting -> ShardId + nodeId conversion is trivial. The oposit would require additional information that could be faked.
Current key is also used in here:
|
builder.startObject("shard_paths"); |
|
{ |
|
for (Map.Entry<ShardRouting, String> c : this.routingToDataPath.entrySet()) { |
|
builder.field(c.getKey().toString(), c.getValue()); |
|
} |
|
} |
where it produces a string with ShardRouting#shortSummary that is excessive and might be simplified to ShardId + nodeId as well
Description
It should be enough to have ShardId + nodeId key in
routingToDataPathto find the necessary data path.Changing the key would allow us to minimize the size of ClusterInfo size and find the data path when shard changes its status.
ClusterInfomight be sent over the wire when cluster allocation explain is executed withincludeDiskInfo=true.ShardRouting -> ShardId + nodeId conversion is trivial. The oposit would require additional information that could be faked.
Current key is also used in here:
elasticsearch/server/src/main/java/org/elasticsearch/cluster/ClusterInfo.java
Lines 149 to 154 in 9ebbe1c
where it produces a string with ShardRouting#shortSummary that is excessive and might be simplified to ShardId + nodeId as well