Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: <56A6580D.3040401@gmail.com>
References: 
 <CAL5zq9bK+WCSWXc404J6OcV07oiO8KMR5+zjNEXJ1ACT0LDJUA@mail.gmail.com>
	<CADczPYTDsCwPvox4c3i5jm+ovWJSfL25si1nNUOxkWtATr+R7Q@mail.gmail.com>
	<CADczPYSfAAQrvGVdWju7rH9RmWazUWj=deoFD6kujTGz9_SbAw@mail.gmail.com>
	<56A6580D.3040401@gmail.com>
Date: Tue, 26 Jan 2016 11:45:57 -0500
Message-ID: 
 <CAGUtCHqs9h4Fe9hcv67CD4V8CrQfqY94pXMgjjmK2wnFS3p-8A@mail.gmail.com>
Subject: Re: Interesting bug report
From: Keith Turner <keith@deenlo.com>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=047d7b3a86806b980c052a3f6b6e

--047d7b3a86806b980c052a3f6b6e
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 25, 2016 at 12:14 PM, Josh Elser <josh.elser@gmail.com> wrote:

> I've long be waffling about the usefulness of our "infinite retry" logic.
> It's great for daemons. It sucks for humans.
>
> Maybe there's a story in addressing this via ClientConfiguration -- let
> the user tell us the policy they want to follow.


+1 for configurable retry policy.    Curator has a configurable retry
policy.  Would be good to see how it works when designing something for
Accumulo.


>
>
> John Vines wrote:
>
>> Of course, it's when I hit send that I realize that we could mitigate by
>> making the client aware of the master state, and if the system is shut
>> down
>> (which was the case for that ticket), then it can fail quickly with a
>> descriptive message.
>>
>> On Mon, Jan 25, 2016 at 10:58 AM John Vines<vines@apache.org>  wrote:
>>
>> While we want to be fault tolerant, there's a point where we want to
>>> eventually fail. I know we have a couple never ending retry loops that
>>> need
>>> to be addressed (https://issues.apache.org/jira/browse/ACCUMULO-1268),
>>> but I'm unsure if queries suffer from this problem.
>>>
>>> Unfortunately, fault tolerance is a bit at odds with instant notification
>>> of system issues, since some of the fault tolerance is temporally
>>> oriented.
>>> And that ticket lacks context of it never failing out vs. failing out
>>> eventually (but too long for the user)
>>>
>>>
>>> On Sun, Jan 24, 2016 at 7:46 PM Christopher<ctubbsii@apache.org>  wrote:
>>>
>>> I saw this bug report:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1300987
>>>>
>>>> As far as I can tell, they are reporting normal, expected, and desired
>>>> behavior of Accumulo as a bug. But, is there something we can do
>>>> upstream
>>>> to enable fast failures in the case of Accumulo not running to support
>>>> their use case?
>>>>
>>>> Personally, I don't see how we can reliably detect within the client
>>>> that
>>>> the cluster is down or up, vs. a normal temporary server
>>>> outage/migration,
>>>> since there is there is no single point of authority for Accumulo to
>>>> determine its overall operating status if ZooKeeper is running and no
>>>> other
>>>> servers are. Am I wrong?
>>>>
>>>>
>>

--047d7b3a86806b980c052a3f6b6e--