but at some point I wonder if you're not optimizing only for the benchmark
in the case of DequeueAll, if it needs to loop and lock through all segments, there might not be a lot of gain. But it could get the entire segment as an array and work those before going to the next
1-2 weeks IIRC
and for surrogates, surrogate support is mandatory as
ActorRef needs special handling to be resolved into a real actorref.. and it can be embedded deeply inside another message
I do want to get rid of Json.NET, but most other serializers lack some features
e.g. polymorphic serialization
and what about 2nd? Don't you think we should add a globally configurable HOCON option for this? I think it's very risky that now we don't have any kind of timeout configured by default. It's not safe, if user forgot at any point to set receive timeout, his/her service could possibly hang forever
if you mean a way to ensure that no receive method runs forever.. I have looked into this, but there is no fast way to deal with it. there would need to be some supervisor thread that polls that no thread have been executing a receiveblock for too long
During the very early stages of akka.net, I put together this: https://gist.github.com/rogeralsing/8472797 it does what you want, but expensive, and the implementation would beed to be cleaned
but eventually I just moved it to separate spec class
I've seen a similar problem before, back then, it was that some static resources, like NoRouter or DefaultDeploy or whatver, was overwritten by the serializer .. e.g. some primitives took a static resource as an input argument, then the serializer overwrote the properties of the primitive, which was backed by the static resource, and tada , the static resource was corrupted
could that be a similar problem here?
e.g.
public Props() : this(Some.Static.Resource) {} then when the deserializer tried to deserialize an object with such ctor, the injected resource would be corrupted
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.