You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by "evaristo.camarero@yahoo.es" <ev...@yahoo.es> on 2020/07/23 16:53:50 UTC
REOPEN CURATOR-538?
Hi there,
I propose to re-open Curator - 538
[CURATOR-538] Background exception was not retry-able or retry gave up - ASF JIRA
|
|
| |
[CURATOR-538] Background exception was not retry-able or retry gave up -...
|
|
|
I am experiencing the same issue (NPE) on a K8S deployment with Curator 4.3.0
Jordan, if I understand right your comment you are proposing to check if server.addr.getAddress() is null...
Currently with the NPE it is enough that a single server in the loop throws the NPE to prevent that the connectString is modified. I can provide a patch to avoid the NPE.
I see 2 options:
1.- Keep a compatible behavior, that with a single server.addr.getAddress() resolution to null the method return an empty string and therefore the connecstring will be unmodified (I can add a LOG warn statement).
2.- Another alternative is to continue the loop till the end ignoring servers that are resolved to null...
What do you think is best?
Regards,
/Chevaris
Re: REOPEN CURATOR-538?
Posted by "evaristo.camarero@yahoo.es" <ev...@yahoo.es>.
I was checking Release Notes for the last releases and there is no indication of any fix for 538
Maybe you are thinking in [CURATOR-568] New option allowing CuratorFramework skip ZK ensemble tracking - ASF JIRA
|
|
| |
[CURATOR-568] New option allowing CuratorFramework skip ZK ensemble trac...
|
|
|
Using option added in 568 will avoid the problem.
/Chevaris
En jueves, 23 de julio de 2020 19:38:24 CEST, Jordan Zimmerman <jo...@jordanzimmerman.com> escribió:
I could've sworn we addressed this as part of 5.0 - I'll do some research or maybe someone else can comment.
-JZ
On Jul 23, 2020, at 11:53 AM, evaristo.camarero@yahoo.es wrote:
Hi there,
I propose to re-open Curator - 538
[CURATOR-538] Background exception was not retry-able or retry gave up - ASF JIRA
|
|
| |
[CURATOR-538] Background exception was not retry-able or retry gave up -...
|
|
|
I am experiencing the same issue (NPE) on a K8S deployment with Curator 4.3.0
Jordan, if I understand right your comment you are proposing to check if server.addr.getAddress() is null...
Currently with the NPE it is enough that a single server in the loop throws the NPE to prevent that the connectString is modified. I can provide a patch to avoid the NPE.
I see 2 options:
1.- Keep a compatible behavior, that with a single server.addr.getAddress() resolution to null the method return an empty string and therefore the connecstring will be unmodified (I can add a LOG warn statement).
2.- Another alternative is to continue the loop till the end ignoring servers that are resolved to null...
What do you think is best?
Regards,
/Chevaris
Re: REOPEN CURATOR-538?
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I could've sworn we addressed this as part of 5.0 - I'll do some research or maybe someone else can comment.
-JZ
> On Jul 23, 2020, at 11:53 AM, evaristo.camarero@yahoo.es wrote:
>
> Hi there,
>
> I propose to re-open Curator - 538
>
> [CURATOR-538] Background exception was not retry-able or retry gave up - ASF JIRA <https://issues.apache.org/jira/browse/CURATOR-538>
>
> [CURATOR-538] Background exception was not retry-able or retry gave up -...
> <https://issues.apache.org/jira/browse/CURATOR-538>
>
>
> I am experiencing the same issue (NPE) on a K8S deployment with Curator 4.3.0
> Jordan, if I understand right your comment you are proposing to check if server.addr.getAddress() is null...
> Currently with the NPE it is enough that a single server in the loop throws the NPE to prevent that the connectString is modified. I can provide a patch to avoid the NPE.
> I see 2 options:
> 1.- Keep a compatible behavior, that with a single server.addr.getAddress() resolution to null the method return an empty string and therefore the connecstring will be unmodified (I can add a LOG warn statement).
> 2.- Another alternative is to continue the loop till the end ignoring servers that are resolved to null...
> What do you think is best?
> Regards,
> /Chevaris
>
>