New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove master branch #4466

Closed
normanmaurer opened this Issue Nov 11, 2015 · 26 comments

Comments

Projects
None yet
@normanmaurer
Member

normanmaurer commented Nov 11, 2015

After talking with @Scottmitch and also with @nmittler I would like to propose "dropping" current master and so not release any new 5.0 version for now.

The major change of using a ForkJoinPool increases complexity and has not
demonstrated a clear performance benefit. Also keeping all the branches in sync is quite some work without a real need for it as there is nothin in current master which I think justifies a new major release.

Things that we should investigate to prepare for this change:

  • Deprecate exceptionCaught in ChannelHandler, only expose it in ChannelInboundHandler
  • Expose EventExecutorChooser from MultithreadEventExecutorGroup to allow the user more flexibility to choose next EventLoop
  • Add another method to be able to send user events both ways in the pipeline. (#4378)

Please chime in here and let me / us hear any concerns.

@normanmaurer

This comment has been minimized.

Member

normanmaurer commented Nov 11, 2015

@normanmaurer

This comment has been minimized.

Member

normanmaurer commented Nov 11, 2015

Also I should have mentioned that we should create a new branch from current master that we keep for "backup" reasons. So we can port code if the need arise later.

@trustin

This comment has been minimized.

Member

trustin commented Nov 11, 2015

+1. I'd like to keep the handler type hierarchy simplification for later cherry-pick (?) though.

@blucas

This comment has been minimized.

Contributor

blucas commented Nov 11, 2015

A few questions:

  • So what do you propose creating exactly, for example where would these changes (deprecating exceptionCaught, exposing EventExecutorChooser, etc.) be applied - 4.1, 4.2, or a new 5.0 branch?
  • If I remember correctly, 5.0 merged ChannelInboundHandler and ChannelOutboundHandler as well as introducing messageReceived as a replacement for channelRead0. What would happen to these changes?
  • Will all features/improvements currently applied to master be ported to this new release? Obviously HTTP/2 was ported to 4.1, just wondering if there is anything else sitting on master that would need attention.
@ninja-

This comment has been minimized.

ninja- commented Nov 11, 2015

That's a bit sad but I would support this change D: wasn't the major feature of 5.0 fixed eventloop migrations or something like that?

@Scottmitch

This comment has been minimized.

Member

Scottmitch commented Nov 11, 2015

So what do you propose creating exactly, for example where would these changes (deprecating exceptionCaught, exposing EventExecutorChooser, etc.) be applied - 4.1, 4.2, or a new 5.0 branch?

@blucas - Unless there are objections I think the proposal is to apply these changes to 4.1. The discussion revolves around there not being enough API changes/core features to justify maintaining a different fork. Any deprecated methods/interfaces would also be marked accordingly in 4.0.

If I remember correctly, 5.0 merged ChannelInboundHandler and ChannelOutboundHandler as well as introducing messageReceived as a replacement for channelRead0. What would happen to these changes?

Are you thinking of 4.1 SimpleChannelInboundHandler.channelRead0 vs 5.0 SimpleChannelInboundHandler.messageReceived? In 4.1 I guess we would keep channelRead0 to stay API compatible with 4.0

Will all features/improvements currently applied to master be ported to this new release? Obviously HTTP/2 was ported to 4.1, just wondering if there is anything else sitting on master that would need attention.

That is the intention. If you know of any please call them out :) We will rename the "master" branch so nothing will be lost if we forget/miss something.

@normanmaurer

This comment has been minimized.

Member

normanmaurer commented Nov 13, 2015

@blucas what @Scottmitch said.

@normanmaurer

This comment has been minimized.

Member

normanmaurer commented Nov 13, 2015

@ninja- event loop migration works in 4.0 as well.

@Scottmitch

This comment has been minimized.

Member

Scottmitch commented Nov 24, 2015

@normanmaurer - Also as a reminder we should revisit deprecated items in 4.1. If things have been deprecated in 4.1 in favor of a change in 5.0, we may want to un-deprecate these items.

@Scottmitch

This comment has been minimized.

Member

Scottmitch commented Nov 24, 2015

@normanmaurer - For example AUTO_CLOSE channel option may be a candidate.

@trustin

This comment has been minimized.

Member

trustin commented Dec 6, 2015

Meanwhile, let me change the default branch from 'master' to '4.1'.

@normanmaurer

This comment has been minimized.

Member

normanmaurer commented Dec 6, 2015

Thanks! Will take care of the rest once back from vacation

Am 06.12.2015 um 07:02 schrieb Trustin Lee notifications@github.com:

Meanwhile, let me change the default branch from 'master' to '4.1'.


Reply to this email directly or view it on GitHub.

@hepin1989

This comment has been minimized.

Contributor

hepin1989 commented Dec 6, 2015

As Netty In Action covers 4.x,I think this should be fine.

@normanmaurer

This comment has been minimized.

Member

normanmaurer commented Dec 17, 2015

master branch was rename to master_deprecated. Changes only need to go to 4.0 and 4.1 now.

@normanmaurer normanmaurer self-assigned this Dec 17, 2015

@normanmaurer normanmaurer added this to the 4.1.0.CR1 milestone Dec 17, 2015

@Scottmitch

This comment has been minimized.

Member

Scottmitch commented Dec 17, 2015

Woot! thanks @normanmaurer!

@junchaowu

This comment has been minimized.

junchaowu commented Mar 9, 2016

For existing 5.x user, do you recommend to change back to use 4.x or I can still use 5.x? What's the recommend way now

@normanmaurer

This comment has been minimized.

Member

normanmaurer commented Mar 9, 2016

Use 4.0 or 4.1

Am 09.03.2016 um 20:37 schrieb junchaowu notifications@github.com:

For existing 5.x user, do you recommend to change back to use 4.x or I can still use 5.x? What's the recommend way now


Reply to this email directly or view it on GitHub.

@ShanniLi

This comment has been minimized.

ShanniLi commented Mar 9, 2016

@normanmaurer this change will break TChannel-JAVA and all TChannel-JAVA users.

@normanmaurer

This comment has been minimized.

Member

normanmaurer commented Mar 9, 2016

@ShanniLi again just use netty 4.0 which works on android

@normanmaurer

This comment has been minimized.

Member

normanmaurer commented Mar 9, 2016

@ShanniLi 5.0 was alpha so you should expect breakage.

@zhangkan1983

This comment has been minimized.

zhangkan1983 commented Jun 13, 2016

@normanmaurer @trustin:
My major concern is that in 4.X, when implement a UDP server, there is only one channel and Eventloop to handle all the IO operation by design(as far as i understand). This would definitely introduce a performance issue when many devices are try to connect to the server at the same time. And unfortunately, we cannot utilize the Linux epoll as the kernel version is only 2.6. Is there any workaround available in 4.X? Please let me know.

Many Many Thanks!

Kan

@freevest

This comment has been minimized.

freevest commented Oct 31, 2016

Mark and support

@wxyjuly

This comment has been minimized.

wxyjuly commented Jan 16, 2018

come on , waiting for next time updated

@niancheng

This comment has been minimized.

niancheng commented Jan 29, 2018

mark

@LoveCtrip

This comment has been minimized.

LoveCtrip commented Apr 27, 2018

ok

@yschimke

This comment has been minimized.

Contributor

yschimke commented Nov 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment