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.

Sign up for GitHub

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

Jump to bottom

Requests with closed upstreams are not handled with max-connections #368

Closed
2m opened this issue Oct 5, 2016 · 2 comments
Closed

Requests with closed upstreams are not handled with max-connections #368

2m opened this issue Oct 5, 2016 · 2 comments
Labels
bug t:server Issues related to the HTTP server
Milestone
10.0.0-RC2

Comments

@2m
Copy link
Member

2m commented Oct 5, 2016

Reproducer here

The problem is that when max-connections is set to a lower value than gatling load test opens connections, some incoming connections are buffered in the OS kernel throughout all of the test. When the test finishes, these buffered connections are closed by gatling, but akka-http server still handles them without respecting max-connections setting.
@2m 2m added bug 1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted t:http:server labels Oct 5, 2016
@jrudolph
Copy link
Member

jrudolph commented Oct 5, 2016 •
edited
Loading

Ok, the reason is probably that in Http.bindAndHandle, connections are limited by the watchTermination future and termination is monitored on the upstream so that completion may be handled concurrently with a request still running. A simple solution could be to move the watchTermination behind the user handler flow so that the user can decide when a connection should be closed (or be counted as closed wrt the maxConnection limit).

@2m
Copy link
Member Author

2m commented Oct 5, 2016

Exactly. Moving watchTermination solves this issue. The hard part was writing the actual test for it. I have a working gatling simulation running in akka-http-tests subproject that actually tests this. I was not able to reproduce the same behaviour with akka-http client though.

2m added a commit to 2m/akka-http that referenced this issue Oct 5, 2016
@2m
akka#368 Capture user handler in a termination future
a6ae09f
2m added a commit to 2m/akka-http that referenced this issue Oct 5, 2016
@2m
akka#368 Capture user handler in a termination future
61ecfeb
@2m 2m mentioned this issue Oct 5, 2016
Closed
@jrudolph jrudolph added t:server Issues related to the HTTP server and removed t:http:server labels Nov 2, 2016
jrudolph added a commit that referenced this issue Nov 3, 2016
@jrudolph
=htc #368 document the guarantees of max-connections
1d05323 
Actually providing better guarantees turned out to be difficult, so
being clear about the limit being an approximate one seems to be the
best solution for now.

See also the discussions in #371.

Fixes #368.
@jrudolph jrudolph mentioned this issue Nov 3, 2016
Merged
jrudolph added a commit that referenced this issue Nov 7, 2016
@jrudolph
=htc #368 be more accurate about max-connections
d315b4f 
To find out whether the materialization for one connection has finished
bindAndHandle will now use two `watchTermination` combinators.

As explained in the Scaladoc this will still not provide 100 percent
guarantee that all of the flow will have finished but it is hopefully
more accurate than before.
@ktoso ktoso closed this as completed in #473 Nov 7, 2016
ktoso pushed a commit that referenced this issue Nov 7, 2016
@jrudolph @ktoso
=htc #368 document the guarantees of max-connections (#473)
c7ac641 
* =htc #368 document the guarantees of `max-connections`

Actually providing better guarantees turned out to be difficult, so
being clear about the limit being an approximate one seems to be the
best solution for now.

See also the discussions in #371.

Fixes #368.

* =htc #368 be more accurate about `max-connections`

To find out whether the materialization for one connection has finished
bindAndHandle will now use two `watchTermination` combinators.

As explained in the Scaladoc this will still not provide 100 percent
guarantee that all of the flow will have finished but it is hopefully
more accurate than before.
@ktoso ktoso added this to the 10.0.0 "first stable" milestone Nov 7, 2016
@ktoso ktoso removed the 1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted label Nov 7, 2016
@ktoso ktoso modified the milestones: 10.0.0 "first stable", Final HTTP/2, 10.0.0-RC2 Nov 10, 2016
jedrekn pushed a commit to jedrekn/akka-http that referenced this issue Nov 17, 2016
@jrudolph @ktoso
=htc akka#368 document the guarantees of max-connections (akka#473)
40d2c00 
* =htc akka#368 document the guarantees of `max-connections`

Actually providing better guarantees turned out to be difficult, so
being clear about the limit being an approximate one seems to be the
best solution for now.

See also the discussions in akka#371.

Fixes akka#368.

* =htc akka#368 be more accurate about `max-connections`

To find out whether the materialization for one connection has finished
bindAndHandle will now use two `watchTermination` combinators.

As explained in the Scaladoc this will still not provide 100 percent
guarantee that all of the flow will have finished but it is hopefully
more accurate than before.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug t:server Issues related to the HTTP server
Projects
None yet
Milestone
10.0.0-RC2
Development

No branches or pull requests
3 participants
@jrudolph @ktoso @2m