These are chat archives for akkadotnet/akka.net

19th
Apr 2016
eyantiful
@eyantiful
Apr 19 2016 07:24
Hi,
Any sample on how to send Actor (Initiating actor in choreography) inside a meesage in Cluster environment?
Thanks
Christian Sparre
@christiansparre
Apr 19 2016 08:30
For a monitoring solution for our services (not using clustering), what would be the best way to present a "list/tree" of actors of a local actorsystem. Having each actor respond to a "getchildren" message or is there a way to ask the actorsystem this? Is there a way to traverse the actor tree?
Zetanova
@Zetanova
Apr 19 2016 08:39
@christiansparre the get list/tree its the same as to work with system file directories. You need to ask each folder for the child-items. But i dont know if there is a system message for doing it like Akka.Actor.Identity
Arjen Smits
@Danthar
Apr 19 2016 08:42
There is no officially supported way of doing this. But there is a hacky one.
Lejdholt
@Lejdholt
Apr 19 2016 08:42
Hi, AroundReceive for UntypedActor allways returns true and ReceiveActor inherites from UntypedActor without changing this behavior. Shouldn't ReceiveActor return false for AroundReceive if for some reason the message wasn't handled by a Receive function defined in a ReceiveActor?
Arjen Smits
@Danthar
Apr 19 2016 08:47
@christiansparre check out this repo by @rogeralsing https://github.com/rogeralsing/Beacon
The actor in there illustrates a way you can "explore" your actorsystem.
However once again. this is not officially supported stuff. But it should give you a nice sample on how you can do this.
basically what it boils down to is you recursively apply an Identify message on an ActorSelection with wildcard
Problem is, you never know when you are done. So running this could kill your cluster :P because you;d end up continually spamming it with identify messages.
But it you could tweak it with clear end-conditions, or be able to restrict it parts of your cluster only. It could be the basis of a nice tool.
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 09:02
@Lejdholt it's a very good notice.
could you set that as an issue on github?
Lejdholt
@Lejdholt
Apr 19 2016 09:03
Was hoping it was me who didn't understand ;P. But yes, I'll do that.
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 09:06
@eyantiful since you can send message through cluster in multiple ways, you need to be more precise. There are few various examples here i.e. cluster section from core repo and cluster web crawler
Lejdholt
@Lejdholt
Apr 19 2016 09:10
@Horusiath here is the new issue akkadotnet/akka.net#1894
Jeff Cyr
@JeffCyr
Apr 19 2016 09:14
@Lejdholt @Horusiath I think Unhandled(object msg) is called somewhere else in ReceiveActor
eyantiful
@eyantiful
Apr 19 2016 09:15
@Horusiath sorry for the minimalism.
I have a custom serializer (ProtoBuf.Net) for type Message.
Message has (among others) IActorRef property for the initiator actor.
In the samples you mentioned the default serializer is used as far as i can tell.
Might be ISurrogated interface which should be surrogated?
I guess the question is more is passing IActorRef around good practice?
In a low-latency application what is the overhead of the resolving for each message?
Lejdholt
@Lejdholt
Apr 19 2016 09:20
@JeffCyr If I want to log handled messages (commands) to a message store in my ReceiveActor without doing it in every receive function, how would I do that? I thought I could use AroundReceive for this, guess not. Feels a bit inconsistent but I think i'm missing something.
Jeff Cyr
@JeffCyr
Apr 19 2016 09:23
@Lejdholt Do you expect an actor to receive a lot of unhandled messages? Why not log every messages?
Lejdholt
@Lejdholt
Apr 19 2016 09:27
@JeffCyr No but I dont want to store commands that wasn't handled. Storing commands are for followup, what command resultet in that event, through correlationids and causationids
Artur Karbone
@ArturKarbone
Apr 19 2016 09:28
Is there a more advanced way to control ITellScheduler? Cron-like for instance. Currently ITellScheduler provides initial delay and iterval.
I want something like once at 2AM during workdays, stuff like that. Thanks
Lejdholt
@Lejdholt
Apr 19 2016 09:28
logging commands to a "normal" log is already done in the parent actor.
Jeff Cyr
@JeffCyr
Apr 19 2016 09:32
@ArturKarbone Not sure if this is production ready, but I think you are looking for https://github.com/akkadotnet/Akka.Quartz.Actor cc @maxim-s
Artur Karbone
@ArturKarbone
Apr 19 2016 09:36
@JeffCyr i think this is what i need. Thanks
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 09:53
@eyantiful in order to serialize IActorRefs, serializer must support surrogates (both Wire and JSON.NET do), otherwise you'd need to pass it i.e. string determining path to an actor, and then resolve it by yourself.
passing IActorRef is good, if used when necessary. Also how low-latency do you mean?
eyantiful
@eyantiful
Apr 19 2016 10:26
@Horusiath we should support 15k concurrent msgs in under 100ms.
When you say resolving do you mean ActorSelection?
Jeff Cyr
@JeffCyr
Apr 19 2016 10:28
@eyantiful Are you able to batch messages? Akka.Remote cannot handle 150K msg/sec
We are working on increasing the performance of Akka.Remote in v1.5
eyantiful
@eyantiful
Apr 19 2016 10:32
@JeffCyr are you talking from single node? the figures are for the cluster as a whole.
@JeffCyr Im currently POC to see how far can we go with minimum nodes in order to asses cluster size...
Jeff Cyr
@JeffCyr
Apr 19 2016 10:40
@eyantiful Yes I meant for a single node, I made a benchmark with two nodes on the same machine on loopback, I could get ~6K msg/sec
On v1.5 we were at 100K msg/sec for the same test, and there were still room for improvements
eyantiful
@eyantiful
Apr 19 2016 10:44
@JeffCyr Default serializer change ?
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 10:45
@eyantiful actor system on a single machine (8 cores) can serve around 20-27mln msg/sec - this can be ofc slowed significantly by things such as persistence, but it also points how important local affinity of actors is
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 10:50
also for communication between nodes, take a look at Wire - it supports everything, default akka serializer should support and has quite good performance - you can see some comparison here
Vagif Abilov
@object
Apr 19 2016 10:54
I get exception while executing TakeSnapshot command for persistence actors implemented in F#:
"Unable to cast object of type 'Akka.Serialization.WireSerializer' to type 'Akka.Serialization.NewtonSoftJsonSerializer'."
System.InvalidCastException: Unable to cast object of type 'Akka.Serialization.WireSerializer' to type 'Akka.Serialization.NewtonSoftJsonSerializer'.
at Akka.Persistence.FSharp.FunPersistentActor`3.OnCommand(Object msg)
at Akka.Persistence.UntypedPersistentActor.ReceiveCommand(Object message)
at Akka.Persistence.UntypedPersistentActor.Receive(Object message)
at Akka.Actor.ActorBase.AroundReceive(Receive receive, Object message)
at Akka.Persistence.Eventsourced.<ProcessingCommands>b__90_0(Receive receive, Object message)
at Akka.Persistence.Eventsourced.AroundReceive(Receive receive, Object message)
at Akka.Actor.ActorCell.ReceiveMessage(Object message)
at Akka.Actor.ActorCell.Invoke(Envelope envelope)
I inspected Akka code and apparently this line fails:
let serializer = UntypedActor.Context.System.Serialization.FindSerializerForType typeof<obj> :?> Akka.Serialization.NewtonSoftJsonSerializer
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 10:55
@object which version of Akka.FSharp are you using?
Vagif Abilov
@object
Apr 19 2016 10:55
1.0.7
Jeff Cyr
@JeffCyr
Apr 19 2016 10:55
@eyantiful Yes I was using Wire
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 10:55
ok, this is a bug
Vagif Abilov
@object
Apr 19 2016 10:55
I have configured Wire as serializer, and as you can see that it casts to Newtonsoft.Json
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 10:55
I thought, we removed that line some time ago
Vagif Abilov
@object
Apr 19 2016 10:57
So the workaround is to get rid of this line and compile from sources?
Zetanova
@Zetanova
Apr 19 2016 10:57
This GC Collections test of PerfUtil for Gen0-2 looks interesting
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 10:59
@object yes, cause this line was part of workaround, we've made for json.net not being able to properly deserialize some of the f# types
Vagif Abilov
@object
Apr 19 2016 11:04
I see. Should I create an issue for that or you will take care of this?
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 11:04
please set an issue, I have a limited time for last few months and I could forget that
Vagif Abilov
@object
Apr 19 2016 11:06
OK. Should I submit a PR if this is only about removing the line? (If the fix requires a bigger effort, I am afraid I am too new to internals to handle it quickly).
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 11:07
as you'll see this is not only a single line
but you could play with it anyway
Vagif Abilov
@object
Apr 19 2016 11:07
Yes I already see it's not a single line. But I'll see what I can do.
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 11:08
Akka.FSharp API is small, and part of responsible for serialization hack is even smaller
Vagif Abilov
@object
Apr 19 2016 14:50
Further investigating F#/Wire persistence problem. It's not only Akka.Persistence.FSharp but also Akka.FSharp that has expectations about JSON.NET as the serializer.
And there is tryDeserializeJObject that is dependent on Newtonsoft.Json.Linq.JObject etc.
But I am not able to provoke an error if I get rid of this stuff and replace with general Akka.Serializer type and FromBinary method call.
So if you are aware of some test that shows necessity for tryDeserializeJObject let me know. As for now, I got rid of this function and its calls and my persistent actors seem to work (I also tested them with the F# persistence example included in Akka solution).
to11mtm
@to11mtm
Apr 19 2016 17:09

Hey folks, I have a question about the Simple.Cluster.Transformation sample. I Attempted to set it up such that I have the 'backends' and the frontend running on a second computer (server) , and the client computer is just running a frontend. If I shut down the client, I get some complaints that it is unreachable on the server, but eventually the auto-down-unreachable downs them. If I bring the client back up, everything's back to normal.

However, if I shut the SERVER down, The client can never talk to the server again, even if I bring the server back up... Any ideas as to what I'm doing wrong?

My HOCON looks like this:

akka {
            actor {
              provider = "Akka.Cluster.ClusterActorRefProvider, Akka.Cluster"
            }

            remote {
              log-remote-lifecycle-events = DEBUG
              helios.tcp {
                hostname = "NODE" //CLIENT, or SERVER, depending on where it is run
                port = 65530
              }
            }

            cluster {
              seed-nodes = [
                "akka.tcp://ClusterSystem@SERVER:2551",
                "akka.tcp://ClusterSystem@SERVER:2552"]

              auto-down-unreachable-after = 2s
            }
          }
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 17:20
@to11mtm in order to join the cluster, node must know at least one other node being part of it already. Quite probably in your example, server is the node which establishes a cluster, while client is the one which tries to join it. Since node cannot join to cluster, because it's connection is unreachable (server if down), it's marking it as a failing endpoint
Kamil Wojciechowski
@aph5nt
Apr 19 2016 17:26
huston... I decided to create new project and use akka1.0.7 + F#. I have created a dummy persistance actor ( https://gist.github.com/aph5nt/8616368185202fcc58808faa82e0fb41) and I got the following error
System.MissingMethodException : Method not found: 'Void Aggregate3..ctor(!2, Microsoft.FSharp.Core.FSharpFunc2<Eventsourced`3<!0,!1,!2>,Microsoft.FSharp.Core.FSharpFunc2<!2,Microsoft.FSharp.Core.FSharpFunc2<!1,!2>>>, Microsoft.FSharp.Core.FSharpFunc2<Eventsourced3<!0,!1,!2>,Microsoft.FSharp.Core.FSharpFunc2<!2,Microsoft.FSharp.Core.FSharpFunc2<!0,Microsoft.FSharp.Core.Unit>>>)'.
at CryptoGames.Game.Mines.Actors.Runa
I have also tried with 'normal' functions declarations ( eg. let execute mailbox state command = () )
did anyone have the same problem ???
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 17:31
@aph5nt this sounds like some versioning problem on the F# side (like most of the F# MissingMethodException do)
Kamil Wojciechowski
@aph5nt
Apr 19 2016 17:39
@Horusiath runtime is set to 4.4.0.0 and im targeting framework 4.5.2 + referenced fsharp.core from packages (instead of program files)
ok, i will create new standalone console proj
and check it again
to11mtm
@to11mtm
Apr 19 2016 17:51
@Horusiath Is there a way to attempt to 're-join' without restarting the entire actorsystem?
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 17:52
you need to know the list of nodes, that will be used to join/create the cluster
Kamil Wojciechowski
@aph5nt
Apr 19 2016 17:53
@Horusiath ok, in f# console app it works
Bartosz Sypytkowski
@Horusiath
Apr 19 2016 17:56
one of the common patterns is to have at least single node that is serves only as connection endpoint with well known address. It doesn't need to perform any work out there, it just needs to be present (see lighthouse project)
to11mtm
@to11mtm
Apr 19 2016 18:07
@Horusiath : I will give that a try. As I'm learning the clustering pieces and moving forward, I'm continually reminded of your blog post comment about monads =)
to11mtm
@to11mtm
Apr 19 2016 19:09
@Horusiath : THANK YOU! Lighthouse as the middleman does the trick like a charm
Kamil Wojciechowski
@aph5nt
Apr 19 2016 19:22
@Horusiath it was R# issue :(
ilhadad
@ilhadad
Apr 19 2016 22:25

