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

Added _shards header to all write responses. #7994

Merged

Conversation

martijnvg
Copy link
Member

The header indicates to how many shard copies (primary and replicas shards) a write was supposed to go to, to how many shard copies to write succeeded and potentially captures shard failures if writing into a replica shard fails.

For async writes it also includes the number of shards a write is still pending.

* `successful`- Indicates the number of shard copies to index operation succeeded on.
* `pending` - Indicates to how many shard copies this index operation still needs to go to at the time index operation
succeeded on the primary shard. This field is only returned if `async` replication is used.
* `failures` - An array that contains replication related errors in the case an index operation failed on a replica shard.
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 need failed: INT , just like in search.

Copy link
Member Author

Choose a reason for hiding this comment

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

+1 I'll add that.

@martijnvg martijnvg force-pushed the feature/shard_info_write_responses branch from f728490 to 9af8a87 Compare October 9, 2014 21:08
@martijnvg
Copy link
Member Author

@javanna @bleskes I updated the PR and the provided feedback has been applied.

The other most noticeable change is that the replication logic in TransportShardReplicationOperationAction has been changed to keep better track of the state of replication while it is being performed. This helped to simplify the replication logic.

@@ -16,6 +16,10 @@ The result of the above delete operation is:
[source,js]
--------------------------------------------------
{
"_shards" : {
"total" : 10,
"successful" : 10
Copy link
Member

Choose a reason for hiding this comment

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

missing failed?

Copy link
Member Author

Choose a reason for hiding this comment

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

I added it to the code, I'll add it to the examples as well!

// The failure doesn't include the node id, maybe add it to ShardOperationFailedException...
ShardOperationFailedException sf = shardActionResult.shardFailure;

ShardIterator thisShardIterator = null;
Copy link
Contributor

Choose a reason for hiding this comment

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

why not capture the shard info during the failure handling? Then we don't need to search for the iterator..

Copy link
Member Author

Choose a reason for hiding this comment

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

good call, let me change that.

@bleskes
Copy link
Contributor

bleskes commented Dec 8, 2014

Thx @martijnvg .

Not sure if we should repeat the primary exception or just tell we never executed on replica shards.

yeah, I see what you mean. I was thinking wrapping the primary failure with a new exception which has the right info in the message? (ala "Failed to execute on shard [](primary + [] replicas): [MESSAGE]")

left some other minor comments.

@martijnvg
Copy link
Member Author

Thanks for the feedback @bleskes. I updated the PR. Since we don't have exceptions (the Failure class has no failure wrapping) for the replica shards, I instead just wrap the original primary shard failure on the message of the replica shard failure. I think this is sufficient?

@martijnvg martijnvg force-pushed the feature/shard_info_write_responses branch from c99bb0f to f6ecd57 Compare January 6, 2015 09:35
@martijnvg
Copy link
Member Author

@bleskes @javanna I applied the feedback and Boaz's commits (bleskes@a9b659d and bleskes@6180417), rebased to master and squashed everything to a single commit for clarity purposes.

I think this is getting close to get merged now, would be great if someone else can take a look at the PR before it gets merged in.


private void assertSyncShardInfo(ActionWriteResponse.ShardInfo shardInfo, NumShards numShards) {
assertThat(shardInfo.getTotal(), equalTo(numShards.totalNumShards));
assertThat(shardInfo.getSuccessful(), greaterThanOrEqualTo(1));
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not greaterThanOrEqualTo(numShards.numPrimaries) or even `equalTo(numShards.totalNumShards)?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't know why this wasn't using numShards.numPrimaries, let me change that!

@imotov
Copy link
Contributor

imotov commented Jan 6, 2015

I left a couple of small comments. In general looks good to me.

@martijnvg
Copy link
Member Author

@imotov I updated the PR and applied your comments.

@imotov
Copy link
Contributor

imotov commented Jan 7, 2015

LGTM

@martijnvg martijnvg changed the title Added _shards header to all write responses. Core: added _shards header to all write responses. Jan 8, 2015
@martijnvg martijnvg added the :Core/Infra/Core Core issues without another label label Jan 8, 2015
@martijnvg martijnvg force-pushed the feature/shard_info_write_responses branch from 9f21553 to 6fc0992 Compare January 8, 2015 16:24
@martijnvg martijnvg force-pushed the feature/shard_info_write_responses branch from 6fc0992 to 33f4241 Compare January 8, 2015 16:35
@martijnvg martijnvg force-pushed the feature/shard_info_write_responses branch from 33f4241 to 1951ba3 Compare January 8, 2015 17:00
@martijnvg martijnvg force-pushed the feature/shard_info_write_responses branch from 1951ba3 to 9f10744 Compare January 8, 2015 17:09
The header indicates to how many shard copies (primary and replicas shards) a write was supposed to go to, to how many
shard copies to write succeeded and potentially captures shard failures if writing into a replica shard fails.

For async writes it also includes the number of shards a write is still pending.

Closes elastic#7994
@martijnvg martijnvg force-pushed the feature/shard_info_write_responses branch from 9f10744 to ca4f27f Compare January 8, 2015 17:10
@martijnvg martijnvg merged commit ca4f27f into elastic:master Jan 8, 2015
@martijnvg martijnvg deleted the feature/shard_info_write_responses branch May 18, 2015 23:27
@clintongormley clintongormley added :Core/Infra/REST API REST infrastructure and utilities and removed :Core/Infra/Core Core issues without another label labels Jun 6, 2015
@clintongormley clintongormley changed the title Core: added _shards header to all write responses. Added _shards header to all write responses. Jun 6, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants