Ok. Based on the discussion, it seems that doing infinite re-creation is
better. I will cancel the KIP.
Thanks,
Jun
On Thu, Nov 2, 2017 at 6:14 PM, Jeff Widman wrote:
> +1 for permanent retry under the covers (without an exposed/later
> deprecated config).
>
> That said, I understand the reali
+1 for permanent retry under the covers (without an exposed/later
deprecated config).
That said, I understand the reality that sometimes we have to workaround an
unfixed issue in another project, so if you think best to expose a config,
then I have no objections. Mainly I wanted to make sure you'd
The following JIRA provides some background on why upgrading immediately
following new release may not be prudent (though I expect this to be rare):
ZOOKEEPER-2347
On Thu, Nov 2, 2017 at 3:00 PM, Ted Yu wrote:
> Stephane:
> bq. hasn't acted in over a year
>
> The above fact implies some relucta
Stephane:
bq. hasn't acted in over a year
The above fact implies some reluctance from the zookeeper community to
fully solve the issue (maybe due to technical issues).
Anyway, we should plan on not relying on the fix to go through in the near
future.
As for Jun's latest suggestion, I think we sho
Hi Jun
I think this is a better option. Would that change require a kip then as
it's not a change in public API ?
@ted it was marked as a blocked for 3.4.11 but they pushed it. It seems
that the owner of the pr hasn't acted in over a year and I think someone
needs to take ownership of that. Addit
Stephane, Jeff,
Another option is to not expose the reconnect timeout config and just retry
the creation of Zookeeper forever. This is an improvement from the current
situation and if zookeeper-2184 is fixed in the future, we don't need to
deprecate the config.
Thanks,
Jun
On Thu, Nov 2, 2017 a
ZOOKEEPER-2184 is scheduled for 3.4.12 whose release is unknown.
I think adding the session recreation on Kafka side should benefit Kafka
users, especially those who don't plan to move to 3.4.12+ in the near
future.
On Wed, Nov 1, 2017 at 6:34 PM, Jun Rao wrote:
> Hi, Stephane,
>
> 3) The diffe
Thanks Jun for the clarification
It sounds like this kip is complementary to the zookeeper-2184 and can move
forward without it. We should still push hard for zookeeper-2184 to go
through (saw you commented on it earlier)
LGTM!
On 2 Nov. 2017 12:34 pm, "Jun Rao" wrote:
> Hi, Stephane,
>
> 3) T
Hi, Stephane,
3) The difference is that currently, there is no retry when re-creating the
Zookeeper object when a ZK session expires. So, if the re-creation of
Zookeeper fails, the broker just logs the error and the Zookeeper object
will never be created again. With this KIP, we will keep retrying
Fixing this in ZK won't be enough though. We'll need this included in a
stable release that we'll then bump Kafka's dependencies to include. I
doubt this KIP will be deprecated shortly even if the ZK bug is fixed
immediately.
On Tue, Oct 31, 2017 at 4:59 PM Jeff Widman wrote:
> Agree with Stepha
Agree with Stephane that it's worth at least taking a shot at trying to get
ZOOKEEPER-2184 fixed rather than adding a config that will be deprecated in
the not-too distant future.
I know Zookeeper development feels more like the turtle than the hare these
days, but Kafka is a high-visibility proje
Hi Jun,
Thanks for the reply.
1) The reason I'm asking about it is I wonder if it's not worth focusing the
development efforts on taking ownership of the existing PR
(https://github.com/apache/zookeeper/pull/150) to fix ZOOKEEPER-2184, rebase
it and have it merged into the ZK codebase shortly
Hi, Stephane,
Thanks for the reply.
1) Fixing the issue in ZK will be ideal. Not sure when it will happen
though. Once it's fixed, we can probably deprecate this config.
2) That could be useful. Is there a java api to do that at runtime? Also,
invalidating DNS cache doesn't always fix the issue
Hi Jun,
I think this is very helpful. Restarting Kafka brokers in case of zookeeper
host change is not a well known operation.
Few questions:
1) would it not be worth fixing the problem at the source ? This has been
stuck for a while though, maybe a little push would help :
https://issues.apache.
Hi, Everyone,
We created "KIP-217: Expose a timeout to allow an expired ZK session to be
re-created".
https://cwiki.apache.org/confluence/display/KAFKA/KIP-217%3A+Expose+a+timeout+to+allow+an+expired+ZK+session+to+be+re-created
Please take a look and provide your feedback.
Thanks,
Jun
15 matches
Mail list logo
