You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Josh Elser (JIRA)" <ji...@apache.org> on 2015/04/08 21:12:15 UTC
[jira] [Updated] (ACCUMULO-3717) Add trace instrumentation around
recovery
[ https://issues.apache.org/jira/browse/ACCUMULO-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Josh Elser updated ACCUMULO-3717:
---------------------------------
Component/s: trace
> Add trace instrumentation around recovery
> -----------------------------------------
>
> Key: ACCUMULO-3717
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3717
> Project: Accumulo
> Issue Type: Improvement
> Components: trace, tserver
> Reporter: Josh Elser
> Fix For: 1.8.0
>
>
> Noticed this when looking into some tracing things with Billie: it doesn't appear that we have recovery instrumented with tracing.
> It would be nice to know what the long pole in the tent is for recovery since it typically represents a period of unavailability of some data for users. We should be aware of why it takes as long as it does and try to reduce it as much as possible.
> Because spans are delivered via ZK, I *think* it will be ok if we're performing recovery on a WAL which contains updates for the trace table. As long as the serialization to the trace table doesn't cause problems (it should just create back-pressure in the tracer, but not throw exceptions), I think it should be fine. Some testing would be needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)