These are chat archives for akkadotnet/akka.net

27th
Apr 2017
fanoI
@fanoI
Apr 27 2017 10:51
Good morning!
I want to have an Actor that has the role of a Database Storage what technology is best to use? I want it to be multi-thread (the other Actors can use Ask<> to read / write data to the DB at the same time)
mwardm
@mwardm
Apr 27 2017 12:02
@fanoI (A single object-instance of) an actor is always single threaded, that's kinda the point. Multiple actors can use Ask at the same time, the request-messages will queue in the DB actor's mailbox and it will execute them one after another. If you want to execute your DB stuff in parallel then you should be doing something like creating multiple instances of the DB actor and using a router-actor to share out the incoming messages between them.
chipdice
@chipdice
Apr 27 2017 12:18
I'm using ClusterClient to send messages to ClusterReceptionists. I'm responding back to the Client with the message received as an ack. Things seem to work fine with two Receptionists running, however I'm having some difficulty with scenarios where I take down both nodes in my cluster. If I use one InitialContact, then if I take down both receptionsists and only bring up the one that is not an initial contact, then it will not get the messages which are sent (and resent due to no Ack). I would expect this because it is not an initial contact. However if I make both of them initial contacts, it looks like neither of the receptionists will get messages until Both are back online. Is this expected? What is the best way to configure so that when a receptionist comes back online the messages that I am resending due to no Acks will be received?
fanoI
@fanoI
Apr 27 2017 13:18
@mwardm yes I want to have the possibility to do select, update, delete... contemporary from more than an Actor so yes using a router actor could be the solution. What underlying technology you will use to interface with the DB in this case? Entity Framework should not be OK in this as it is not thread safe...
Guillermo
@mompox
Apr 27 2017 13:26
I just upgraded to 1.2 and I'm having issues with my unit tests.
I have some code that uses ActorSelection to obtain a reference to a "global" actor
var otherActor = Context.ActorSelection("/user/OtherActor").ResolveOne(TimeSpan.FromSeconds(5)).Result;
From my tests I use a TestProbe to create the OtherActor:
var otherActor = CreateTestProbe("OtherActor");
This was working in 1.1.3 but not in 1.2.0 (It fails in the line above when trying to resolve the actor)
Do you know how can I fix my test?
Guillermo
@mompox
Apr 27 2017 13:43
I tried it with both versions, and I am seeing that the difference is that in 1.2 TestProbe creates the actor in system instead of user:
1.1.3 {[akka://test/user/OtherActor#1609127914]}
1.2.0 {[akka://test/system/OtherActor#728329032]}
Is there any way to change it back to user?
Guillermo
@mompox
Apr 27 2017 14:03
I am using NUnit3, if it makes a difference
mwardm
@mwardm
Apr 27 2017 14:16
@fanoI I'm not a big Entity Framework user myself but the DbContext is threadsafe, no? I would have thought that in terms of getting stuff in and out of the database, you can use EF just like you would from a (by nature multithreaded) web-app.
chipdice
@chipdice
Apr 27 2017 14:48
Should I try and use SubscribeContactPoints and monitor if the actors are not available? If so, how do I filter for specific roles within the ContactPoints?
Sean Gilliam
@sean-gilliam
Apr 27 2017 15:18
iirc EF's DbContext is not threadsafe
chipdice
@chipdice
Apr 27 2017 15:59
RE: Both initial clients being online. Looks like it is working properly with my test now. Not sure what was wrong yesterday, but I guess a night's sleep fixed it
fanoI
@fanoI
Apr 27 2017 16:15
I'm a C# newbie and I've read that Entity Framework is indeed not thread safe in fact I'm asking what you use as DB "framework" in couple with Akka? Having only a DB "Actor" is too much limiting and well not "natural" having all so multi - threaded.
There is some example of Akka.Net and Database usage in multi thread scenarios?
mwardm
@mwardm
Apr 27 2017 17:01
@fanol @sean-gilliam Sorry - don't know what I was on! What I was meaning to say is that it's the DbContext that's not threadsafe, but that you can use Entity Framework in a multi-threaded way by just instantiating a DbContext per thread.
mwardm
@mwardm
Apr 27 2017 17:14
However, it sounds a bit like you're trying to slot Akka.Net into your application while still considering the database to be the master (and synchroniser) of your state. I think you probably have to turn that on its head and consider that the instantiated actors hold the state and the database is simply keeping a backup in case things go wrong (and or allowing you to unload some for a while). But these are big conceptual issues and way out of my league :smile:
fanoI
@fanoI
Apr 27 2017 17:59

Yes having I have done a precedent distributed application in C and indeed I find this as "a problem" myself trying to redo thing in the same way in C# / Akk.net probably is not the best way.

My type of application is maybe different from which Akka.net is used it is particular Point of Sale in which you can have an operator (but could work in automatic mode too), should interoperate with devices sometimes connected via Network sometimes via serial port (!). For example when the Operator does login into the application I have to check in the database if it is authorized what is roles is and so on... if all is OK I create "a turnation". You will consider all this "state"?

RichardLindeberg
@RichardLindeberg
Apr 27 2017 19:56
Moving from Database centric to Actor based does require a change of architecture. You can of course read data from serial ports and make that into messages that can be sent to one or more actors for further processing. But I don't see any huge benefit in having Repository like actors that read and write in some database. It's of course doable if you need to interact with legacy systems. But the most benefit of using actors is when you need fast and fault tolerant systems. Then you don't want to make some SQL server be in the center with lot's of complex queries going on. Instead try to make the system event-sourced, you can still use SQL server if you need that for IT ops perspective. Then your actors would have the information they need and to authorize someone and you would have an actor that already has the state needed to authorize the user. As soon as your actors need to go out and talk to other systems you have a bottle neck and the system will be harder to reason about and test.