fix bug about chunk response handling #1389

Merged
merged 1 commit into from Dec 26, 2016

Projects

None yet

2 participants

@tagomoris
Member

fixes #1388.

v0.14.11 should be released after this change is merged for quick regression fix.
The changes between v0.14.10 release and this change will be introduced at v0.14.12.

@tagomoris tagomoris fix bug about chunk response handling
0579cce
@tagomoris tagomoris self-assigned this Dec 23, 2016
@tagomoris tagomoris requested a review from repeatedly Dec 23, 2016
@tagomoris
Member

@repeatedly could you review this?

@@ -178,7 +178,7 @@ def start
# But it should be overwritten by ack_response_timeout to rollback chunks after timeout
if @ack_response_timeout && @delayed_commit_timeout != @ack_response_timeout
@repeatedly
repeatedly Dec 24, 2016 Member

If @delayed_commit_timeout and @ack_response_timeout are the same, @delayed_commit_timeout = @ack_response_timeout + 2 line is skipped. Is this okay?

@tagomoris
tagomoris Dec 24, 2016 Member

ok, because these are configured intentionally by users, and don't cause problems for longer configured values.

@@ -178,7 +178,7 @@ def start
# But it should be overwritten by ack_response_timeout to rollback chunks after timeout
if @ack_response_timeout && @delayed_commit_timeout != @ack_response_timeout
log.info "delayed_commit_timeout is overwritten by ack_response_timeout"
@repeatedly
repeatedly Dec 24, 2016 Member

OT. Adding why message is better for users to understand why delayed_commit_timeout is overwritten in out_forward.

@@ -214,22 +214,23 @@ def write(chunk)
select_a_healthy_node{|node| node.send_data(tag, chunk) }
end
- ACKWaitingSockInfo = Struct.new(:sock, :chunk_id, :node, :time, :timeout) do
+ ACKWaitingSockInfo = Struct.new(:sock, :chunk_id, :chunk_id_base64, :node, :time, :timeout) do
@repeatedly
repeatedly Dec 24, 2016 Member

Just one idea.
How about using def chunk_id_base64 instead of struct member?
It reduces additional member cost.

@tagomoris
tagomoris Dec 24, 2016 edited Member

It's not bad idea, but it looks better for me to add these methods to chunk:

  • unique_id_hex
  • unique_id_base64

These values are called many times (especially _hex for logging), and should be cached not to calculate 2 or more times.
How do you think about it?

@repeatedly
repeatedly Dec 24, 2016 Member

Hm... it also seems good.

@tagomoris
tagomoris Dec 24, 2016 Member

Another one: chunk.unique_id(:hex) (or :base64)

@repeatedly
repeatedly Dec 25, 2016 Member

I like method approach, unique_id_hex, rathar than unique_id(:hex).

@tagomoris
tagomoris Dec 26, 2016 Member

Fixing this point makes many bad things (one is unreasonable SEGV in Travis) and doesn't bring so big happy.
I'll leave this as is.

@tagomoris tagomoris merged commit 739e7db into master Dec 26, 2016

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@tagomoris tagomoris deleted the fix-bug-forward-ack-reponse branch Dec 26, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment