These are chat archives for akkadotnet/akka.net

15th
Apr 2016
Steven Harrap
@stevenharrap
Apr 15 2016 04:12

Hi
Just getting deeper into Akka.net here and I want to use a router with ConsistentHashing but I'm missing a key step. This my understanding:

  1. Create several actors
  2. Create some message types that implement the IConsistentHashable.
  3. Ensure the actors will accept that message types
  4. Create a mapping scheme that tells the router which message should go to which actor <-- this bit????
  5. Create the router with the list of actors and the mapping
  6. Celebrate!

`
public class MyMessage : IConsistentHashable
{
public readonly string P1;

/* some other properties *

public MyMessage (string p1) 
{
    this.P1 = p1;
}

public object ConsistentHashKey
{
    get
    {
        return this.P1;
    }
}

}

public class ActorSystemSetup
{
public ActorSystemSetup() {

    /* make some actors for the router here */

    var actors = new string[] {/* list of actors */};
    var mapping = new ConsistentHashMapping(/* something here that associates MyMessage.P1 with one of the actors */);
    var props = Props.Empty.WithRouter(new ConsistentHashingGroup(actors).WithHashMapping(mapping));
    actorSystem.ActorOf(props, "router-name");
}

}
`

So I'm possibly one line away from awesome. Can someone help me out?

