Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Thu, 19 Feb 2015 20:25:11 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12769667.1422030494000.89198.1424377511785@Atlassian.JIRA>
In-Reply-To: <JIRA.12769667.1422030494000@Atlassian.JIRA>
References: <JIRA.12769667.1422030494000@Atlassian.JIRA>
 <JIRA.12769667.1422030494791@arcas>
Subject: [jira] [Commented] (ACCUMULO-3528) Bump the version of HTrace to
 3.1.0-incubating
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Josh Elser commented on ACCUMULO-3528:
--------------------------------------

Overall it makes sense. Track the newer htrace stuff, and versions of HDFS which also use the new htrace libs will automatically start showing up in Accumulo. It encourages use of newer versions of HDFS and, hopefully, reduces our burden. Getting HDFS spans in Accumulo isn't a requirement, just a nice to have.

Some quick observations:

{code}
+      SpanReceiverBuilder builder = new SpanReceiverBuilder(wrapHadoopConf(conf));
+      SpanReceiver rcvr = builder.spanReceiverClass(className.trim()).build();
+      if (rcvr == null) {
+        log.warn("Failed to load SpanReceiver " + className);
       }
+      receivers.add(rcvr);
+      log.info("SpanReceiver " + className + " was loaded successfully.");
     }
{code}

Looks like you want an else after the {{if (rcvr == null)}} if-statement. This will print that it failed to load the spanreceiver, and then that it loaded it.

{code}
   @Override
   public synchronized boolean offer(Runnable e) {
-    task.add((Comparable) e);
+    task.add((TraceRunnable) e);
     notify();
     return true;
   }
{code}

In {{CompactionQueue}}, maybe add a {{Precondition}} check instead of a blind cast? At least we can give a better error if we ever get a Runnable that wasn't a TraceRunnable?

I see in {{AsyncSpanReceiver}} and {{ZooTraceClient}} the {{configure(HTraceConfiguration)}} method has gone away. Was that nuked in o.a.htrace? The configure method was nice because it made the constructors do less "work" which typically makes it easier to test those classes with mocks.

> Bump the version of HTrace to 3.1.0-incubating
> ----------------------------------------------
>
>                 Key: ACCUMULO-3528
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3528
>             Project: Accumulo
>          Issue Type: Task
>          Components: trace
>            Reporter: Billie Rinaldi
>            Assignee: Billie Rinaldi
>             Fix For: 1.7.0
>
>         Attachments: ACCUMULO-3528.1.patch
>
>
> Now that htrace has an incubating release, 3.1.0-incubating, we could use that instead of 3.0.4.  This relates to HADOOP-11498.  The issue is that tracing will only connect through to HDFS when Accumulo and HDFS are using compatible versions of htrace, and the incubating release is not compatible with previous versions since apache has been added to the package names.
> See also HBASE-12810 for an example of upgrading htrace.  In addition to import changes, it looks like span receivers and samplers are constructed differently now.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)