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)