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

Persistence: persist() does not stash when invoked while handling RecoveryCompleted #21736

Closed
jypma opened this issue Oct 27, 2016 · 3 comments
Closed
Labels
help wanted Issues that the core team will likely not have time to work on t:persistence
Milestone

Comments

@jypma
Copy link
Member

jypma commented Oct 27, 2016

I have a PersistentActor that wants to self-initialize like such:

    @Override
    public PartialFunction<Object, BoxedUnit> receiveRecover() {
        return ReceiveBuilder
            .match(RecoveryCompleted.class, msg -> {
                if (lastSequenceNr() == 0) {
                    persist(createInitialEvent(), e -> {
                        updateSomeState();
                    });
                }
            })
            .build()
            .orElse(super.receiveRecover());
    }

However, incoming commands aren't stashed between persisting the createInitialEvent() and getting the callback to updateSomeState() (which does happen eventually, I think as the next command is handled).

In EventSourcing.scala, the reason is that the detecting of pendingStashingPersistInvocations isn't performed until the state reaches processingCommands. Perhaps a well-placed changeState(persistingEvents) inside recoveryStarted(...) or recovering(...) could make it work.

Otherwise, blow up if persist() is invoked during receiveRecover.

@jypma
Copy link
Member Author

jypma commented Oct 27, 2016

Workaround: Put the check inside receiveCommand() and stash there while the initial persist is happening.

@patriknw patriknw added this to the 2.4.x milestone Oct 31, 2016
@patriknw patriknw added 1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted help wanted Issues that the core team will likely not have time to work on t:persistence labels Oct 31, 2016
ortibazar pushed a commit to ortibazar/akka that referenced this issue Nov 24, 2016
ortibazar pushed a commit to ortibazar/akka that referenced this issue Nov 28, 2016
ortibazar pushed a commit to ortibazar/akka that referenced this issue Dec 13, 2016
ktoso pushed a commit that referenced this issue Dec 14, 2016
* be able to persist events that happen during recovery, #21736

* prohibit persiting events during recovery, #21736

* change error message #21736
@ktoso ktoso modified the milestones: 2.5.0, 2.4.x Dec 14, 2016
@ktoso
Copy link
Member

ktoso commented Dec 14, 2016

Not backporting, it's not critical to have this back in 2.4 I think

@ktoso ktoso removed the 1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted label Dec 14, 2016
@patriknw patriknw closed this as completed Jan 3, 2017
patriknw pushed a commit that referenced this issue Feb 21, 2017
* be able to persist events that happen during recovery, #21736

* prohibit persiting events during recovery, #21736

* change error message #21736

(cherry picked from commit ef1e0e0)
@patriknw patriknw modified the milestones: 2.4.18, 2.5-M1 Feb 21, 2017
@patriknw
Copy link
Member

I have backported it, because something else was depending on it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Issues that the core team will likely not have time to work on t:persistence
Projects
None yet
Development

No branches or pull requests

3 participants