Document: calling persist() in Futures is bad

[eugenemiretsky]

When testing a persistent actor with a low throughput (one command at a time) event sometimes get "stuck" and are not processes until the next command is sent.

I suspect that it has to do with batching in EventSourced - events get batched before being sent to the persistent store. FlushBatch is getting called inside aroundReceiveComplete, which explains why the batch gets flushed when the 2nd command is sent.

Is there a way to tune, or turn off batching?

[ktoso]

• What persistence journal?
• Are you using persist or persistAsync or a mix?
• What does "low throughput" mean in your case?
• Could you explain more about what you mean with "stuck"? By "command is sent" I assume you mean "event is stored", i.e. persist call happens?

[eugenemiretsky]

1. LevelDB
2. Persist
3. low throughput - test load. Generating 1 request at a time manually.
4. By stuck I mean that all the code before persist() is executed, however none of the code in the call back is executed. The callback is executed only after I send another command that triggers another persist call.

[patriknw]

Sounds interesting. Do you have a reproducer?

[eugenemiretsky]

Working on a reproducer.
Persist is getting called in a Future. Could that be the issue?

[patriknw]

Yes, that is not allowed. Must be done in the actor's receive thread. Pipe the result of the future back to the actor and persist from receiveCommand

[ktoso]

Not a bug IMHO if persist() was called from a Future, incorrect usage though.
I added a more explicit warning about this: #21699