[
https://issues.apache.org/jira/browse/ACCUMULO-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268661#comment-13268661
]
Keith Turner commented on ACCUMULO-577:
---------------------------------------
An option for the scanner to disable iterators would also be nice. If the user
sees their iterator failing for certain queries, they can disable server side
iterators and run the iterators on the client side to debug. This way
iterators do not need to be disabled across the table for an edge case in the
data possibly impacting operations. The client side iterator scanner can be
used to run iterators on the client side.
This would also be useful for testing changes to iterators. If you have
iterators deployed on a production system, then you can disable them for a scan
and test the new version on the client side.
> Allow option for ignoring repeatedly failed iterators during compaction
> -----------------------------------------------------------------------
>
> Key: ACCUMULO-577
> URL: https://issues.apache.org/jira/browse/ACCUMULO-577
> Project: Accumulo
> Issue Type: Improvement
> Components: tserver
> Affects Versions: 1.5.0, 1.4.0
> Reporter: John Vines
> Assignee: Keith Turner
>
> Currently when an iterator is causing errors, either stemming from the
> iterator configuration or from instantiating, it will endlessy try over and
> over again. I think we should provide a table configuration to allow eventual
> fail over for these circumstances. I think in these circumstances all user
> configured iterators (including versioning) should be disabled to ensure the
> data is written (or rewritten) and once the configuration is fixed, then the
> next major compaction will sort it all out.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