And i got the formatting wrong
Bartosz Sypytkowski
@Horusiath
Apr 15 2016 06:01
@boekabart have you created protected constrcutor with serialization info? It's one of the native Exception constructors, you should expose in your custom one
Bartosz Sypytkowski
@Horusiath
Apr 15 2016 06:07
@stevenharrap this is not how the consistent hash router works - imagine that your consistent hash can operate on some range of hashes. What CH router does, is taking group of actors, it has been given, and splits them to serve part of that hash range, so i.e. given 5 actors and possible range of all hashes 1-100, actor1 will receive all messages with hash from 1-20, actor2: messages with hash 21-40 etc.
Steven Harrap
@stevenharrap
Apr 15 2016 06:11
Ok. Not quite how I interpreted the documentation. Do you know of a router approach that would give the result I'm after?
Bartosz Sypytkowski
@Horusiath
Apr 15 2016 06:14
This can be defined by yourself. You can create an actor and define messageId-actor mapping inside of it. It's quite straightforward
Optionally I guess you may want to checkout Akka.Cluster.Sharding. It's often something that people mistake with, when they are trying to use consistent hash router.
Steven Harrap
@stevenharrap
Apr 15 2016 06:17
Ok. I was attracted to the asynchronous approach that the router takes in moving messages to destinations rather than the "one-at-a-time" approach that an actor mailbox will use.
Bartosz Sypytkowski
@Horusiath
Apr 15 2016 06:21
last time I've checked out, single actor was able to receive 3.5mln messages/sec. adding a map to it should be a heavy slowdown
Steven Harrap
@stevenharrap
Apr 15 2016 06:24
Ok - thanks Bartosz. Sounds like the router approach is overkill.
Zetanova
@Zetanova
Apr 15 2016 06:41
If a routie has some sort of interaction with other actors in the process, it would mean that the routie need to stack new incoming messages from the router. Can the routie somehow get in a bussy state?
Because if the routie is stacking up new command messages, the router most likly dont see the mailbox size anymore
Bartosz Sypytkowski
@Horusiath
Apr 15 2016 06:42
@Zetanova you could use stashing + round robin instead of smallest mailbox router?
Zetanova
@Zetanova
Apr 15 2016 06:44
I am currently using only create-child, send command + process, send response, stop
I would need something for the query-actors, if the load goes up they need to throutle quit a bit
Bart de Boer
@boekabart
Apr 15 2016 06:48
@Horusiath I haven't [created protected constructor], but do I understand correctly that akka [default serializer] can only serialize 'custom' exceptions that I've explicitly decorated to be serializable? (and if yes, will Wire fix this?)
Bartosz Sypytkowski
@Horusiath
Apr 15 2016 06:48
you could probably create demand driven pub/sub, so each subscriber must inform publisher/router that it's ready to receive the message (personally I've never used routers in production app)
@boekabart .NET have its own way of serializing exceptions based on protected constructor an ISerializable interface. All serializers wanting to serialize/deserialize exception, must work with that.
Zetanova
@Zetanova
Apr 15 2016 06:50
@Horusiath Then i will not use them :)
Bart de Boer
@boekabart
Apr 15 2016 06:51
What I notice, is that my poco with a long and an exception will serialize fine if exception==null, but not if it's populated with eg. new Exception("boomcrash")
Zetanova
@Zetanova
Apr 15 2016 06:53
@boekabart yes, just create them, or map the exception to an ErrorInfo type, that is fully seriazlizable, I needed to do this for WCF and angularJS
Bart de Boer
@boekabart
Apr 15 2016 06:54
That's what I was planning, indeed. just investigating all my use cases now to see what kind of info I need 'on the other side'
Thanks again for the help
Zetanova
@Zetanova
Apr 15 2016 06:56
@boekabart internaly are exception the best, but the going outside of the AppDomain it gets near allways problematic. Then it is better to map them.
Ralf
@Ralf1108
Apr 15 2016 08:52
public static class ActorSystemExtensions
{
public static IEnumerable<object> QueryAllUserActors(this ActorSystem system, object message)
{
using (var inbox = Inbox.Create(system))
{
system.ActorSelection("user/*").Tell(message, inbox.Receiver);
            while (true)
            {
                object response;

                try
                {
                    response = inbox.Receive(TimeSpan.FromSeconds(1));
                }
                catch (TimeoutException)
                {
                    break;
                }

                yield return response;
            }
        }
    }
}
ups...
just for reference.. yesterday I tried to query all user actors. With help from here I got this and it works nice
`public static class ActorSystemExtensions
{
public static IEnumerable<object> QueryAllUserActors(this ActorSystem system, object message)
{
using (var inbox = Inbox.Create(system))
{
system.ActorSelection("user/*").Tell(message, inbox.Receiver);
            while (true)
            {
                object response;

                try
                {
                    response = inbox.Receive(TimeSpan.FromSeconds(1));
                }
                catch (TimeoutException)
                {
                    break;
                }

                yield return response;
            }
        }
    }
}`
cant get the code to be properly formatted
`public static class ActorSystemExtensions
{
public static IEnumerable<object> QueryAllUserActors(this ActorSystem system, object message)
{
using (var inbox = Inbox.Create(system))
{
system.ActorSelection("user/*").Tell(message, inbox.Receiver);
            while (true)
            {
                object response;

                try
                {
                    response = inbox.Receive(TimeSpan.FromSeconds(1));
                }
                catch (TimeoutException)
                {
                    break;
                }

                yield return response;
            }
        }
    }
}`
Ralf
@Ralf1108
Apr 15 2016 09:17
I think yesterday I found a way to mark messages to not influence the RecieveTimeout of an actor
but i dont find it again
does anybody knows the way this worked? maybe an marker interface for the messag?
Ralf
@Ralf1108
Apr 15 2016 09:35
ok.. searching through akka source didn't discover this. Maybe I only read this in a forum entry.
so as a new feature... does it make sense to support a marker interface for messages which doesn't influence the idle timeout of the actor which was set via "Context.SetReceiveTimeout()" ?
I am thinking about management messages like "GetStatistics". If an actor recieves that message he can answer that but it should not extend the idle timeout for passivate the actor
Zetanova
@Zetanova
Apr 15 2016 09:42
@Ralf1108 the ReceiveTimeout message should be only an event and not an command. The actor should "only" react to this event and so to check it's state
Ralf
@Ralf1108
Apr 15 2016 09:43
yes but as I understand if I set a recieve timeout for an actor and the actor doesn't recieve any other message in this time a "RecieveTimout" message is send to this actor by the scheduler
I use this "RecieveTimout" message to passivate the actor
now if I send only a management message to the actor I dont want it to extend the "RecieveTimeout" timespan.
Zetanova
@Zetanova
Apr 15 2016 09:44
@Ralf1108 yes, if you need to free the actor because of some pressure, implement a shutdown command, that u can send from the coordinator
if the actor can passivate it will, if not it will ignore the shutdown and receivetimeout
even if u ignore on command like GetStatistics for the receivetimeout, the sender of GetStatistics dont know if its alive or not, the coordinator would need to reply or start the actor
Chris Ochs
@gamemachine
Apr 15 2016 09:47
Anyone have suggestions for a good azure setup for realtime/stateful/low latency apps?
Ralf
@Ralf1108
Apr 15 2016 09:53
check this scenarios:

actor A
coordinator C

Scenario 1

  • A sets RecieveTimout(5 min)
  • A recieves no message in time
  • after 5 min scheduler send A "RecieveTimout" message
  • A sends "Passivate" message to coordinator
  • ...passivating is going on

Scenario 2

  • A sets RecieveTimout(5 min)
  • A has nothing to do for 4 min
  • A recieves a "management" message (should not influence RecieveTimout but now scheduler will extend RecieveTimout to 5 min again)
  • Passivating will be postponed to further 5 min -> Scenario 2 restarts
