Improve GOAWAY handling to allow for forced and graceful termination

ari-ban / issue-test

0 stars 0 forks source link

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

Closed arinban closed 7 years ago

arinban commented 7 years ago

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

arinban commented 6 years ago

Issue Imported From: https://github.com/javaee/grizzly/issues/1925
Original Issue Raised By:@rlubke
Original Issue Assigned To:@rlubke
Original Issue Closed By:@rlubke

arinban commented 7 years ago

@kofemann Commented shouldn't this go into master as well?

arinban commented 7 years ago

@rlubke Commented Master doesn't have http2 yet.

arinban commented 7 years ago

@rlubke Commented 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

arinban commented 7 years ago

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

arinban commented 7 years ago

@rlubke Commented 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!

arinban commented 7 years ago

@rlubke Commented Re-opening. There's some additional changes necessary.

arinban commented 7 years ago

@kofemann Commented 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!