Re: [DISCUSS] On HBase client retries (NIFI-6197)

I'm not sure either. I agree that 35 is too high, the 2.x++ default of 15 seems reasonable to me. We might be able to include a connection check API in the future but that won't help us now so we need to find some way forward. I believe we have different "services" in NiFi for HBase 1 & 2. How ab

Re: [DISCUSS] On HBase client retries (NIFI-6197)

So, do we have a real issue here? Or are we just overlapping two discussions about the same code-change with different context? My impression from Bryan is, now that he has the bigger context of why implicit retries are important for HBase, that he is not against setting this value higher (alt

Re: [DISCUSS] On HBase client retries (NIFI-6197)

That's what I suggested[1] and Bryan rejected[2] [1] [2] On Wed, Feb 19, 2020 at 4:29 PM Josh Elser wrote: > Thanks for sharing the code, Bryan! I lazily did not

Re: [DISCUSS] On HBase client retries (NIFI-6197)

Thanks for sharing the code, Bryan! I lazily did not go digging. Looking into #onEnabled, we could change this to create its own Connection with a very low 1 or 2 retries with a very short retry duration. Throw that one away after we did our sanity check, set a high retry amount, and then crea

Re: [DISCUSS] On HBase client retries (NIFI-6197)

We do already expose the ability to configure the retries in the controller service [1], it was just a debate about what the default value should be. Currently it is set to 1 because we believed it was better to fail fast during the initial configuration of the service. A user can easily set it bac

Re: [DISCUSS] On HBase client retries (NIFI-6197)

We could certainly implement some kind of "sanity check" via HBase code, but I think the thing that is missing is the logical way to validate this in NiFi itself. Something like... ``` Configuration conf = HBaseConfiguration.create(); conf.setInt("hbase.rpc.timeout", 5000); try (Connection con

Re: [DISCUSS] On HBase client retries (NIFI-6197)

Hi, Josh, thanks for bringing it up here again. I'm happy to revive the PR with whatever the outcome of this thread is. It came up today because another client complained about how "unstable" HBase is on NiFi. @Josh: As the whole issue is only the initial connect can we have a different timeout s

Re: [DISCUSS] On HBase client retries (NIFI-6197)

Good point, I don't think we can do that on a controller service. Le mar. 18 févr. 2020 à 11:06, Bryan Bende a écrit : > That could make it a little better, but I can't remember, can we > terminate on a controller service? > > The issue here would be on first time enabling the the HBase client >

Re: [DISCUSS] On HBase client retries (NIFI-6197)

That could make it a little better, but I can't remember, can we terminate on a controller service? The issue here would be on first time enabling the the HBase client service, so before even getting to a processor. On Tue, Feb 18, 2020 at 2:00 PM Pierre Villard wrote: > > Bryan, > > I didn't fo

Re: [DISCUSS] On HBase client retries (NIFI-6197)

Bryan, I didn't follow the whole discussion so I apologize if I'm saying something stupid here. Now that we have the possibility to terminate threads in a processor, would that solve the issue? Pierre Le mar. 18 févr. 2020 à 10:52, Bryan Bende a écrit : > Hi Josh, > > The problem isn't so much

Re: [DISCUSS] On HBase client retries (NIFI-6197)

Hi Josh, The problem isn't so much about the retries within the flow, its more about setting up the service for the first time. A common scenario for users was the following: - Create a new HBase client service - Enter some config that wasn't quite correct, possibly hostnames that weren't reacha

[DISCUSS] On HBase client retries (NIFI-6197)

Hiya! LarsF brought this up in the apache-hbase slack account and it caught my eye. Sending a note here since the PR is closed where this was being discussed before[1]. I understand Bryan's concerns that misconfiguration of an HBase processor with a high number of retries and back-off can cr