Improve GOAWAY handling to allow for forced and graceful termination - Githubissues

javaee / grizzly

Writing scalable server applications in the Java™ programming language has always been difficult. Before the advent of the Java New I/O API (NIO), thread management issues made it impossible for a server to scale to thousands of users. The Grizzly NIO framework has been designed to help developers to take advantage of the Java™ NIO API.

https://javaee.github.io/grizzly/

Other

222 stars 60 forks source link

Improve GOAWAY handling to allow for forced and graceful termination #1925

Closed rlubke closed 7 years ago

rlubke commented 7 years ago

The current implementation handling of GOAWAY isn't to the spec. This needs to be improved before shipping.

kofemann commented 7 years ago

shouldn't this go into master as well?

rlubke commented 7 years ago

Master doesn't have http2 yet.

rlubke commented 7 years ago

Just to explain why: it makes it easier with the on-going development, IMO, to get it working in one branch first and then move once it's polished to avoid having to additional actions on each commit

kofemann commented 7 years ago

different philosophy...We always got through master branch to ensure that fixes and new features are never get lost in the master.

rlubke commented 7 years ago

We generally have a sustaining branch that is active (2.3.x, 2.4.x) that we apply fixes and small features to. These will be ported to master. We've been doing backwards incompatible changes in master in preparation of 3.0. It makes is harder to work from master in that regard.

This is just how we've done it for years now. Not saying it's right. If you have suggestions for a better option, we can certainly discuss!

rlubke commented 7 years ago

Re-opening. There's some additional changes necessary.

kofemann commented 7 years ago

well, you should not change your workflow if it works for you. But here is how we do it at dCache:

All development in the master branch
At some point new release branch is created, let say 1.0
release branch is stabilized, but all fixes goes through master, unless master doesn't contain them any more
At some point 1.0.0 is released.
all bug fixes goes through master branch

and this is in the loop.

This is very similar to what many other software projects are doing. At least all others I have contributed to ( except grizzly, actually). It works for as. We have weekly bug-fix releases and 3-4 months cycle for major releases. 3-5 active branches supported in parallel. In last 10 years we had 60 branches and 760 releases.

Again, you work workflow works for you, there are no reasons to change it!