You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by Rakesh R <ra...@huawei.com> on 2014/03/17 11:28:03 UTC
Upgrade ZK version in BK
Hi All,
Presently BK is using ZK-3.4.3 version which I feel is quite old one. While bumping the version to ZK-3.4.6, I've noticed one small diff about the netty versions.
ZK has netty version - 3.7.0
BK has netty version - 3.2.9
As part of ZOOKEEPER-1715, it has upgraded the netty version to 3.7.0
<dependency org="io.netty" name="netty" conf="default" rev="3.7.0.Final">
But in BK we have different version 3.2.9
<dependency>
<groupId>org.jboss.netty</groupId>
<artifactId>netty</artifactId>
<version>3.2.9.Final</version>
<scope>compile</scope>
</dependency>
Following are few ideas that comes in my mind, which I'm putting to kick start the discussion.
Approach-1) Since BK is not using ZooKeeper's netty feature, it can simply exclude the netty library while adding ZK-3.4.6 dependency and BK will continue using his own version.
Approach-2) BK also will upgrade its netty version to '3.7.0' and be in sync with ZK-3.4.6. Here it would need to see old - new BK communications.
Appreciate any help in finding a better way. Also welcome fresh ideas:)
Thanks & Regards,
Rakesh R
Re: Upgrade ZK version in BK
Posted by Sijie Guo <gu...@gmail.com>.
On Tuesday, March 25, 2014, Sijie Guo <gu...@gmail.com> wrote:
>
>
> On Monday, March 24, 2014, Rakesh R <rakeshr@huawei.com<javascript:_e(%7B%7D,'cvml','rakeshr@huawei.com');>>
> wrote:
>
>> Thanks everyone for the reply.
>>
>> >> We do use ClientSocketChannelFactory.
>> Would it be possible to deprecate this usage ? Anyway this would be
>> handled gracefully when we shade netty library in future.
>
>
> No. We should deprecate this. As it allows sharing resources between
> clients and applications. That is also the reason I don't like shading.
>
Sorry. "should deprecate" -> "should not deprecate"
>
>
>> >> As I said before, we are close to 4.3.0, let's not bump any version at
>> last minute, unless there is critical bugs need to fix.
>> >> We could bump zk and Netty versions in next release.
>>
>> Thats fine.
>>
>> -Rakesh
>>
>> -----Original Message-----
>> From: Sijie Guo [mailto:guosijie@gmail.com]
>> Sent: 24 March 2014 08:31
>> To: bookkeeper-dev@zookeeper.apache.org
>> Cc: bookkeeper-user@zookeeper.apache.org
>> Subject: Re: Upgrade ZK version in BK
>>
>> On Thursday, March 20, 2014, Ivan Kelly <iv...@apache.org> wrote:
>>
>> > My take on this is actually that we should shade this also.
>> >
>> > [1] contains netty's policy on versioning. If we upgrade to 3.7.0 we
>> > force anyone using bookkeeper to upgrade also. As [1] says, the
>> > changes may not be binary compatible. I've actually experienced this
>> > problem with netty recently, though I think it was between major
>> > versions. In any case though, if binary incompatible can happen, we
>> > shouldn't break anyone by having them use us.
>> >
>> > However, shading would involve a source compat break for us, as one of
>> > the constructors for BookKeeper takes a ClientSocketChannelFactory. My
>> > vote on this, is to break this constructor for 3.4.0 release, upgrade
>> > netty and shade it. I really doubt anyone is using the constructor
>> > with ClientSocketChannelFactory.
>>
>>
>> We do use ClientSocketChannelFactory.
>>
>>
>>
>> > Also, for 3.4.0, we should split out
>> > the client package into a separate module to avoid pulling in too many
>> > modules. It's not a huge amount of work. I think I did it in 45
>> > minutes before, but it needs to be done when there's very little
>> > outstanding work, and files move around a lot.
>> >
>> > Sijie, what do you think? You've been opposed to shading in the past.
>>
>>
>> As I said before, we are close to 4.3.0, let's not bump any version at
>> last minute, unless there is critical bugs need to fix.
>> We could bump zk and Netty versions in next release.
>>
>>
>> >
>> > -Ivan
>> >
>> >
>> >
>> > > Presently BK is using ZK-3.4.3 version which I feel is quite old one.
>> > While bumping the version to ZK-3.4.6, I've noticed one small diff
>> > about the netty versions.
>> > >
>> > > ZK has netty version - 3.7.0
>> > > BK has netty version - 3.2.9
>> > >
>> > > As part of ZOOKEEPER-1715, it has upgraded the netty version to
>> > > 3.7.0 <dependency org="io.netty" name="netty" conf="default"
>> > > rev="3.7.0.Final">
>> > >
>> > > But in BK we have different version 3.2.9
>> > > <dependency>
>> > > <groupId>org.jboss.netty</groupId>
>> > > <artifactId>netty</artifactId>
>> > > <version>3.2.9.Final</version>
>> > > <scope>compile</scope>
>> > > </dependency>
>> > >
>> > >
>> > > Following are few ideas that comes in my mind, which I'm putting to
>> > > kick
>> > start the discussion.
>> > >
>> > > Approach-1) Since BK is not using ZooKeeper's netty feature, it can
>> > > simply exclude the netty library while adding ZK-3.4.6 dependency
>> > > and BK will continue using his own version.
>> > BK uses the zk client which does use netty.
>> >
>> > > Approach-2) BK also will upgrade its netty version to '3.7.0' and be
>> > > in sync with ZK-3.4.6. Here it would need to see old - new BK
>> > > communications.
>> >
>> > >
>> > > Appreciate any help in finding a better way. Also welcome fresh
>> > > ideas:)
>> > >
>> > > Thanks & Regards,
>> > > Rakesh R
>> > >
>> > [1] http://netty.io/news/2013/08/27/semantic-versioning.html
>> >
>>
>
Re: Upgrade ZK version in BK
Posted by Sijie Guo <gu...@gmail.com>.
On Tuesday, March 25, 2014, Sijie Guo <gu...@gmail.com> wrote:
>
>
> On Monday, March 24, 2014, Rakesh R <rakeshr@huawei.com<javascript:_e(%7B%7D,'cvml','rakeshr@huawei.com');>>
> wrote:
>
>> Thanks everyone for the reply.
>>
>> >> We do use ClientSocketChannelFactory.
>> Would it be possible to deprecate this usage ? Anyway this would be
>> handled gracefully when we shade netty library in future.
>
>
> No. We should deprecate this. As it allows sharing resources between
> clients and applications. That is also the reason I don't like shading.
>
Sorry. "should deprecate" -> "should not deprecate"
>
>
>> >> As I said before, we are close to 4.3.0, let's not bump any version at
>> last minute, unless there is critical bugs need to fix.
>> >> We could bump zk and Netty versions in next release.
>>
>> Thats fine.
>>
>> -Rakesh
>>
>> -----Original Message-----
>> From: Sijie Guo [mailto:guosijie@gmail.com]
>> Sent: 24 March 2014 08:31
>> To: bookkeeper-dev@zookeeper.apache.org
>> Cc: bookkeeper-user@zookeeper.apache.org
>> Subject: Re: Upgrade ZK version in BK
>>
>> On Thursday, March 20, 2014, Ivan Kelly <iv...@apache.org> wrote:
>>
>> > My take on this is actually that we should shade this also.
>> >
>> > [1] contains netty's policy on versioning. If we upgrade to 3.7.0 we
>> > force anyone using bookkeeper to upgrade also. As [1] says, the
>> > changes may not be binary compatible. I've actually experienced this
>> > problem with netty recently, though I think it was between major
>> > versions. In any case though, if binary incompatible can happen, we
>> > shouldn't break anyone by having them use us.
>> >
>> > However, shading would involve a source compat break for us, as one of
>> > the constructors for BookKeeper takes a ClientSocketChannelFactory. My
>> > vote on this, is to break this constructor for 3.4.0 release, upgrade
>> > netty and shade it. I really doubt anyone is using the constructor
>> > with ClientSocketChannelFactory.
>>
>>
>> We do use ClientSocketChannelFactory.
>>
>>
>>
>> > Also, for 3.4.0, we should split out
>> > the client package into a separate module to avoid pulling in too many
>> > modules. It's not a huge amount of work. I think I did it in 45
>> > minutes before, but it needs to be done when there's very little
>> > outstanding work, and files move around a lot.
>> >
>> > Sijie, what do you think? You've been opposed to shading in the past.
>>
>>
>> As I said before, we are close to 4.3.0, let's not bump any version at
>> last minute, unless there is critical bugs need to fix.
>> We could bump zk and Netty versions in next release.
>>
>>
>> >
>> > -Ivan
>> >
>> >
>> >
>> > > Presently BK is using ZK-3.4.3 version which I feel is quite old one.
>> > While bumping the version to ZK-3.4.6, I've noticed one small diff
>> > about the netty versions.
>> > >
>> > > ZK has netty version - 3.7.0
>> > > BK has netty version - 3.2.9
>> > >
>> > > As part of ZOOKEEPER-1715, it has upgraded the netty version to
>> > > 3.7.0 <dependency org="io.netty" name="netty" conf="default"
>> > > rev="3.7.0.Final">
>> > >
>> > > But in BK we have different version 3.2.9
>> > > <dependency>
>> > > <groupId>org.jboss.netty</groupId>
>> > > <artifactId>netty</artifactId>
>> > > <version>3.2.9.Final</version>
>> > > <scope>compile</scope>
>> > > </dependency>
>> > >
>> > >
>> > > Following are few ideas that comes in my mind, which I'm putting to
>> > > kick
>> > start the discussion.
>> > >
>> > > Approach-1) Since BK is not using ZooKeeper's netty feature, it can
>> > > simply exclude the netty library while adding ZK-3.4.6 dependency
>> > > and BK will continue using his own version.
>> > BK uses the zk client which does use netty.
>> >
>> > > Approach-2) BK also will upgrade its netty version to '3.7.0' and be
>> > > in sync with ZK-3.4.6. Here it would need to see old - new BK
>> > > communications.
>> >
>> > >
>> > > Appreciate any help in finding a better way. Also welcome fresh
>> > > ideas:)
>> > >
>> > > Thanks & Regards,
>> > > Rakesh R
>> > >
>> > [1] http://netty.io/news/2013/08/27/semantic-versioning.html
>> >
>>
>
Re: Upgrade ZK version in BK
Posted by Sijie Guo <gu...@gmail.com>.
On Monday, March 24, 2014, Rakesh R <ra...@huawei.com> wrote:
> Thanks everyone for the reply.
>
> >> We do use ClientSocketChannelFactory.
> Would it be possible to deprecate this usage ? Anyway this would be
> handled gracefully when we shade netty library in future.
No. We should deprecate this. As it allows sharing resources between
clients and applications. That is also the reason I don't like shading.
> >> As I said before, we are close to 4.3.0, let's not bump any version at
> last minute, unless there is critical bugs need to fix.
> >> We could bump zk and Netty versions in next release.
>
> Thats fine.
>
> -Rakesh
>
> -----Original Message-----
> From: Sijie Guo [mailto:guosijie@gmail.com <javascript:;>]
> Sent: 24 March 2014 08:31
> To: bookkeeper-dev@zookeeper.apache.org <javascript:;>
> Cc: bookkeeper-user@zookeeper.apache.org <javascript:;>
> Subject: Re: Upgrade ZK version in BK
>
> On Thursday, March 20, 2014, Ivan Kelly <ivank@apache.org <javascript:;>>
> wrote:
>
> > My take on this is actually that we should shade this also.
> >
> > [1] contains netty's policy on versioning. If we upgrade to 3.7.0 we
> > force anyone using bookkeeper to upgrade also. As [1] says, the
> > changes may not be binary compatible. I've actually experienced this
> > problem with netty recently, though I think it was between major
> > versions. In any case though, if binary incompatible can happen, we
> > shouldn't break anyone by having them use us.
> >
> > However, shading would involve a source compat break for us, as one of
> > the constructors for BookKeeper takes a ClientSocketChannelFactory. My
> > vote on this, is to break this constructor for 3.4.0 release, upgrade
> > netty and shade it. I really doubt anyone is using the constructor
> > with ClientSocketChannelFactory.
>
>
> We do use ClientSocketChannelFactory.
>
>
>
> > Also, for 3.4.0, we should split out
> > the client package into a separate module to avoid pulling in too many
> > modules. It's not a huge amount of work. I think I did it in 45
> > minutes before, but it needs to be done when there's very little
> > outstanding work, and files move around a lot.
> >
> > Sijie, what do you think? You've been opposed to shading in the past.
>
>
> As I said before, we are close to 4.3.0, let's not bump any version at
> last minute, unless there is critical bugs need to fix.
> We could bump zk and Netty versions in next release.
>
>
> >
> > -Ivan
> >
> >
> >
> > > Presently BK is using ZK-3.4.3 version which I feel is quite old one.
> > While bumping the version to ZK-3.4.6, I've noticed one small diff
> > about the netty versions.
> > >
> > > ZK has netty version - 3.7.0
> > > BK has netty version - 3.2.9
> > >
> > > As part of ZOOKEEPER-1715, it has upgraded the netty version to
> > > 3.7.0 <dependency org="io.netty" name="netty" conf="default"
> > > rev="3.7.0.Final">
> > >
> > > But in BK we have different version 3.2.9
> > > <dependency>
> > > <groupId>org.jboss.netty</groupId>
> > > <artifactId>netty</artifactId>
> > > <version>3.2.9.Final</version>
> > > <scope>compile</scope>
> > > </dependency>
> > >
> > >
> > > Following are few ideas that comes in my mind, which I'm putting to
> > > kick
> > start the discussion.
> > >
> > > Approach-1) Since BK is not using ZooKeeper's netty feature, it can
> > > simply exclude the netty library while adding ZK-3.4.6 dependency
> > > and BK will continue using his own version.
> > BK uses the zk client which does use netty.
> >
> > > Approach-2) BK also will upgrade its netty version to '3.7.0' and be
> > > in sync with ZK-3.4.6. Here it would need to see old - new BK
> > > communications.
> >
> > >
> > > Appreciate any help in finding a better way. Also welcome fresh
> > > ideas:)
> > >
> > > Thanks & Regards,
> > > Rakesh R
> > >
> > [1] http://netty.io/news/2013/08/27/semantic-versioning.html
> >
>
Re: Upgrade ZK version in BK
Posted by Sijie Guo <gu...@gmail.com>.
On Monday, March 24, 2014, Rakesh R <ra...@huawei.com> wrote:
> Thanks everyone for the reply.
>
> >> We do use ClientSocketChannelFactory.
> Would it be possible to deprecate this usage ? Anyway this would be
> handled gracefully when we shade netty library in future.
No. We should deprecate this. As it allows sharing resources between
clients and applications. That is also the reason I don't like shading.
> >> As I said before, we are close to 4.3.0, let's not bump any version at
> last minute, unless there is critical bugs need to fix.
> >> We could bump zk and Netty versions in next release.
>
> Thats fine.
>
> -Rakesh
>
> -----Original Message-----
> From: Sijie Guo [mailto:guosijie@gmail.com <javascript:;>]
> Sent: 24 March 2014 08:31
> To: bookkeeper-dev@zookeeper.apache.org <javascript:;>
> Cc: bookkeeper-user@zookeeper.apache.org <javascript:;>
> Subject: Re: Upgrade ZK version in BK
>
> On Thursday, March 20, 2014, Ivan Kelly <ivank@apache.org <javascript:;>>
> wrote:
>
> > My take on this is actually that we should shade this also.
> >
> > [1] contains netty's policy on versioning. If we upgrade to 3.7.0 we
> > force anyone using bookkeeper to upgrade also. As [1] says, the
> > changes may not be binary compatible. I've actually experienced this
> > problem with netty recently, though I think it was between major
> > versions. In any case though, if binary incompatible can happen, we
> > shouldn't break anyone by having them use us.
> >
> > However, shading would involve a source compat break for us, as one of
> > the constructors for BookKeeper takes a ClientSocketChannelFactory. My
> > vote on this, is to break this constructor for 3.4.0 release, upgrade
> > netty and shade it. I really doubt anyone is using the constructor
> > with ClientSocketChannelFactory.
>
>
> We do use ClientSocketChannelFactory.
>
>
>
> > Also, for 3.4.0, we should split out
> > the client package into a separate module to avoid pulling in too many
> > modules. It's not a huge amount of work. I think I did it in 45
> > minutes before, but it needs to be done when there's very little
> > outstanding work, and files move around a lot.
> >
> > Sijie, what do you think? You've been opposed to shading in the past.
>
>
> As I said before, we are close to 4.3.0, let's not bump any version at
> last minute, unless there is critical bugs need to fix.
> We could bump zk and Netty versions in next release.
>
>
> >
> > -Ivan
> >
> >
> >
> > > Presently BK is using ZK-3.4.3 version which I feel is quite old one.
> > While bumping the version to ZK-3.4.6, I've noticed one small diff
> > about the netty versions.
> > >
> > > ZK has netty version - 3.7.0
> > > BK has netty version - 3.2.9
> > >
> > > As part of ZOOKEEPER-1715, it has upgraded the netty version to
> > > 3.7.0 <dependency org="io.netty" name="netty" conf="default"
> > > rev="3.7.0.Final">
> > >
> > > But in BK we have different version 3.2.9
> > > <dependency>
> > > <groupId>org.jboss.netty</groupId>
> > > <artifactId>netty</artifactId>
> > > <version>3.2.9.Final</version>
> > > <scope>compile</scope>
> > > </dependency>
> > >
> > >
> > > Following are few ideas that comes in my mind, which I'm putting to
> > > kick
> > start the discussion.
> > >
> > > Approach-1) Since BK is not using ZooKeeper's netty feature, it can
> > > simply exclude the netty library while adding ZK-3.4.6 dependency
> > > and BK will continue using his own version.
> > BK uses the zk client which does use netty.
> >
> > > Approach-2) BK also will upgrade its netty version to '3.7.0' and be
> > > in sync with ZK-3.4.6. Here it would need to see old - new BK
> > > communications.
> >
> > >
> > > Appreciate any help in finding a better way. Also welcome fresh
> > > ideas:)
> > >
> > > Thanks & Regards,
> > > Rakesh R
> > >
> > [1] http://netty.io/news/2013/08/27/semantic-versioning.html
> >
>
RE: Upgrade ZK version in BK
Posted by Rakesh R <ra...@huawei.com>.
Thanks everyone for the reply.
>> We do use ClientSocketChannelFactory.
Would it be possible to deprecate this usage ? Anyway this would be handled gracefully when we shade netty library in future.
>> As I said before, we are close to 4.3.0, let's not bump any version at last minute, unless there is critical bugs need to fix.
>> We could bump zk and Netty versions in next release.
Thats fine.
-Rakesh
-----Original Message-----
From: Sijie Guo [mailto:guosijie@gmail.com]
Sent: 24 March 2014 08:31
To: bookkeeper-dev@zookeeper.apache.org
Cc: bookkeeper-user@zookeeper.apache.org
Subject: Re: Upgrade ZK version in BK
On Thursday, March 20, 2014, Ivan Kelly <iv...@apache.org> wrote:
> My take on this is actually that we should shade this also.
>
> [1] contains netty's policy on versioning. If we upgrade to 3.7.0 we
> force anyone using bookkeeper to upgrade also. As [1] says, the
> changes may not be binary compatible. I've actually experienced this
> problem with netty recently, though I think it was between major
> versions. In any case though, if binary incompatible can happen, we
> shouldn't break anyone by having them use us.
>
> However, shading would involve a source compat break for us, as one of
> the constructors for BookKeeper takes a ClientSocketChannelFactory. My
> vote on this, is to break this constructor for 3.4.0 release, upgrade
> netty and shade it. I really doubt anyone is using the constructor
> with ClientSocketChannelFactory.
We do use ClientSocketChannelFactory.
> Also, for 3.4.0, we should split out
> the client package into a separate module to avoid pulling in too many
> modules. It's not a huge amount of work. I think I did it in 45
> minutes before, but it needs to be done when there's very little
> outstanding work, and files move around a lot.
>
> Sijie, what do you think? You've been opposed to shading in the past.
As I said before, we are close to 4.3.0, let's not bump any version at last minute, unless there is critical bugs need to fix.
We could bump zk and Netty versions in next release.
>
> -Ivan
>
>
>
> > Presently BK is using ZK-3.4.3 version which I feel is quite old one.
> While bumping the version to ZK-3.4.6, I've noticed one small diff
> about the netty versions.
> >
> > ZK has netty version - 3.7.0
> > BK has netty version - 3.2.9
> >
> > As part of ZOOKEEPER-1715, it has upgraded the netty version to
> > 3.7.0 <dependency org="io.netty" name="netty" conf="default"
> > rev="3.7.0.Final">
> >
> > But in BK we have different version 3.2.9
> > <dependency>
> > <groupId>org.jboss.netty</groupId>
> > <artifactId>netty</artifactId>
> > <version>3.2.9.Final</version>
> > <scope>compile</scope>
> > </dependency>
> >
> >
> > Following are few ideas that comes in my mind, which I'm putting to
> > kick
> start the discussion.
> >
> > Approach-1) Since BK is not using ZooKeeper's netty feature, it can
> > simply exclude the netty library while adding ZK-3.4.6 dependency
> > and BK will continue using his own version.
> BK uses the zk client which does use netty.
>
> > Approach-2) BK also will upgrade its netty version to '3.7.0' and be
> > in sync with ZK-3.4.6. Here it would need to see old - new BK
> > communications.
>
> >
> > Appreciate any help in finding a better way. Also welcome fresh
> > ideas:)
> >
> > Thanks & Regards,
> > Rakesh R
> >
> [1] http://netty.io/news/2013/08/27/semantic-versioning.html
>
RE: Upgrade ZK version in BK
Posted by Rakesh R <ra...@huawei.com>.
Thanks everyone for the reply.
>> We do use ClientSocketChannelFactory.
Would it be possible to deprecate this usage ? Anyway this would be handled gracefully when we shade netty library in future.
>> As I said before, we are close to 4.3.0, let's not bump any version at last minute, unless there is critical bugs need to fix.
>> We could bump zk and Netty versions in next release.
Thats fine.
-Rakesh
-----Original Message-----
From: Sijie Guo [mailto:guosijie@gmail.com]
Sent: 24 March 2014 08:31
To: bookkeeper-dev@zookeeper.apache.org
Cc: bookkeeper-user@zookeeper.apache.org
Subject: Re: Upgrade ZK version in BK
On Thursday, March 20, 2014, Ivan Kelly <iv...@apache.org> wrote:
> My take on this is actually that we should shade this also.
>
> [1] contains netty's policy on versioning. If we upgrade to 3.7.0 we
> force anyone using bookkeeper to upgrade also. As [1] says, the
> changes may not be binary compatible. I've actually experienced this
> problem with netty recently, though I think it was between major
> versions. In any case though, if binary incompatible can happen, we
> shouldn't break anyone by having them use us.
>
> However, shading would involve a source compat break for us, as one of
> the constructors for BookKeeper takes a ClientSocketChannelFactory. My
> vote on this, is to break this constructor for 3.4.0 release, upgrade
> netty and shade it. I really doubt anyone is using the constructor
> with ClientSocketChannelFactory.
We do use ClientSocketChannelFactory.
> Also, for 3.4.0, we should split out
> the client package into a separate module to avoid pulling in too many
> modules. It's not a huge amount of work. I think I did it in 45
> minutes before, but it needs to be done when there's very little
> outstanding work, and files move around a lot.
>
> Sijie, what do you think? You've been opposed to shading in the past.
As I said before, we are close to 4.3.0, let's not bump any version at last minute, unless there is critical bugs need to fix.
We could bump zk and Netty versions in next release.
>
> -Ivan
>
>
>
> > Presently BK is using ZK-3.4.3 version which I feel is quite old one.
> While bumping the version to ZK-3.4.6, I've noticed one small diff
> about the netty versions.
> >
> > ZK has netty version - 3.7.0
> > BK has netty version - 3.2.9
> >
> > As part of ZOOKEEPER-1715, it has upgraded the netty version to
> > 3.7.0 <dependency org="io.netty" name="netty" conf="default"
> > rev="3.7.0.Final">
> >
> > But in BK we have different version 3.2.9
> > <dependency>
> > <groupId>org.jboss.netty</groupId>
> > <artifactId>netty</artifactId>
> > <version>3.2.9.Final</version>
> > <scope>compile</scope>
> > </dependency>
> >
> >
> > Following are few ideas that comes in my mind, which I'm putting to
> > kick
> start the discussion.
> >
> > Approach-1) Since BK is not using ZooKeeper's netty feature, it can
> > simply exclude the netty library while adding ZK-3.4.6 dependency
> > and BK will continue using his own version.
> BK uses the zk client which does use netty.
>
> > Approach-2) BK also will upgrade its netty version to '3.7.0' and be
> > in sync with ZK-3.4.6. Here it would need to see old - new BK
> > communications.
>
> >
> > Appreciate any help in finding a better way. Also welcome fresh
> > ideas:)
> >
> > Thanks & Regards,
> > Rakesh R
> >
> [1] http://netty.io/news/2013/08/27/semantic-versioning.html
>
Re: Upgrade ZK version in BK
Posted by Sijie Guo <gu...@gmail.com>.
On Thursday, March 20, 2014, Ivan Kelly <iv...@apache.org> wrote:
> My take on this is actually that we should shade this also.
>
> [1] contains netty's policy on versioning. If we upgrade to 3.7.0 we
> force anyone using bookkeeper to upgrade also. As [1] says, the
> changes may not be binary compatible. I've actually experienced this
> problem with netty recently, though I think it was between major
> versions. In any case though, if binary incompatible can happen, we
> shouldn't break anyone by having them use us.
>
> However, shading would involve a source compat break for us, as one of
> the constructors for BookKeeper takes a ClientSocketChannelFactory. My
> vote on this, is to break this constructor for 3.4.0 release, upgrade
> netty and shade it. I really doubt anyone is using the constructor
> with ClientSocketChannelFactory.
We do use ClientSocketChannelFactory.
> Also, for 3.4.0, we should split out
> the client package into a separate module to avoid pulling in too many
> modules. It's not a huge amount of work. I think I did it in 45
> minutes before, but it needs to be done when there's very little
> outstanding work, and files move around a lot.
>
> Sijie, what do you think? You've been opposed to shading in the past.
As I said before, we are close to 4.3.0, let's not bump any version at last
minute, unless there is critical bugs need to fix.
We could bump zk and Netty versions in next release.
>
> -Ivan
>
>
>
> > Presently BK is using ZK-3.4.3 version which I feel is quite old one.
> While bumping the version to ZK-3.4.6, I've noticed one small diff about
> the netty versions.
> >
> > ZK has netty version - 3.7.0
> > BK has netty version - 3.2.9
> >
> > As part of ZOOKEEPER-1715, it has upgraded the netty version to 3.7.0
> > <dependency org="io.netty" name="netty" conf="default" rev="3.7.0.Final">
> >
> > But in BK we have different version 3.2.9
> > <dependency>
> > <groupId>org.jboss.netty</groupId>
> > <artifactId>netty</artifactId>
> > <version>3.2.9.Final</version>
> > <scope>compile</scope>
> > </dependency>
> >
> >
> > Following are few ideas that comes in my mind, which I'm putting to kick
> start the discussion.
> >
> > Approach-1) Since BK is not using ZooKeeper's netty feature, it can
> > simply exclude the netty library while adding ZK-3.4.6 dependency
> > and BK will continue using his own version.
> BK uses the zk client which does use netty.
>
> > Approach-2) BK also will upgrade its netty version to '3.7.0' and be
> > in sync with ZK-3.4.6. Here it would need to see old - new BK
> > communications.
>
> >
> > Appreciate any help in finding a better way. Also welcome fresh ideas:)
> >
> > Thanks & Regards,
> > Rakesh R
> >
> [1] http://netty.io/news/2013/08/27/semantic-versioning.html
>
Re: Upgrade ZK version in BK
Posted by Sijie Guo <gu...@gmail.com>.
On Thursday, March 20, 2014, Ivan Kelly <iv...@apache.org> wrote:
> My take on this is actually that we should shade this also.
>
> [1] contains netty's policy on versioning. If we upgrade to 3.7.0 we
> force anyone using bookkeeper to upgrade also. As [1] says, the
> changes may not be binary compatible. I've actually experienced this
> problem with netty recently, though I think it was between major
> versions. In any case though, if binary incompatible can happen, we
> shouldn't break anyone by having them use us.
>
> However, shading would involve a source compat break for us, as one of
> the constructors for BookKeeper takes a ClientSocketChannelFactory. My
> vote on this, is to break this constructor for 3.4.0 release, upgrade
> netty and shade it. I really doubt anyone is using the constructor
> with ClientSocketChannelFactory.
We do use ClientSocketChannelFactory.
> Also, for 3.4.0, we should split out
> the client package into a separate module to avoid pulling in too many
> modules. It's not a huge amount of work. I think I did it in 45
> minutes before, but it needs to be done when there's very little
> outstanding work, and files move around a lot.
>
> Sijie, what do you think? You've been opposed to shading in the past.
As I said before, we are close to 4.3.0, let's not bump any version at last
minute, unless there is critical bugs need to fix.
We could bump zk and Netty versions in next release.
>
> -Ivan
>
>
>
> > Presently BK is using ZK-3.4.3 version which I feel is quite old one.
> While bumping the version to ZK-3.4.6, I've noticed one small diff about
> the netty versions.
> >
> > ZK has netty version - 3.7.0
> > BK has netty version - 3.2.9
> >
> > As part of ZOOKEEPER-1715, it has upgraded the netty version to 3.7.0
> > <dependency org="io.netty" name="netty" conf="default" rev="3.7.0.Final">
> >
> > But in BK we have different version 3.2.9
> > <dependency>
> > <groupId>org.jboss.netty</groupId>
> > <artifactId>netty</artifactId>
> > <version>3.2.9.Final</version>
> > <scope>compile</scope>
> > </dependency>
> >
> >
> > Following are few ideas that comes in my mind, which I'm putting to kick
> start the discussion.
> >
> > Approach-1) Since BK is not using ZooKeeper's netty feature, it can
> > simply exclude the netty library while adding ZK-3.4.6 dependency
> > and BK will continue using his own version.
> BK uses the zk client which does use netty.
>
> > Approach-2) BK also will upgrade its netty version to '3.7.0' and be
> > in sync with ZK-3.4.6. Here it would need to see old - new BK
> > communications.
>
> >
> > Appreciate any help in finding a better way. Also welcome fresh ideas:)
> >
> > Thanks & Regards,
> > Rakesh R
> >
> [1] http://netty.io/news/2013/08/27/semantic-versioning.html
>
Re: Upgrade ZK version in BK
Posted by Ivan Kelly <iv...@apache.org>.
My take on this is actually that we should shade this also.
[1] contains netty's policy on versioning. If we upgrade to 3.7.0 we
force anyone using bookkeeper to upgrade also. As [1] says, the
changes may not be binary compatible. I've actually experienced this
problem with netty recently, though I think it was between major
versions. In any case though, if binary incompatible can happen, we
shouldn't break anyone by having them use us.
However, shading would involve a source compat break for us, as one of
the constructors for BookKeeper takes a ClientSocketChannelFactory. My
vote on this, is to break this constructor for 3.4.0 release, upgrade
netty and shade it. I really doubt anyone is using the constructor
with ClientSocketChannelFactory. Also, for 3.4.0, we should split out
the client package into a separate module to avoid pulling in too many
modules. It's not a huge amount of work. I think I did it in 45
minutes before, but it needs to be done when there's very little
outstanding work, and files move around a lot.
Sijie, what do you think? You've been opposed to shading in the past.
-Ivan
> Presently BK is using ZK-3.4.3 version which I feel is quite old one. While bumping the version to ZK-3.4.6, I've noticed one small diff about the netty versions.
>
> ZK has netty version - 3.7.0
> BK has netty version - 3.2.9
>
> As part of ZOOKEEPER-1715, it has upgraded the netty version to 3.7.0
> <dependency org="io.netty" name="netty" conf="default" rev="3.7.0.Final">
>
> But in BK we have different version 3.2.9
> <dependency>
> <groupId>org.jboss.netty</groupId>
> <artifactId>netty</artifactId>
> <version>3.2.9.Final</version>
> <scope>compile</scope>
> </dependency>
>
>
> Following are few ideas that comes in my mind, which I'm putting to kick start the discussion.
>
> Approach-1) Since BK is not using ZooKeeper's netty feature, it can
> simply exclude the netty library while adding ZK-3.4.6 dependency
> and BK will continue using his own version.
BK uses the zk client which does use netty.
> Approach-2) BK also will upgrade its netty version to '3.7.0' and be
> in sync with ZK-3.4.6. Here it would need to see old - new BK
> communications.
>
> Appreciate any help in finding a better way. Also welcome fresh ideas:)
>
> Thanks & Regards,
> Rakesh R
>
[1] http://netty.io/news/2013/08/27/semantic-versioning.html
Re: Upgrade ZK version in BK
Posted by Ivan Kelly <iv...@apache.org>.
My take on this is actually that we should shade this also.
[1] contains netty's policy on versioning. If we upgrade to 3.7.0 we
force anyone using bookkeeper to upgrade also. As [1] says, the
changes may not be binary compatible. I've actually experienced this
problem with netty recently, though I think it was between major
versions. In any case though, if binary incompatible can happen, we
shouldn't break anyone by having them use us.
However, shading would involve a source compat break for us, as one of
the constructors for BookKeeper takes a ClientSocketChannelFactory. My
vote on this, is to break this constructor for 3.4.0 release, upgrade
netty and shade it. I really doubt anyone is using the constructor
with ClientSocketChannelFactory. Also, for 3.4.0, we should split out
the client package into a separate module to avoid pulling in too many
modules. It's not a huge amount of work. I think I did it in 45
minutes before, but it needs to be done when there's very little
outstanding work, and files move around a lot.
Sijie, what do you think? You've been opposed to shading in the past.
-Ivan
> Presently BK is using ZK-3.4.3 version which I feel is quite old one. While bumping the version to ZK-3.4.6, I've noticed one small diff about the netty versions.
>
> ZK has netty version - 3.7.0
> BK has netty version - 3.2.9
>
> As part of ZOOKEEPER-1715, it has upgraded the netty version to 3.7.0
> <dependency org="io.netty" name="netty" conf="default" rev="3.7.0.Final">
>
> But in BK we have different version 3.2.9
> <dependency>
> <groupId>org.jboss.netty</groupId>
> <artifactId>netty</artifactId>
> <version>3.2.9.Final</version>
> <scope>compile</scope>
> </dependency>
>
>
> Following are few ideas that comes in my mind, which I'm putting to kick start the discussion.
>
> Approach-1) Since BK is not using ZooKeeper's netty feature, it can
> simply exclude the netty library while adding ZK-3.4.6 dependency
> and BK will continue using his own version.
BK uses the zk client which does use netty.
> Approach-2) BK also will upgrade its netty version to '3.7.0' and be
> in sync with ZK-3.4.6. Here it would need to see old - new BK
> communications.
>
> Appreciate any help in finding a better way. Also welcome fresh ideas:)
>
> Thanks & Regards,
> Rakesh R
>
[1] http://netty.io/news/2013/08/27/semantic-versioning.html