Hi, is it possible to run actors of a Cluster run on .net core and .net Framework at the same time? Heard about serialization differences, right?
Is it possible to Switch / Change serialization/deserialization to make this work?
(e.g. switching to protobuf instead)
Heard about proto.actor which is x-platform... is there a Performance comaprism available? Are These projects related?
@beachwalker serialization differences are sometimes between versions of the library, not between platforms.
@Horusiath thought about differences in .net core libs and .net framework, if same class in lib of platform is in different namespace. But there may occur also problems related to platform if using binary serialization (think of little or big endian) so the serialized class of a lib is not the only influence
Hi, What is the status of "Akka.DistributedData" ? Is there any good sample for it ?
Hello Geeks, do I need some special ACL to start an Windows service built using Akka.Remote since I will be opening port on the windows servver?
serialization differences are sometimes between versions of the library, not between platforms.
there are major serialization differences between .NET and .NET Core
default namespaces changed for built-in primitives
protobuf or MsgPack will avoid this issue @beachwalker
@jalchr I've got one example that shows an async/await API (not very good fit to communicate between actors, but good for using DData outside of an actor system): https://github.com/Horusiath/CrdtDemo . Also keep in mind that LightningDB plugin is not yet stable (its binary format will change in the future).
@Horusiath Thanks, highly appreciated
@Horusiath I'm thinking about using DData as a state holder for ensuring message delivery. So instead of scattering state in every actor, I have it centralized and cluster-ready. What's your thoughts on this ?
@jalchr DData is intended for having multiple writable replicas of the same state distributed throughout the cluster
so it's like having N copies of the same actor
but the DData data structures (CRDTs) allow for the state of all N replicas to be merged together into a consistent view of the entity as a whole eventually
but there are tradeoffs in terms of the types of things you can do with your entity's state
for instance, some of the collection data structures may not allow you to delete items from the collection (you have to use a "tombstone" instead to indicate that something has been removed)
and some of the counter data structures are monotonic (don't allow decrements)
if you're working on reliable delivery type problems
I made a YouTube video about this last year, let me see if I can grab it
in general, I recommend not using exactly once if you can avoid it
but if you really need it, that video goes through how to implement it
and the technique I use there is exactly once without strong ordering
meaning each message is delivered independently from every other message
if you need to do exactly once delivery AND preserve ordering for all messages to each individual recipient
you'd need to ditch using an AtLeastOnceDeliveryActor base class
and implement something custom where each send operation to each recipient is atomic
and any subsequent sends get queued up until the current send is ACKed
and then you can proceed from there
in a happy-path scenario the performance is probably OK
once you actually start dealing with prolonged trouble on the network though then that technique is going to result in back-ups quickly
especially if you end up with a poisoned message
I'm working on some finance applications at the moment; real-time price analysis, trading indicators, and eventually an execution engine
In the spec design I have currently we only use something stronger than at most once delivery inside the execution engine
if I miss some real-time order book events from the exchanges I'm connected to
however, if my ability to process those real-time order book events is slow
then my application can't really do its job properly
we will use the stronger delivery guarantee in the execution engine though
because my view of an account balance and the exchange's view of the account balance have to be identical
otherwise the trading algorithms are going to try to execute trades that can't be filled or might otherwise blow away the liquidity (cash-on-hand) parameters the users set... which would be bad
hi! I have a problem: there are two independent projects and I am using Akka Remoting for connection. I am also using Autofac DI. Two projects. Two actor systems. Two Autofac DI containers. Actor of the first ActorSystem calls actor of the second ActorSystem which should have constructor injection. But the first actor system doesn't know (and shouldn't know) about this dependencies. Is it possible to call this actor after resolving dependency through the second actor system?
@AnchishkinAlex are you remotely deploying those actors?
if not, then none of this stuff matters - both actors are started independently
and neither needs to know about each other's constructor arguments
they just need to acquire a remote actor reference to each other