[
https://issues.apache.org/jira/browse/KUDU-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16151608#comment-16151608
]
Adar Dembo commented on KUDU-2131:
----------------------------------
bq. If you think the fix makes sense, I will put up a CR for it.
Yes, definitely do that.
bq. Meanwhile, do you think we should still add a user facing flag to control
the tablet copy expiration time, similar to "--tablet_copy_idle_timeout_ms", to
at least have a workaround if encounter case like this again? Even though I
would image it would be very rare given "log_container_max_size" to be 10GB.
Good question. I don't think it would hurt to stop tagging
--table_copy_idle_timeout_ms as hidden (and tag it with advanced and evolving,
something like that). While we're at it we should also change it from ms to
seconds, since outside of tests the likely values are going to be quite high.
> Tablet copy session may expire before completion for large tablet
> -----------------------------------------------------------------
>
> Key: KUDU-2131
> URL: https://issues.apache.org/jira/browse/KUDU-2131
> Project: Kudu
> Issue Type: Bug
> Reporter: Hao Hao
> Priority: Blocker
> Fix For: 1.5.0
>
>
> KUDU-1726 introduced an optimization to do a bulk sync-to-disk once the
> tablet copy operation is complete. However, when tested in a large cluster, I
> found disk synchronization in batches can result in the tablet session
> expires before the synchronization complete. There is a flag
> '--tablet_copy_idle_timeout_ms' to control the amount of time without
> activity before a tablet copy session expires, but it is tagged as hidden(not
> user-facing).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
