akkadotnet/akka.net

Port of Akka actors for .NET

Bartosz Sypytkowski

@Horusiath

@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

@Horusiath here is the new issue akkadotnet/akka.net#1894

Jeff Cyr

@JeffCyr

@Lejdholt @Horusiath I think Unhandled(object msg) is called somewhere else in ReceiveActor

https://github.com/akkadotnet/akka.net/blob/fe69c8408fa5a49de4871262746d77a08e73fd2f/src/core/Akka/Actor/ReceiveActor.cs#L70

eyantiful

@eyantiful

@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

@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

@Lejdholt Do you expect an actor to receive a lot of unhandled messages? Why not log every messages?

Lejdholt

@Lejdholt

@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

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

logging commands to a "normal" log is already done in the parent actor.

Jeff Cyr

@JeffCyr

@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

@JeffCyr i think this is what i need. Thanks

Bartosz Sypytkowski

@Horusiath

@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

@Horusiath we should support 15k concurrent msgs in under 100ms.
When you say resolving do you mean ActorSelection?

Jeff Cyr

@JeffCyr

@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

@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

@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

@JeffCyr Default serializer change ?

Bartosz Sypytkowski

@Horusiath

@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

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

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

@object which version of Akka.FSharp are you using?

Vagif Abilov

@object

1.0.7

Jeff Cyr

@JeffCyr

@eyantiful Yes I was using Wire

Bartosz Sypytkowski

@Horusiath

ok, this is a bug

Vagif Abilov

@object

I have configured Wire as serializer, and as you can see that it casts to Newtonsoft.Json

Bartosz Sypytkowski

@Horusiath

I thought, we removed that line some time ago

Vagif Abilov

@object

So the workaround is to get rid of this line and compile from sources?

Andreas Dirnberger

@Zetanova

This GC Collections test of PerfUtil for Gen0-2 looks interesting

Bartosz Sypytkowski

@Horusiath

@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

I see. Should I create an issue for that or you will take care of this?

Bartosz Sypytkowski

@Horusiath

please set an issue, I have a limited time for last few months and I could forget that

Vagif Abilov

@object

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

as you'll see this is not only a single line

but you could play with it anyway

Vagif Abilov

@object

Yes I already see it's not a single line. But I'll see what I can do.

Bartosz Sypytkowski

@Horusiath

Akka.FSharp API is small, and part of responsible for serialization hack is even smaller

Vagif Abilov

@object

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

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

@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

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

Where communities thrive

People

Repo info

Activity