You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Enrico Olivelli <eo...@gmail.com> on 2017/04/11 12:21:00 UTC
Re: Graceful close of ZooKeeper client
2017-02-17 15:59 GMT+01:00 Edward Ribeiro <ed...@gmail.com>:
> Hey Enrico,
>
> I suggest you to get in touch with Jordan Zimmerman (here on the list) to
> make sure your proposed change doesn't break backwards compatibility.
> Jordan is creator of Curator, the best ZK lib out there, and an active
> member on this list.
>
>
Edward,
I'm back after some month running in production.
My final proposal is to leave the ZooKeeper#close method as it is
currently, because many times there is a need to fast close the ZK handle
without waiting.
I had some production cases in which in order to react to a session
expiration the clients needs to open a new ZK handle and tries to close the
previous one, but the delay introduced a lot of bugs.
I have introduced a new close(int maxWaitTime) which waits for the graceful
shutdown and it is very useful in two cases:
- webapps with reloading (so that the contextDestroyed callbacks need to
wait for a perfect cleanup of the env)
- unit tests cases (enables to run tests in a more predicatable way)
The new method will not introduce any compatibility issue, even with
Curator; maybe @Jordan can you confirm that ?
I can update the JIRA and submit a PR to share my patch, I really would
like to have this small feature in 3.5.x branch
Does it sound good to you ?
> Cheers,
> Eddie
>
> On Thu, Feb 16, 2017 at 2:14 PM, Enrico Olivelli <eo...@gmail.com>
> wrote:
>
> > Hi ZooKeepers,
> > I have just created this and issue to improve client-side "close"
> >
> > https://issues.apache.org/jira/browse/ZOOKEEPER-2697 Handle graceful
> stop
> > of ZookKeeper client
> >
> > If the idea is acceptable for you I can write a patch and file a PR.
> >
> > Thanks
> > -- Enrico
> >
>
Re: Graceful close of ZooKeeper client
Posted by Enrico Olivelli <eo...@gmail.com>.
2017-04-11 15:13 GMT+02:00 Jordan Zimmerman <jo...@jordanzimmerman.com>:
> > The new method will not introduce any compatibility issue, even with
> > Curator; maybe @Jordan can you confirm that ?
>
> If it's a new method then there's no Curator compatibility issues. Though,
> we'd appreciate a PR adding support for this in Curator :D
>
> -JZ
Great!
This is the PR for the ZooKeeper trunk
https://github.com/apache/zookeeper/pull/222
this is the JIRA
https://issues.apache.org/jira/browse/ZOOKEEPER-2697
I will appreciate any committer to take a look and maybe check wheather it
could be included in 3.5.X branch and not only in 3.6
Jordan,
maybe I will send an email to Curator dev list for a proposal
Thank you
Re: Graceful close of ZooKeeper client
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
> The new method will not introduce any compatibility issue, even with
> Curator; maybe @Jordan can you confirm that ?
If it's a new method then there's no Curator compatibility issues. Though, we'd appreciate a PR adding support for this in Curator :D
-JZ
Re: Graceful close of ZooKeeper client
Posted by Edward Ribeiro <ed...@gmail.com>.
Yup, it sounds great. :)
PS: btw, congrats on new BK committer status.
Em 11 de abr de 2017 9:21 AM, "Enrico Olivelli" <eo...@gmail.com>
escreveu:
2017-02-17 15:59 GMT+01:00 Edward Ribeiro <ed...@gmail.com>:
> Hey Enrico,
>
> I suggest you to get in touch with Jordan Zimmerman (here on the list) to
> make sure your proposed change doesn't break backwards compatibility.
> Jordan is creator of Curator, the best ZK lib out there, and an active
> member on this list.
>
>
Edward,
I'm back after some month running in production.
My final proposal is to leave the ZooKeeper#close method as it is
currently, because many times there is a need to fast close the ZK handle
without waiting.
I had some production cases in which in order to react to a session
expiration the clients needs to open a new ZK handle and tries to close the
previous one, but the delay introduced a lot of bugs.
I have introduced a new close(int maxWaitTime) which waits for the graceful
shutdown and it is very useful in two cases:
- webapps with reloading (so that the contextDestroyed callbacks need to
wait for a perfect cleanup of the env)
- unit tests cases (enables to run tests in a more predicatable way)
The new method will not introduce any compatibility issue, even with
Curator; maybe @Jordan can you confirm that ?
I can update the JIRA and submit a PR to share my patch, I really would
like to have this small feature in 3.5.x branch
Does it sound good to you ?
> Cheers,
> Eddie
>
> On Thu, Feb 16, 2017 at 2:14 PM, Enrico Olivelli <eo...@gmail.com>
> wrote:
>
> > Hi ZooKeepers,
> > I have just created this and issue to improve client-side "close"
> >
> > https://issues.apache.org/jira/browse/ZOOKEEPER-2697 Handle graceful
> stop
> > of ZookKeeper client
> >
> > If the idea is acceptable for you I can write a patch and file a PR.
> >
> > Thanks
> > -- Enrico
> >
>