in scenario the passivating of the actor is postponed because there a unimportant management message
Zetanova
@Zetanova
Apr 15 2016 09:55
A sets RecieveTimout(1 min) => if(--retirement == 0) Passivate()
but i would even make on ReceiveTimeout: Self.Tell(Shutdown.Instance)
On Shutdown: if(CanPassivate) Passivate()
Ralf
@Ralf1108
Apr 15 2016 09:59
so with the field "retirement " i have to handle this myself?
and when to increase the "retirement" counter? on each important message?
Zetanova
@Zetanova
Apr 15 2016 10:00
somehow to make some sort of Helper Classes that extends the actor with features
but i am not there jet by myself
Ralf
@Ralf1108
Apr 15 2016 10:02
maybe my assumption was wrong. Is the RecieveTimeout canceled before each message is handled and I have to call "SetRecieveTimeout" everytime?
Zetanova
@Zetanova
Apr 15 2016 10:02
No, it is firing until u pass Null to it
Ralf
@Ralf1108
Apr 15 2016 10:03
but if a message was handled the timeperiod is extendend to the value of the last "SetRecieveTimeout()"?
Zetanova
@Zetanova
Apr 15 2016 10:05
yes it will extened again but also mybe fired short before after the message
i am getting them in burts
and often delayed
Ralf
@Ralf1108
Apr 15 2016 10:08
ok.. my idea was only to not extend the timeout period if message with specific marker interfaces were handled
Ralf
@Ralf1108
Apr 15 2016 10:20
with "system.ActorSelection("user/*")" I only get the first hierarchy level of the actors
is there a way to specify all actors below users with all children?
and subchildren and grandchildren and so on ....
Vagif Abilov
@object
Apr 15 2016 10:41
Hello, now with deprecation of PersistentViews I am a bit lost about capabilities to monitor state changes of persistent actors. We want to build a Web site that visualizes both journals and snapshots, i.e. it will display the flow of state changes across all actors (possibly also state snapshots). I've found a few examples using SingalR but they were limited to receiving events for some specific actors. But is there a way to receive system-wide state changes for persistent actors?
Bartosz Sypytkowski
@Horusiath
Apr 15 2016 10:43
@Ralf1108 AFAIK there has been implemented marker interface to mark messages, which are not supposed to break receive timeout. However it may be not included in the latest release.
@object persistent views will be obsoleted in the favor of akka.persistence.query, which will allow to build streams on top of event journals - depending on the journal, you will be able to track mulitple different persistence ids with it
Vagif Abilov
@object
Apr 15 2016 10:48
@Horusiath and until Persistence.Query is ported there is no built-in way to track persistence changes across multiple actors? Would you recommend reading journals and snapshots right from the physical data store (i.e. SQL Server) or there are less dirty ways?
Bartosz Sypytkowski
@Horusiath
Apr 15 2016 10:49
there is persistent query mechanism for sql-based journals, standard message based, but I'm hoping to obsolete it once streams + persistence query will come out
Ralf
@Ralf1108
Apr 15 2016 10:50
@Horusiath thx for the info! can you give me a hint of the name from the marker interface?
Bartosz Sypytkowski
@Horusiath
Apr 15 2016 10:51
@Ralf1108 this is the PR: akkadotnet/akka.net#1835 not merged yet
Jeroen de Haas
@dajero
Apr 15 2016 11:09
I have created a server-client system with Akka.Remote and I am wondering what the best way is to disconnect a client from the server without seeing DissociatedExceptions in my server's log
Ralf
@Ralf1108
Apr 15 2016 11:19
yes... could be that I saw this yesterday.. but didn't remember it correctly :-)
Vagif Abilov
@object
Apr 15 2016 11:42
@Horusiath you mentioned "persistent query mechanism for sql-based journals", can you please point me to some docs or examples that use it?
Vagif Abilov
@object
Apr 15 2016 12:14
I guess it must be Akka.Persistence.Sql.Commons.
Chris G. Stevens
@cgstevens
Apr 15 2016 13:47
Akka.Cluster.Tools question.
I am doing the following and I expect that if I kill off the remote actor that it would trigger the Terminated message but it does not seem to be doing that.
Receive<ClusterManager.SubscribeToManager>(ic =>
            {
                Program.MyActorSystem.Settings.InjectTopLevelFallback(ClusterClientReceptionist.DefaultConfig());
                clusterClient = Program.MyActorSystem.ActorOf(ClusterClient.Props(ClusterClientSettings.Create(Program.MyActorSystem)));
                Context.Watch(clusterClient);
                clusterClient.Tell(new ClusterClient.Send(ActorPaths.ClusterManagerActor.Path, new ClusterManager.SubscribeToManager()));
            });

            Receive<Terminated>(ic =>
            {
                _logger.Info("Address Terminated: {0}", ic.AddressTerminated.ToString());
            });
Kris Schepers
@schepersk
Apr 15 2016 14:26
Any idea when akkadotnet/Akka.Persistence.SqlServer#24 will be merged and a new nuget package will be published?
Bartosz Sypytkowski
@Horusiath
Apr 15 2016 15:24
@object akkadotnet/akka.net#1306
John Nicholas
@MrTortoise
Apr 15 2016 19:54
has anyone run the cluster sample recently? I just grabbed it and it seems liek the protobuff nuget package stuff is fubar ... just me?
John Nicholas
@MrTortoise
Apr 15 2016 20:07
the protobuf nuget has no dll in it :/
John Nicholas
@MrTortoise
Apr 15 2016 21:25
am i going insane?