question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Replace EnsureActive with Akka's StartEntity

See original GitHub issue

Akka 2.5 introduces the StartEntity message specially meant to activate a sharded entity. On top of that it’s implemented so that it will not be delivered to the entity actor itself.

If we replaced the EnsureActive message used on ClusterDistribution and also ReadSideActor and TaggedOffsetProducerActor with StartEntity then the entity actors will not be cluster aware and will be more testable.

Changing this means the entity actor is responsible for starting itself once it’s activated since i can’t rely on an external EnsureActive or StartEntity message acting as trigger. This limitation requires a new way to provide the tag that each instance of the entity actor will be responsible for.

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:8 (8 by maintainers)

github_iconTop GitHub Comments

1reaction
octonatocommented, Sep 22, 2017

Have we maybe mixed things by offering a prepare method that has the responsibility to prepare what ever needs to be done + retrieve the last know offset?

From the scaladoc/javadoc:

The primary purpose of this method is to load the last offset that was processed, so that read side processing can continue from that offset.

This also provides an opportunity for processors to do any initialisation activities, such as creating or updating database tables, or migrating data.

This will be invoked at least once for each tag, and may be invoked multiple times, such as in the event of failure.

From the docs we are saying that there is a primary purpose + a piggy-back one. That’s a good example of missing concerns. We should have a prepare and a findLastestOffset.

Anyway, although I think it was a missed opportunity to separate these two concerns, I think that will be ok to call it from inside the closure as you mentioned. As the last paragraph states, it will be invoked at least once and possibly multiple times in case of failure. We won’t be breaking the contract if a user piggy-back it. Actually, we even recommended the user to piggy-back it.

0reactions
ignasi35commented, Sep 22, 2017

This issue doesn’t make sense anymore. #999 is meant to replace EnsureActive with StartEntity but in Lagom the sharded entity needs the payload of the message (EnsureActive or StartEntity). The problem is that StartEntity is not delivered to the entity. This is a feature of Akka Cluster Sharding since v 2.5: the message is used to actiavte the entity but is not delivered to the entity purposedly.

When I originally wrote this issue I had another improvement in mind which is now it’s own issue. See #1006.

Read more comments on GitHub >

github_iconTop Results From Across the Web

ensureActive - Kotlin
If the job was cancelled, thrown exception contains the original cancellation cause. This method is a drop-in replacement for the following code, but...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found