[jira] [Commented] (HBASE-7055) port HBASE-6371 tier-based compaction from 0.89-fb to trunk - first slice (not configurable by cf or dynamically)

["stack (JIRA)" <ji...@apache.org>]

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

stack commented on HBASE-7055:
------------------------------

What sort of compaction does this new policy do?

Regards...

{code}
+    } catch (ClassNotFoundException e) {
+      throw new UnsupportedOperationException(
+          "Unable to find region server interface " + policyClassName, e);
+    } catch (IllegalAccessException e) {
+      throw new UnsupportedOperationException(
+          "Unable to access specified class " + policyClassName, e);
+    } catch (InstantiationException e) {
+      throw new UnsupportedOperationException(
+          "Unable to instantiate specified class " + policyClassName, e);
+    } catch (InvocationTargetException e) {
+      throw new UnsupportedOperationException(
+          "Unable to invoke specified target class constructor " + policyClassName, e);
+    } catch (NoSuchMethodException e) {
+      throw new UnsupportedOperationException(
+          "Unable to find suitable constructor for class " + policyClassName, e);
{code}

Just do catch (Exception e) once?

What is the min flush time about?

Should it be called TieredCompaction rather than TierCompaction?  E.G. in TierCompactionConfiguration

Is 'TierCompaction' the default as it says in the class comment: '+ * Control knobs for default compaction algorithm.'?

Why the break out of config for TierCompaction in particular?  Will we have to do this pattern for all we'd dynamically config: i.e. break out a Config class when we are already carrying a heavyweight Configuration anyways that is mostly accessible from anywhere?

I wonder who is going to take the time to do configuration on each compaction tier?  Is this asking a bit much of operators?

There is no class comment on TierCompactionPolicy, the place I'd go to learn about how TierCompactionPolicy works.

In the ascii diagram is tier 0 the first tier, the tier we first flush into?

Does this policy do anything about making it so leveldb-like, every file may contain all keys in the namespace: i.e. does it make it so a tier is made of files that each contain a distinct subset of the namespace?

I'm not sure how this stuff works, what it will give me after (admittedly skimming) the javadoc comments in the policy file.

Tests look good.
                
> port HBASE-6371 tier-based compaction from 0.89-fb to trunk - first slice (not configurable by cf or dynamically)
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-7055
>                 URL: https://issues.apache.org/jira/browse/HBASE-7055
>             Project: HBase
>          Issue Type: Task
>          Components: Compaction
>    Affects Versions: 0.96.0
>            Reporter: Sergey Shelukhin
>            Assignee: Sergey Shelukhin
>             Fix For: 0.96.0
>
>         Attachments: HBASE-6371-squashed.patch, HBASE-6371-v2-squashed.patch, HBASE-6371-v3-refactor-only-squashed.patch, HBASE-6371-v4-refactor-only-squashed.patch, HBASE-6371-v5-refactor-only-squashed.patch, HBASE-7055-v0.patch
>
>
> There's divergence in the code :(
> See HBASE-6371 for details.

--
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