These are chat archives for akkadotnet/akka.net

25th
Oct 2016
Amri Hidayat
@amri
Oct 25 2016 00:50
What are the persistence journal plugins that implements Persistence Query ?
ChaosD
@ChaosD
Oct 25 2016 06:52
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?
Daniel D'Agostino
@dandago2_twitter
Oct 25 2016 06:59
@object I am not arguing about the need for proper props but most of the time they can be made transparent.
Arjen Smits
@Danthar
Oct 25 2016 07:00
@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.
ChaosD
@ChaosD
Oct 25 2016 07:04
so it is perfectly fine to run a neverending listener/polling task inside an actor?
using async / PipeTo
Bartosz Sypytkowski
@Horusiath
Oct 25 2016 07:19
@ChaosD I don't see any reason why you would need this.
ChaosD
@ChaosD
Oct 25 2016 07:27
so what would be a better way to have an actor/something listen to a socket and generate messages from that ?
Roger Johansson
@rogeralsing
Oct 25 2016 07:31
@Horusiath has Akka IO been obsoleted/disabled?
Bartosz Sypytkowski
@Horusiath
Oct 25 2016 07:44
@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)
ChaosD
@ChaosD
Oct 25 2016 08:18
@Horusiath neat, I'll check that out. Thank you
Francis Paulin
@paulinfrancis
Oct 25 2016 11:07
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?
Bartosz Sypytkowski
@Horusiath
Oct 25 2016 11:08
@paulinfrancis remote only or using cluster?
Francis Paulin
@paulinfrancis
Oct 25 2016 11:09
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
Bartosz Sypytkowski
@Horusiath
Oct 25 2016 11:13
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
Francis Paulin
@paulinfrancis
Oct 25 2016 11:14
Thanks, I'll look into those approaches :)
Bartosz Sypytkowski
@Horusiath
Oct 25 2016 11:14
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)
Juan José De Arana
@juanjoarana
Oct 25 2016 13:14
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?
Bartosz Sypytkowski
@Horusiath
Oct 25 2016 14:08
@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.
stevemesser
@stevemesser
Oct 25 2016 14:55
I
Alex Valuyskiy
@alexvaluyskiy
Oct 25 2016 17:51
@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
Vagif Abilov
@object
Oct 25 2016 19:58
What a great comparison!
Bartosz Sypytkowski
@Horusiath
Oct 25 2016 20:29
@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
Jared Lobberecht
@Jared314
Oct 25 2016 22:50
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