These are chat archives for akkadotnet/akka.net

11th
Dec 2017
jalchr
@jalchr
Dec 11 2017 08:42
Some additional notes, my applications are CPU and Network intensive apps. It is typical to have 100% CPU and 100% Network utilization, most of the time.
Perhaps this effects how akka.net communication works and causes this ... perhaps
Bart de Boer
@boekabart
Dec 11 2017 08:57
@ that, I sometimes think Akka.Net needs a 'priority' system for actor mailboxes for such high-load cases - some actors are simply more time-critical than others. cc @Aaronontheweb
Stefano
@delfuria
Dec 11 2017 10:25
Priority Mailboxes are already available
http://getakka.net/articles/actors/mailboxes.html
anthonyhawes
@anthonyhawes
Dec 11 2017 12:08
I don't think priority mailboxes would solve the time-critical actor problem in high load cases. A priority scheduler would be needed to give those actors a larger "slice" of message processing
Vagif Abilov
@object
Dec 11 2017 15:12
I am checking our cluster sharding event journal, and it has very small number of rows. And the snapshot store that we created for cluster sharding is always empty. So I wonder if there's any need for a snapshot store for cluster sharding. Can there ever be an attempt to create a snapshot? And is there ever need to cleanup the event journal for cluster sharding? Can it grow big (I suppose it doesn't have autocleanup).
Bartosz Sypytkowski
@Horusiath
Dec 11 2017 16:25

@object if you don't have remember-entites flag set, cluster sharding won't produce too much events. Snapshot store will be used (by default) every 1000 consecutive sharding events stored, but this applies if shard coordinator will live long enough to produce that 1000 events within a single incarnation.

Also I hope to be able to finish DData-based cluster sharding soon (see akkadotnet/akka.net#3199). With it, event journals will no longer be needed.

It actually already works, but I need to fix tests.
wilddeveloperappears
@wilddeveloperappears
Dec 11 2017 18:31
@Horusiath can I set them up programatically? Or does it have to be through HOCON config? I want to pass a function to the initial logger.
Vagif Abilov
@object
Dec 11 2017 19:12
Thanks @Horusiath. We recently had weird experience with our cluster when nodes were not able to form a single cluster continuously logging "trying to register... but no acknowledgement" until we deleted whole sharding event journal (there were only about 80 rows in it). And if DData implementation is around the corner, we should not probably spend much time on the investigation of this failure.
Bartosz Sypytkowski
@Horusiath
Dec 11 2017 19:37
@wilddeveloperappears if I remember right, you should be able to just subscribe to System.EventStream.Subscribe(actorRef, typeof(Akka.Event.LogEvent))
wilddeveloperappears
@wilddeveloperappears
Dec 11 2017 19:37
I'm currently investigating doing hocon changes to solve the problem.
Bartosz Sypytkowski
@Horusiath
Dec 11 2017 19:38
@object this sounds like an issue described by @zbynek001 (see: https://github.com/akkadotnet/akka.net/issues/3204#issuecomment-350274096) - regarding ddata, remember that PRs can take some time.
wilddeveloperappears
@wilddeveloperappears
Dec 11 2017 19:40
I've retro-fitted NLog into a project I'm working on with hundreds of classes all separated out into projects. They all fed into one log file and now I have them filtering to several based on their namespace. Using Akka in this model is broken because the Akka loggers are in a separate namespace from the project they're logging for.
Bart de Boer
@boekabart
Dec 11 2017 19:47
@delfuria That's something else - those allow messages to overtake each other. I'm talking about actors whose 'inbox' gets processed with priority over other actor's inboxes.
@anthonyhawes not a larger slice, but when the scheduler decides what to do next, it should 'prefer' to do the High Prio tasks, always.
(so it's important that there sometimes/often are none such)
This can be used in 'streams' (that are not built using Akka.Streams) as well to prevent having to use backpressure explicitly - just give the 'downstream' actors increasing priorities
Vagif Abilov
@object
Dec 11 2017 21:36
@Horusiath sounds similar, but I didn't quite understand "On persistent plugin side, properly using Serialization.SerializeWithTransport method and passing transport context". Does this mean that there is a problem with SqlServer persistent plugin which we are using (and which apparently does not pass transport context)?
Bartosz Sypytkowski
@Horusiath
Dec 11 2017 21:37
@object more a problem with how akka.net serialization handles actor refs (not visible in short living cases like remoting, but probably hurting persistence)