AbsorbCancellation stage may leak stages in server #851
Assignees
Labels
Projects
Milestone
Comments
jrudolph
added a commit
to jrudolph/akka-http
that referenced
this issue
Feb 8, 2017
Under circumstances that I could not reproduce so far, the AbsorbCancellation stage introduced in akka#459 may keep the graph running if data was already buffered but never read. The reason is that the stage so far requires completion to reach the stage after cancellation was absorbed which might be blocked by incoming elements that were never pulled. The solution is two-fold. After cancellation: 1) pull in and ignore all incoming elements to eventually fetch completion 2) complete the stage after a configurable time In the HTTP use case, we delay the cancellation by no more than the time specified in the new linger-timeout setting.
jrudolph
added a commit
to jrudolph/akka-http
that referenced
this issue
Feb 8, 2017
Under circumstances that I could not reproduce so far, the AbsorbCancellation stage introduced in akka#459 may keep the graph running if data was already buffered but never read. The reason is that the stage so far requires completion to reach the stage after cancellation was absorbed which might be blocked by incoming elements that were never pulled. The solution is two-fold. After cancellation: 1) pull in and ignore all incoming elements to eventually fetch completion 2) complete the stage after a configurable time In the HTTP use case, we delay the cancellation by no more than the time specified in the new linger-timeout setting.
jrudolph
added a commit
to jrudolph/akka-http
that referenced
this issue
Feb 9, 2017
Under circumstances that I could not reproduce so far, the AbsorbCancellation stage introduced in akka#459 may keep the graph running if data was already buffered but never read. The reason is that the stage so far requires completion to reach the stage after cancellation was absorbed which might be blocked by incoming elements that were never pulled. The solution is two-fold. After cancellation: 1) pull in and ignore all incoming elements to eventually fetch completion 2) complete the stage after a configurable time In the HTTP use case, we delay the cancellation by no more than the time specified in the new linger-timeout setting.
jrudolph
added a commit
to jrudolph/akka-http
that referenced
this issue
Feb 9, 2017
Under circumstances that I could not reproduce so far, the AbsorbCancellation stage introduced in akka#459 may keep the graph running if data was already buffered but never read. The reason is that the stage so far requires completion to reach the stage after cancellation was absorbed which might be blocked by incoming elements that were never pulled. The solution is two-fold. After cancellation: 1) pull in and ignore all incoming elements to eventually fetch completion 2) complete the stage after a configurable time In the HTTP use case, we delay the cancellation by no more than the time specified in the new linger-timeout setting.
jrudolph
added a commit
to jrudolph/akka-http
that referenced
this issue
Feb 16, 2017
Under circumstances that I could not reproduce so far, the AbsorbCancellation stage introduced in akka#459 may keep the graph running if data was already buffered but never read. The reason is that the stage so far requires completion to reach the stage after cancellation was absorbed which might be blocked by incoming elements that were never pulled. The solution is two-fold. After cancellation: 1) pull in and ignore all incoming elements to eventually fetch completion 2) complete the stage after a configurable time In the HTTP use case, we delay the cancellation by no more than the time specified in the new linger-timeout setting.
jrudolph
added a commit
to jrudolph/akka-http
that referenced
this issue
Feb 16, 2017
Under circumstances that I could not reproduce so far, the AbsorbCancellation stage introduced in akka#459 may keep the graph running if data was already buffered but never read. The reason is that the stage so far requires completion to reach the stage after cancellation was absorbed which might be blocked by incoming elements that were never pulled. The solution is two-fold. After cancellation: 1) pull in and ignore all incoming elements to eventually fetch completion 2) complete the stage after a configurable time In the HTTP use case, we delay the cancellation by no more than the time specified in the new linger-timeout setting.
jrudolph
added a commit
that referenced
this issue
Feb 16, 2017
=htc #851 fix leaking AbsorbCancellation
|
Fixed by #852. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Under so far unknown circumstances the AbsorbCancellation stage introduced in #459 may keep the graph running if data was already buffered but never read. The reason is that the stage so far requires completion to reach the stage after cancellation was absorbed which might be blocked by incoming elements that were never pulled.
The text was updated successfully, but these errors were encountered: