Turns out I am hitting a bug (as far as I can tell) that is fixed in
trunk:
http://svn.apache.org/viewvc/accumulo/trunk/server/src/main/java/org/apache/accumulo/server/Accumulo.java?r1=1437810&r2=1438335&diff_format=hI believe the prior code is trying to talk to Zookeeper before it
has called Accumulo.waitForZookeeperAndHdfs(). No?
Seems this was fixed for a totally different reason (ACCUMULO-928,
which doesn't talk about what I am talking about specifically)
and unknowingly addressed another bug.
On 2/27/2013 11:38 AM, Jeff Blaine wrote:
> On 2/27/2013 9:48 AM, Eric Newton wrote:
>> Sure, just create a ticket and submit a patch, if you're up to it.
>
> I'm not afraid of contributing here. I do elsewhere. Unfortunately,
> a patch + custom build for our project is not allowed. The effort
> requires unpatched 1.4.2, so I figured I'd ask.
>
> It looks like (after browsing the source a bit), I will have to
> figure out a workaround.
>
> If I'm feeling saucy and can make sense of it, I will try to
> follow up with a patch some day so that this is addressed for
> the next person. I'm not a Java developer, but do comprehend
> most of the basic code I've seen in the repo based on previous
> Java reading.
>
>> On Wed, Feb 27, 2013 at 9:38 AM, Jeff Blaine <[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>> wrote:
>>
>> We spin up our slaves first, then the Hadoop namenode + Accumulo
>> master afterward. By the time that comes up, tserver has exited
>> on the Accumulo slaves.
>>
>> Is there a way to increase the tserver effort for connection
>> to the master?
>>
>> Aside: is there really any reason for tserver to exit? Why not
>> just do an exponential backoff of connection attempts until
>> 30 seconds is hit, and then stay there infinitely?
>>
>>