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

Remove TranslogService and fold it into synchronous IndexShard API #13707

Merged
merged 1 commit into from Sep 23, 2015

Conversation

Projects
None yet
4 participants
@s1monw
Contributor

s1monw commented Sep 22, 2015

This commit moves the size and ops based flush into a synchronous API into
IndexShard and removes the time-based flush alltogether since it' basically
covered by the inactive async flush API we have today. The functionality doesn't
need to be covered by scheduled task and async APIs while we can actually make all
the decisions in a sync manner which is way easier to control and to test.

@kimchy

View changes

Show outdated Hide outdated ...elasticsearch/action/support/replication/TransportReplicationAction.java Outdated
@bleskes

This comment has been minimized.

Show comment
Hide comment
@bleskes

bleskes Sep 22, 2015

Member

I'm +1 on removing the time component for translog flushing which leaves translog service without any real value. Folding what's left into index shard also makes sense. I'm a bit concerned that flushing is now left to the TransportReplicationAction. It doesn't feel like that's where this logic should be as the replication action doesn't really need to know what the index shard is doing with the write operations. Instead I proposed adding this logic to index shard it self, where all write operations go through as well.

I share Shay's concern about the flush storm that may happen. In the spirit of the new java 8 lambda functionality it feels like we need a debounce utility :)

Member

bleskes commented Sep 22, 2015

I'm +1 on removing the time component for translog flushing which leaves translog service without any real value. Folding what's left into index shard also makes sense. I'm a bit concerned that flushing is now left to the TransportReplicationAction. It doesn't feel like that's where this logic should be as the replication action doesn't really need to know what the index shard is doing with the write operations. Instead I proposed adding this logic to index shard it self, where all write operations go through as well.

I share Shay's concern about the flush storm that may happen. In the spirit of the new java 8 lambda functionality it feels like we need a debounce utility :)

@s1monw

This comment has been minimized.

Show comment
Hide comment
@s1monw

s1monw Sep 22, 2015

Contributor

Instead I proposed adding this logic to index shard it self, where all write operations go through as well.

I should have added this to the issue this can't go into index shard since it would completely ruin the cleanup and add more crazy state to it sorry we have to find a different solution. I had the same concerns about the thread pool while I was AFK ....I will work on a better solution

Contributor

s1monw commented Sep 22, 2015

Instead I proposed adding this logic to index shard it self, where all write operations go through as well.

I should have added this to the issue this can't go into index shard since it would completely ruin the cleanup and add more crazy state to it sorry we have to find a different solution. I had the same concerns about the thread pool while I was AFK ....I will work on a better solution

@s1monw

This comment has been minimized.

Show comment
Hide comment
@s1monw

s1monw Sep 22, 2015

Contributor

I pushed a new commit that prevent the storms

Contributor

s1monw commented Sep 22, 2015

I pushed a new commit that prevent the storms

@kimchy

View changes

Show outdated Hide outdated core/src/main/java/org/elasticsearch/index/shard/IndexShard.java Outdated
@kimchy

This comment has been minimized.

Show comment
Hide comment
@kimchy

kimchy Sep 22, 2015

Member

left a minor comment, LGTM otherwise

Member

kimchy commented Sep 22, 2015

left a minor comment, LGTM otherwise

@bleskes

This comment has been minimized.

Show comment
Hide comment
@bleskes

bleskes Sep 22, 2015

Member

LGTM2. Agreed with Shay's comment.

Member

bleskes commented Sep 22, 2015

LGTM2. Agreed with Shay's comment.

Remove TranslogService and fold it into synchronous IndexShard API
This commit moves the size and ops based flush into a synchronous API into
IndexShard and removes the time-based flush alltogether since it' basically
covered by the inactive async flush API we have today. The functionality doesn't
need to be covered by scheduled task and async APIs while we can actually make all
the decisions in a sync manner which is way easier to control and to test.

Closes #13707

@s1monw s1monw merged commit 75e8164 into elastic:master Sep 23, 2015

1 check passed

CLA Commit author is a member of Elasticsearch
Details

s1monw added a commit that referenced this pull request Sep 23, 2015

Add back presumably redundant shouldFlush() check.
The check prevents a race condition since we can't use real locks here.
Relates to #13707

@clintongormley clintongormley removed the :Engine label Sep 23, 2015

bleskes added a commit to bleskes/elasticsearch that referenced this pull request Sep 24, 2015

Internal: pending operations in the translog prevent shard from being…
… marked as inactive

The IndexingMemoryController checks periodically if there is any indexing activity on the shard. If no activity is sean for 5m (default) the shard is marked as inactive allowing it's indexing buffer quota to given to other active shards.

Sadly the current check is bad as it checks for 0 translog operation. This makes the inactive wait for a flush to happen - which used to take 30m and since elastic#13707 doesn't happen at all (as we rely on the synced flush triggered by inactivity). This commit fixes the check so it will work with any translog size.

bleskes added a commit that referenced this pull request Sep 24, 2015

Internal: pending operations in the translog prevent shard from being…
… marked as inactive

The IndexingMemoryController checks periodically if there is any indexing activity on the shard. If no activity is sean for 5m (default) the shard is marked as inactive allowing it's indexing buffer quota to given to other active shards.

Sadly the current check is bad as it checks for 0 translog operation. This makes the inactive wait for a flush to happen - which used to take 30m and since #13707 doesn't happen at all (as we rely on the synced flush triggered by inactivity). This commit fixes the check so it will work with any translog size.

Closes #13759
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment