Re: About ZooKeeper Dynamic Reconfiguration

2019-10-07 Thread Gao,Wei
Hi oo4load,
 Would you please sent me the active code of the implementation?
Thank you very much!



--
Sent from: http://zookeeper-user.578899.n2.nabble.com/


Re: About ZooKeeper Dynamic Reconfiguration

2019-10-07 Thread Gao,Wei
Hi oo4load,
 Would you please sent me the active code of the implementation?
Thank you very much!



--
Sent from: http://zookeeper-user.578899.n2.nabble.com/


Re: Removing Netty support from branch-3.4

2019-10-07 Thread Patrick Hunt
On Fri, Oct 4, 2019 at 9:14 AM Enrico Olivelli  wrote:

> The release branch 3.4 is frozen and we should cut new releases only for
> important security reasons or other important issues for users that cannot
> upgrade to 3.5.
>
> Given that 3.5 is now the suggested version and the upgrade path is simple
> I think there is no need to put effort into this activity.
>
> Is there any other valid reason for not using 3.4 + Netty in production ?
> We can advise users on the website that Netty 3 is old, and it is suggested
> to move do plain NIO or to ZK 3.5 client.
> Is the Netty dependency flagging us with security risks ?
>
>
We can explain that netty/3.4 whatever we like, the issue is 1) in the near
term we'll deal with reports such as when it's found through automated
means, easier is to just address it directly. 2) eventually there is likely
to be a real issue that can't be explained away, we would need to address
it directly in that case. Once 3.4 is officially "no longer supported" it
would be easier, but atm that's not the case. Perhaps we should document an
EOL for 3.4 to help address and close the loop more generally?

Patrick


> Il giorno ven 4 ott 2019 alle ore 10:52 Andor Molnar  ha
> scritto:
>
> > Hi ZK users / devs,
> >
> > ZooKeeper branch-3.4 is still on Netty 3 which is not maintained by the
> > Netty team anymore. There’s no intention of updating it on our side,
> hence
> > we’re planning to remove it from the codebase completely and ask existing
> > users to upgrade to 3.5, if they still want to use Netty. 3.5 is a much
> > better option anyway in various aspects: Netty 4 performs better, TLS
> > support in both quorum and client communication, etc.
> >
> > The default stack in 3.4 is NIO, so our gut feeling is that the impact on
> > our existing users is low, however the most important effect of this
> change
> > is probably the loss of encrypted client connections.
> >
> > Please share your thoughts about this change and let us know if upgrading
> > to 3.5 is not possible in your use case.
> >
> > Tracking Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-3568
> >
> > Regards,
> > Andor
> >
> >
> >
> >
>


Re: Experimental status of readonlymode feature

2019-10-07 Thread Norbert Kalmar
Hi Lewis,

I don't think the two is connected, so it's not only JVM flag because it's
experimental, it's just haven't been implemented to read this parameter
from config -experimental feature or not.
If you create an upstream ticket, create the PR if you want to contribute
(or just wait until someone implements it) it will be available in the next
release (3.5.x, not in 3.4).
I'm not aware of any rule that experimental features should not be
available from config.

As for why it is experimental. Honestly, I don't know. jute.maxbuffer is
also experimental, but it is widely used in production. This might worth a
question on the dev list.

Regards,
Norbert


On Fri, Oct 4, 2019 at 3:40 AM Lewis Gardner  wrote:

> Hi,
>
> The readonlymode feature was added 8 years ago but is still marked as
> experimental and requires setting a JVM system property to enable it.
>
> What steps are required to promote this feature to "fully supported"
> status
> and allow enablement via the "readonlymode.enabled" setting in zoo.cfg?
>
> thanks,
> Lewis
>