You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Christopher Tubbs (JIRA)" <ji...@apache.org> on 2014/09/19 21:43:34 UTC

[jira] [Commented] (ACCUMULO-3036) 1.5 MiniCluster fails to start, forces clients to wait indefinitely

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

Christopher Tubbs commented on ACCUMULO-3036:
---------------------------------------------

This issue was marked as a blocker, but 1.5.2 was released without including it, so clearly, it's not a blocker.

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