What are the persistence journal plugins that implements Persistence Query ?
Good morning everybody. I'm evaluating akka for a project and it seems to be a good fit for now. There is one thing i cannot wrap my head around: i need to collect data from a) sockets/streams; b) by polling and push those as messages in my akka network. Having a continous task inside an actor feels wrong from reading the documentation. Should my "data aquisition" be completely separate from my akka network? Or can it be integrated somehow?
@object I am not arguing about the need for proper props but most of the time they can be made transparent.
@ChaosD That is up to you. If you can see distinct advantages with hosting your data aquisition inside an actor. Then do so. If you don't want to host it inside an actor. Then dont, and communicate with your actor system through one or more well known actor's.
so it is perfectly fine to run a neverending listener/polling task inside an actor?
using async / PipeTo
@ChaosD I don't see any reason why you would need this.
so what would be a better way to have an actor/something listen to a socket and generate messages from that ?
@Horusiath has Akka IO been obsoleted/disabled?
@ChaosD Akka.IO namespace defines methods that are already prepared to be used along with sockets - I've wrote an introductory post about that
@rogeralsing I don't know anything about it. I only know that mr. fergusson redesigned the internals to be merged somewhere in 1.5/.net core and possibly they will be working with akka-streams interface (which right now it's not fully possible due to some problems with actor termination or socket disconnection not being notified on the streams side)
@Horusiath neat, I'll check that out. Thank you
in a scenario which involves remoting between A and B, is there a mechanism in Akka to wait before the two are connected, before processing messages in B and doing an actor selection to Tell messages to A?
@paulinfrancis remote only or using cluster?
remote only
the "normal" flow is Web client calls actor in A, which remotes to B to do stuff, and B remotes back
but B also subscribes to an event stream, and if events come before A has connected, B isn't going to be able to do an actor selection on A
I could just stuff the events into a queue inside an actor in B, but that seems a bit like duplicating the already existing mailbox concept
another alternative is to just discard the events that I pick up before A connects, as they are not really needed
remoting connection is more on-demand. So you're passing fully qualified string to locate where the other actor system is. You can make sure, that there's someone listening under the path, where actor selection directs by either sending
actorSelection.Tell(new Identify(correlationId)) and waiting for ActorIdentity(correlationId, subject != null) response or timeout, or by using actorSelection.ReceiveOne(timeout) which does basically the same
Thanks, I'll look into those approaches :)
but afaik there's no way to "auto-magically" detect if they see each other, other than just periodically send that Identify request
(because if you send Identify to selection that doesn't point anywhere you can either get ActorIdentity with subject == null or just don't get anything, therefore timeout is needed)
We're currently evaluating different actor system frameworks to implement an statefull server. Anyone that understands what are the main differences/benefits/drawbacks between Akka.net and MSFT Service Fabric actor system?
@juanjoarana this is not full comparison, as my knowledge of SF is poor and there are a lot more changes between those two:
| Service Fabric Actors | Akka.NET |
|---|---|
| Proprietary / closed source | Free / open sourced |
| It's tied to Service Fabric. | Not tied to any particular platform. Can be used from any project template on any platform (Mono support). |
| It's mostly ready out of the box. | It's build for modularity. May require additional NuGet plugins and configuration to reach full potential. |
| Programming model close to OO paradigm. | Message-based programming model. More functional in nature. |
| Actor's behavior is represented as interface with async methods. | Actor's behavior is dynamic, based messages it can handle. This can change at runtime as result of handling other messages. |
| Exceptions are propagated up in the callchain, causing each actor on the path to restart. | Exceptions are contained within an actor. It's up to actor's parent to decide, how it should behave. |
| Communication through async RPC or Pub/Sub (only between actors and clients). Every request is ACKed/NACKed by default. | Basic communication through fire-and-forget messages. From there, basically any communication pattern possible: request/response, pub/sub, reactive streamming. ACK/NACK is part of the communication pattern. |
| Consistent during network partitions | Consistent or available during network paritions (you can have full control over it) |
| Actors are distributed over cluster by using paritions. You cannot guarantee that actors from different paritions will be located on the same machine. | Actors can be paritioned automaticaly by using Akka.Cluster.Sharding, but by default you place them explicitly. This allows to perform optimizations based on local affinity of actors. |
| Actors are identified by Guid, string or long | Actors are identified by URI-based actor paths with support for actor hierarchies |
Serialization through DataContractSerializer |
Current default serializer is JSON.NET. In the future it will be Wire (which is one of the fastest in .NET). You can set up your own based on message type. |
| Default persistence is state-based on the local replicated storage. | Default persistence is based on eventsourcing. No default backed, you need to plug one of your choice. |
| Cluster membership using replicated log. | Cluster memebership is based on seed nodes (nodes with well-known addresses). |
| Reentrancy only in callchain. | Actors are "reentrant" by default. This can be changed by using ReceiveAsync |
| No way to increase concurrency level of actor. | Actors concurrency can be set by using routers. |
I
@Horusiath If you add Orleans and Akka.Typed to this table it would be the great comparsion
As I know SF actors are very similar to Orleans
What a great comparison!
@alexvaluyskiy Orleans vs Service Fabric can be found here: http://richorama.github.io/2016/07/08/orleans-vs-service-fabric/
I've used this comparison to build a table
Are there any examples of resumable projections, with a persistence query, other than the one in the docs?
like a full sample project that uses it