accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3036) 1.5 MiniCluster fails to start, forces clients to wait indefinitely
Date Fri, 19 Sep 2014 19:46:34 GMT

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

Josh Elser commented on ACCUMULO-3036:
--------------------------------------

Yeah, that's valid. I didn't come up with a good way to do this, so I had chucked it on my
backburner.

> 1.5 MiniCluster fails to start, forces clients to wait indefinitely
> -------------------------------------------------------------------
>
>                 Key: ACCUMULO-3036
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3036
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: mini
>    Affects Versions: 1.5.0, 1.5.1
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>             Fix For: 1.5.3
>
>
> Over in Pig land, a user was complaining about a test which used MiniAccumuloCluster
that hung until the JUnit timeout was hit.
> Eventually, the problem was diagnosed as a bad classpath (old version of Thrift was included
and used), which was causing the TServer and Master to immediately bail out. However, the
client sat indefinitely trying to connect unsuccessfully.
> MAC#start should not return before we're sure that the processes are actually up and
running (a very quick smoke test).
> It looks like ACCUMULO-1537 introduced a call to SetGoalState on the Master before MAC#start
returned which would (I assume) fail and then throw a RTE if the Master decided to die. Including
this fix in 1.5 may be sufficient to fix the underlying issue the user was seeing.



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

Mime
View raw message