NoSerializationVerificationNeeded
that will ofc not help if the testlatch is part of a bigger message, but if it is the root, that would make it bypass serialization in inproc systems
neat :) so for persistence, we just need to start making providers? and follow typesafes lead on how to take it out of beta (?)
beside that, I'm currently during writing some tutorial about how to write custom persistence plugins
but I think, that @Aaronontheweb or @jcwrequests may want to try to implement Cassandra plugins for Akka.Persistence
I also hope, that when it will be ready to drop -Pre flag, RavenDB and EventStore creators will want to integrate their services too
@horusiath is your SQL code on your Akka fork? I think it would be a good idea to write them for Cassandra, mongo, postgres and maybe foundation db. I think that the focus should be on the high write throughput DBs. @arronontheweb might have some during opinions about ravendb 😊.
@jcwrequests if you want to start, my sqlserver fork is not what you want (at least for now). Right now I'm hardening Akka.Persistence.Tests (they are randomly failing right now, mostly due to timeouts) and making an Akka.Persistence.TestKit to work easier with. If everything goes right, they could be released soon and then I'll prepare tutorial about how to start persistence plugin development - right now I already have sample code, but it's not commented.
By default we execute on the threadpool, so we don't own those threads.. we can also execute on the GUI thread with the synchronization context dispatcher if you want an actor that updates GUI elements. we dont own that thread either... then we have cases like the new threadpool, that can be used to give some actors a higher priority than the others, those threads are owned by whatever threadpool we use under the hood, but yes you could consider those owned threads I guess.. so we can execute ontop of whatever the current dispatcher decides to run the work on
but in short, akka never does anything to the threads, it just executes the mailbox run on whatever scheduling mechanism is there
I do have a question for the group though on how you would handle supervision in this scenario: https://gist.github.com/stefansedich/0c5e1d2ac431eccd9fed
In this scenario say DoStuff failed, I would want to restart the child, but to do that I would need to execute the Start message again to reset the internal state back to a starting point before kicking off again, what are the best ways to achieve this kind of thing?
My current solution is to pass a message to the parent, but I end up implementing my own retry and not taking advantage of the Supervisor strategy.
sorry if the example is a bit shitty :)
the child actually notifies the parent of the change and parent keeps track of state, so it it has to restart parent would need to pass down the current value.
It is a position in a stream basically.
when parent receives the IAmREadyToWork, it can pass the Start message back to the child
as the child actor will be recreated if you use Restart
never have the parent start it off
Thanks @rogeralsing that works a treat as usual there is a simple solution!
Once that happens I know the child is good and dead and it is time to give up, I would only want this on errors though not normal shutdown.
