-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Ensure, that Result-ack is sent before Completion-ack. #4115
Conversation
// should have arrived earlier and already resolved it. If it didn't arrive yet (what could happen if log | ||
// collection is really fast and the result is very large), it will most likely arrive in a few milliseconds. | ||
// If that message really got lost, the mechanism of DB-polling will take place. | ||
if (!entry.blocking) entry.promise.trySuccess(Left(aid)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There may be a problem with the line activations.remove(aid)
as well. Since the ID is removed from the activations TrieMap, the processResult
method may not be able to find the ID when activations.get(aid).map
is called.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right. That's a very good point.
if (job.msg.blocking) { | ||
activation.foreach( | ||
val sendResult = if (job.msg.blocking) { | ||
activation.map( | ||
sendActiveAck(tid, _, job.msg.blocking, job.msg.rootControllerIndex, job.msg.user.namespace.uuid, false)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shoudl reconcile any errors here into a Future.successful or use onComplete
below. Otherwise you'll end up not sending the second message if the first failed. Unlikely, but just a teeny bit more defensive. I'd go for onComplete
below, because that makes it more clear on the calling side, that you don't care about errors.
FWIW I like this solution a lot better than the one before.
Codecov Report
@@ Coverage Diff @@
## master #4115 +/- ##
==========================================
- Coverage 86.25% 81.31% -4.95%
==========================================
Files 151 151
Lines 7263 7269 +6
Branches 468 470 +2
==========================================
- Hits 6265 5911 -354
- Misses 998 1358 +360
Continue to review full report at Codecov.
|
@@ -530,8 +530,16 @@ class ContainerProxy( | |||
activationWithLogs | |||
.map(_.fold(_.activation, identity)) | |||
.foreach { activation => | |||
// Sending the completionMessage to the controller asynchronously. | |||
sendActiveAck(tid, activation, job.msg.blocking, job.msg.rootControllerIndex, job.msg.user.namespace.uuid, true) | |||
// Sending the completionMessage to the controller asynchronously. But not before result message is sent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe im confused by the view on github - is the active ack sent twice for blocking invokes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you're right, one is ComplectionMessage
and the other is ResultMessage
PG3#3673 is 🔵 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cbickel I added a commit which adds some comments (that helped me understand the changes). What do you think?
Also you'll notice I added a type alias so the active ack method is easier to find. I'd suggest we do that for some of the other function closures.
…ion messages. Adds a type alias for the active ack messages, and document the interface.
@rabbah Thanks a lot for your proposed changes :) Using these type aliases in more places makes totally sense to me. |
Improves comments to clarify the ordering of result and completion messages. Adds a type alias for the active ack messages, and document the interface. Co-authored-by: Christian Bickel <[email protected]> Co-authored-by: Rodric Rabbah <[email protected]>
Description
On invoking an action blocking, a ResultMessage and afterwards a CompletionMessage will be sent from the invoker to the controller. The CompletionMessage is always very small. Currently those two messages are sent asynchronously. If log-collection is very fast, they are sent to Kafka at the same point in time.
This could result into the condition, that the loadbalancer receives the completion-ack before the result ack. This will make the response to the customer slower, as the controller first needs to go against Kafka.
This PR will ensure, that the completion message will be sent after the reult message has been published successfully to Kafka.
Related issue and scope
My changes affect the following components
Types of changes
Checklist: