accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <>
Subject [jira] [Updated] (ACCUMULO-1188) Sandbox iterators
Date Wed, 17 Jul 2013 14:34:48 GMT


Keith Turner updated ACCUMULO-1188:

    Attachment: ACCUMULO-1188_fig1.png

I was thinking about how this could be done and had the following thoughts :

 * A tablet should advertise different ports for reading and writing, so that reader can go
directly to the process running scans.
 * The process running the scan should also contain the cache.

I attached fig 1 that shows the data flows I was thinking of.  I have also started to think
that we should not pursue this approach or running compactions and scans in separate processes.

I think that if ACCUMULO-1454 is implemented, that it may solve the problem this ticket is
trying to solve.  If an iterator gets stuck in an infinite loop ACCUMULO-1454 makes it possible
to restart the tserver and avoid disruption.  

I am thinking the following should be done.

 * Use ACCUMULO-1345 and ACCUMULO-1454 to restart tservers with stuck compactions/scans.
 * Need to blacklist tablets that repeatedly fail ACCUMULO-1570

Is there any reason to pursue this ticket if we restart tservers and blacklist tablets? Even
if we run user iterators in a separate process, we will still need to blacklist tablets and
restart those separate processes. The only thing its seems to help with is avoiding walog
recovery.  Are there other benefits?  

> Sandbox iterators
> -----------------
>                 Key: ACCUMULO-1188
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>            Reporter: Keith Turner
>             Fix For: 1.6.0
>         Attachments: ACCUMULO-1188_fig1.png
> It's possible that a user iterator can bring down a tablet server.  For example if it
has an OOM or creates too many threads.  It would be nice if iterators could be sandboxed
in some way.

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:

View raw message