accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
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


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

View raw message