On Tuesday, March 25, 2014, Sijie Guo <[email protected]> wrote: > > > On Monday, March 24, 2014, Rakesh R > <[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>> > 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:[email protected]] >> Sent: 24 March 2014 08:31 >> To: [email protected] >> Cc: [email protected] >> Subject: Re: Upgrade ZK version in BK >> >> On Thursday, March 20, 2014, Ivan Kelly <[email protected]> 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 >> > >> >
