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.

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 ResultMessage is processed #4135

Merged
merged 3 commits into from
Nov 29, 2018

Conversation

jiangpengcheng
Copy link
Contributor

@jiangpengcheng jiangpengcheng commented Nov 26, 2018

Description

As processCompeltion and processResult is executed asynchronously, it's better to ensure ResultMessage will be processed in any case

Related issue and scope

My changes affect the following components

  • API
  • Controller
  • Message Bus (e.g., Kafka)
  • Loadbalancer
  • Invoker
  • Intrinsic actions (e.g., sequences, conductors)
  • Data stores (e.g., CouchDB)
  • Tests
  • Deployment
  • CLI
  • General tooling
  • Documentation

Types of changes

  • Bug fix (generally a non-breaking change which closes an issue).
  • Enhancement or new feature (adds new functionality).
  • Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

  • I signed an Apache CLA.
  • I reviewed the style guides and followed the recommendations (Travis CI will check :).
  • I added tests to cover my changes.
  • My changes require further changes to the documentation.
  • I updated the documentation where necessary.

@codecov-io
Copy link

codecov-io commented Nov 26, 2018

Codecov Report

Merging #4135 into master will decrease coverage by 4.89%.
The diff coverage is 85.71%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master    #4135     +/-   ##
=========================================
- Coverage   86.17%   81.28%   -4.9%     
=========================================
  Files         151      151             
  Lines        7271     7272      +1     
  Branches      469      468      -1     
=========================================
- Hits         6266     5911    -355     
- Misses       1005     1361    +356
Impacted Files Coverage Δ
...e/loadBalancer/ShardingContainerPoolBalancer.scala 85.09% <85.71%> (ø) ⬆️
...core/database/cosmosdb/RxObservableImplicits.scala 0% <0%> (-100%) ⬇️
...core/database/cosmosdb/CosmosDBArtifactStore.scala 0% <0%> (-95.54%) ⬇️
...sk/core/database/cosmosdb/CosmosDBViewMapper.scala 0% <0%> (-92.6%) ⬇️
...whisk/core/database/cosmosdb/CosmosDBSupport.scala 0% <0%> (-83.34%) ⬇️
...abase/cosmosdb/CosmosDBArtifactStoreProvider.scala 0% <0%> (-62.5%) ⬇️
...in/scala/org/apache/openwhisk/common/Counter.scala 40% <0%> (-20%) ⬇️
...penwhisk/core/database/cosmosdb/CosmosDBUtil.scala 92% <0%> (-4%) ⬇️
...rg/apache/openwhisk/common/ForcibleSemaphore.scala 92.3% <0%> (-3.85%) ⬇️
...isk/core/controller/actions/PrimitiveActions.scala 86.71% <0%> (-0.7%) ⬇️
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7bd4971...f4c6540. Read the comment docs.

@rabbah rabbah self-requested a review November 26, 2018 20:28
@cbickel
Copy link
Contributor

cbickel commented Nov 27, 2018

@jiangpengcheng Thanks a lot for tackling this issue again.
I also looked at the problem again. What do you think about the following approach of fixing this:
The promise is only used in case the activation was blocking. In case of non-blocking activations, this promise is never used.
What about storing the promise only in your new map for blocking requests?

@jiangpengcheng
Copy link
Contributor Author

@cbickel
do you mean create an extra Promise[Either[ActivationId, WhiskActivation]] , saved it into the new map for blocking activations, and return this promise.future in the publish method,
and for non-blocking activations, just keep the original way?

or

don't create promise for non-blocking activations, just return an Future.successful(Left(aid)) in the publish method?

Copy link
Contributor

@cbickel cbickel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
Thanks a lot for doing this PR and simplifying it.

@cbickel
Copy link
Contributor

cbickel commented Nov 28, 2018

Ah wait. One more thing came into my mind. Do we still need to store the promise in the ActivationEntry with this change? I think it would be enough to store it in blockingPromises, right?

@jiangpengcheng
Copy link
Contributor Author

yes, we don't need that promise

@ningyougang
Copy link
Contributor

@cbickel ,can be merged?

@cbickel cbickel merged commit 7f571c3 into apache:master Nov 29, 2018
sendActivationToInvoker(messageProducer, msg, invoker).map { _ =>
entry.promise.future
if (msg.blocking) {
blockingPromises.getOrElseUpdate(msg.activationId, Promise[Either[ActivationId, WhiskActivation]]()).future
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

while not likely, it's plausible the active ack is received before the promise is added to this map (which is why setup activation adds the promise before it's posted to any invoker).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants