accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Miller (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Deleted] (ACCUMULO-4697) tablet server could kick off too many idle compactions
Date Fri, 01 Sep 2017 16:52:00 GMT

     [ https://issues.apache.org/jira/browse/ACCUMULO-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Miller updated ACCUMULO-4697:
-------------------------------------
    Comment: was deleted

(was: From [~elserj]:
This part of the code is meant to handle the case when the active master changes while there
data out to be replicated. The Master should initialize itself with the current state of ZooKeeper
to know what has already been assigned out for replication (by the previous active Master).

I can see that this bug would result in the Master holding onto some memory that it would
never free (in the Map), and it would result in the Master trying to submit it back out to
the cluster. However, I think eventually the Master (or TabletServer which took the work task)
would see that there is no more work to be done and eventually clean up the record.

I believe, by nature of the DistributedWorkQueue, there is sufficient exclusion to prevent
two TabletServers from concurrently trying to replicate the same WAL. However, I believe the
worst case would be that we inadvertently replicate the entire WAL twice.)

> tablet server could kick off too many idle compactions
> ------------------------------------------------------
>
>                 Key: ACCUMULO-4697
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4697
>             Project: Accumulo
>          Issue Type: Bug
>          Components: tserver
>            Reporter: Adam Fuchs
>            Priority: Minor
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Tablet.initiateMajorCompaction() always returns false, but we check the return value
when accounting for the number of idle major compactions started in TabletServer.MajorCompactor.run()
and continue to kick off idle compactions on every tablet.
> DefaultCompactionStrategy doesn't do anything special for idle compactions, so this will
only be an issue with a custom CompactionStrategy.
> My guess would be the best thing to do would be to get rid of idle compactions and get
rid of the return value on initiateMajorCompaction().



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message