Skip to content
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 · 32 comments
Closed

Remove master branch #4466

normanmaurer opened this issue Nov 11, 2015 · 32 comments
Assignees
Milestone

Comments

@normanmaurer
Copy link
Member

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. (Possibility of firing user event in outbound direction. #4378)

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

@normanmaurer
Copy link
Member Author

@normanmaurer
Copy link
Member Author

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
Copy link
Member

trustin commented Nov 11, 2015

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

@blucas
Copy link
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-
Copy link

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
Copy link
Member

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
Copy link
Member Author

@blucas what @Scottmitch said.

@normanmaurer
Copy link
Member Author

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

@Scottmitch
Copy link
Member

@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
Copy link
Member

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

@trustin
Copy link
Member

trustin commented Dec 6, 2015

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

@normanmaurer
Copy link
Member Author

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.

@He-Pin
Copy link
Contributor

He-Pin commented Dec 6, 2015

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

@normanmaurer
Copy link
Member Author

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
Copy link
Member

Woot! thanks @normanmaurer!

@jc-fireball
Copy link

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
Copy link
Member Author

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
Copy link

ShanniLi commented Mar 9, 2016

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

@normanmaurer
Copy link
Member Author

@ShanniLi again just use netty 4.0 which works on android

@normanmaurer
Copy link
Member Author

@ShanniLi 5.0 was alpha so you should expect breakage.

@zhangkan1983
Copy link

@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
Copy link

Mark and support

@wxyjuly
Copy link

wxyjuly commented Jan 16, 2018

come on , waiting for next time updated

@niancheng
Copy link

mark

@FreedomTrip
Copy link

ok

@yschimke
Copy link
Contributor

image

https://github.com/netty/netty/projects/1

@fuzhengwei
Copy link

@shihongwei
Copy link

mark

@abcdelf
Copy link

abcdelf commented Jul 20, 2021

@shallwetalkge
Copy link

mark

@SolarisNeko
Copy link

What direction will netty 5.x consider to improve performance?
Will you consider the follow-up Java cooperation program (Virtual Thread) ?

@niancheng
Copy link

niancheng commented May 31, 2023 via email

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

No branches or pull requests