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, 01 Aug 2014 15:50:38 GMT

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

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

SetGoalState is only modifying ZooKeeper -- That's not going to help.

The MAC impl has the root user/password. Is trying to instantiate a Connector with the root
user's credentials sufficient? That will communicate with a tserver, but not the Master. That
would at least be sufficient to catch the case of a bad classpath where all processes fail
to run.

> 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
>            Priority: Blocker
>             Fix For: 1.5.2
>
>
> 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.2#6252)

Mime
View raw message