Re: Interesting bug report

2016-01-26 Thread Keith Turner
On Mon, Jan 25, 2016 at 12:14 PM, Josh Elser 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

Re: Interesting bug report

2016-01-26 Thread Keith Turner
On Mon, Jan 25, 2016 at 10:59 AM, 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 > Thats a good idea. Should consider the use case when someone wants to

Re: Interesting bug report

2016-01-26 Thread John Vines
That sounds like great follow on work (clients register ephemerally so the master can tell clients to disconnect, etc.), but I think just having a client that can get a better read on the state of the system is a phenomenal starting point. On Tue, Jan 26, 2016 at 11:52 AM Keith Turner

Re: Interesting bug report

2016-01-25 Thread John Vines
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

Re: Interesting bug report

2016-01-25 Thread Josh Elser
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. John Vines wrote: Of course, it's when I hit send

Re: Interesting bug report

2016-01-25 Thread John Vines
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

Interesting bug report

2016-01-24 Thread Christopher
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