accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Medinets (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-1366) Create mechanism for user iterators to report problems
Date Wed, 01 May 2013 19:04:16 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646827#comment-13646827
] 

David Medinets commented on ACCUMULO-1366:
------------------------------------------

Can the problem be exposed by JMX? If so, the source (the iterator) is
isolated from the reporting (i.e. aggregating)




                
> Create mechanism for user iterators to report problems
> ------------------------------------------------------
>
>                 Key: ACCUMULO-1366
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1366
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: tserver
>            Reporter: Josh Elser
>            Assignee: Keith Turner
>             Fix For: 1.6.0
>
>
> A common workflow for Accumulo iterators is a custom SortedKeyValueIterator which knows
certain logic on how to process a given table structure, e.g. when to skip to a new column,
what to aggregate, how to parse a Value, etc.
> One deficiency is that the only way for such a SKVI to report unexpected data found in
that table (sans killing the entire scan) is via a log message which will bubble up to the
monitor. This isn't the best as log messages on the monitor are not persistent, nor are they
guaranteed to actually alert anyone of problematic data found.
> It would be nice to have a mechanism for a SKVI to report a problem in a non-transient
manner. Having some general interface would be desirable as we could use multiple implementations:
the monitor, HTTP, mail, IRC/xmpp, etc.
> One easy implementation that may be low-hanging is re-using the "Table Problems" alerts
that Accumulo will log, typically when HDFS read/write operations fail. Persistence is definitely
a must. It would also be desirable to have something that can identify duplicate messages
and aggregate them together so as to not overwhelm the consumer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message