Guys I am having an issue with with an ask. This is the code making the ask. This code resides in one node:

SupervisorRegistryGetListRequest request = new SupervisorRegistryGetListRequest(Self);
            //Make the ask
            _SupervisorRegistry.Ask<SupervisorRegistryGetListResponse>(request).ContinueWith<SupervisorRegistryGetListEvent>(taskResponse =>
            {
                SupervisorRegistryGetListResponse r = taskResponse.Result as SupervisorRegistryGetListResponse;
                if (taskResponse.IsFaulted)
                {
                    return new SupervisorRegistryGetListEvent(request, r, false);
                }
                return new SupervisorRegistryGetListEvent(request, r, true);
            }).PipeTo(Self);

and the config is:

akka {
                    # here we are configuring log levels
                    log-config-on-start = off
                    stdout-loglevel = DEBUG
                    loglevel = DEBUG

          // Define an Nlog logger for the Akka system
          loggers = ["Akka.Logger.NLog.NLogLogger, Akka.Logger.NLog"]

            actor {
              provider = "Akka.Cluster.ClusterActorRefProvider, Akka.Cluster"
            }

            remote {
                            log-remote-lifecycle-events = DEBUG
                            log-received-messages = on

            helios.tcp {
                                transport-class = "Akka.Remote.Transport.Helios.HeliosTcpTransport, Akka.Remote"
                                applied-adapters = []
                                transport-protocol = tcp
                                #will be populated with a dynamic host-name at runtime if left uncommented
                                #public-hostname = "POPULATE STATIC IP HERE"
                                hostname = "127.0.0.1"
                                port = 8777
              }
            }
}

and this is the code replying to the ask resides on a different node:

            Receive<SupervisorRegistryGetListRequest>(r => HandleGetListRequest(r));
... more code here...
 private void HandleGetListRequest(SupervisorRegistryGetListRequest r)
        {
            ImmutableDictionary<MicroServices.Area,IActorRef> immutableDictOfSupervisorsActors = 
                _KnownSupervisorsActors.ToImmutableDictionary(kvp => kvp.Key, kvp => kvp.Value.SupervisorActorReference);

            r.Requestor.Tell(new SupervisorRegistryGetListResponse(r.Requestor,immutableDictOfSupervisorsActors,r));

        }

and it's config is:

akka {
                    # here we are configuring log levels
                    log-config-on-start = off
                    stdout-loglevel = DEBUG
                    loglevel = DEBUG

          // Define an Nlog logger for the Akka system
          loggers = ["Akka.Logger.NLog.NLogLogger, Akka.Logger.NLog"]

          // Enables connectivity to the remote ActorSystemBridge
          actor {
            provider = "Akka.Cluster.ClusterActorRefProvider, Akka.Cluster"
            debug {
              receive = on
              autoreceive = on
              lifecycle = on
              event-stream = on
              unhandled = on
            }

          }

          remote {
            log-remote-lifecycle-events = DEBUG
            helios.tcp {
                transport-class = "Akka.Remote.Transport.Helios.HeliosTcpTransport, Akka.Remote"
                transport-protocol = tcp
                port = 8888
                hostname = "127.0.0.1"
            }
          }
}

The receive is being triggered, however, the message never gets back to the ask. Not sure what's wrong. How can I check what is happening with the reply?

ilhadad
@ilhadad
Apr 19 2016 23:14
One more additional piece of info. The following code defines the _SupervisorRegistry IActorRef:
                        _ActorSystem.ActorSelection("akka.tcp://" + SSAActorSystem.ActorSystemName + "@127.0.0.1:8888/user/SupervisorRegistry")
                            .ResolveOne(TimeSpan.FromSeconds(3))
                            .Result;