These are chat archives for akkadotnet/akka.net

6th
Sep 2016
Alex Michel
@amichel
Sep 06 2016 10:24
I have similar question. I need to run thousands of actors that recalculate state 2-3 times a second and publish updates to ui (vis signalr).
Another use case is heavy batch that needs to process 10s of thousands of transactions every minute. It also needs to be precise so it runs as early in the start of next minute as possible (at round minutes).
Bartosz Sypytkowski
@Horusiath
Sep 06 2016 10:33
@qwoz you can use akka and utilize some of it's scheduling capabilities - however akka scheduler is oriented around short time intervals (hours at most). To make it daily, you'll need to combine it with something else (like akka + quartz.net: there's already some plugin for that).
@amichel processing power of actors is usually enough, more often is problem with underlying data storage (I guess you're have one for transactions) and custom code - particularly using Akka.NET anti-patterns that can cause performance drop
also precise execution (within minute constraints) can be matter of discuss, as requests that are incoming too fast to be processed right away are usually queued by actor's mailbox - if there is too much of them, they may fail to satisfy constraint. Good part is that in akka you can use various ways of prioritizing both incoming messages based on type and CPU availability to certain actors if needed.
Alex Michel
@amichel
Sep 06 2016 10:39
Thanks. What about the first use case with publishing updates to ui twice a second?
Bartosz Sypytkowski
@Horusiath
Sep 06 2016 10:40
it's more a matter of your UI framework ;) I don't see, why it might be a problem
Alex Michel
@amichel
Sep 06 2016 10:42
I see. So no issue to run 10k actors at that speed in terms of scheduler?
Vagif Abilov
@object
Sep 06 2016 10:43
Both Scala and Akka.NET documentation states that when an actor is about to be stopped, it gets a chance to complete the message being currently under processing. But what if the message processing takes long time or even worse - the actor hangs while processing that message? Are there any timeout rules applied in such case?
Bartosz Sypytkowski
@Horusiath
Sep 06 2016 10:46
@amichel depending on your own code - if it's only in-memory processing, then it shouldn't be a problem.
Alex Michel
@amichel
Sep 06 2016 10:47
All in memory. Thanks
Bartosz Sypytkowski
@Horusiath
Sep 06 2016 10:47
@object in general if actor hangs, you're going to have a bad time. It's not only a problem in akka. I.e. if you're using cancellation tokens, they are also dependent on where the executing code have barriers, which checks if cancellation has been requested - so you can order to cancel a task, but already have passed a point of no return.
Vagif Abilov
@object
Sep 06 2016 10:57
@Horusiath so actor supervisor doesn't use brute force to stop the actor? It will simply wait until the actor completes the last messages, correct?
I can see advantages which such behavior, but I wonder what people usually do in such cases. Comparing to traditional OOP systems the actor system is a different beast, there is no access to threads executing actors from user code.
Bartosz Sypytkowski
@Horusiath
Sep 06 2016 11:07
@object actually actor will be stopped differently, depending on how stop occurred i.e. Context.Stop will stop an actor immediately, but I suspect, that actor will try to finish processing current message anyway
while PoisonPill will be placed on the mailbox, so actor will process every message until it reaches the poison pill
Aaron has written blog post about it: https://petabridge.com/blog/how-to-stop-an-actor-akkadotnet/
Vagif Abilov
@object
Sep 06 2016 11:16
@Horusiath Thanks!
Alex Michel
@amichel
Sep 06 2016 14:36
I am trying to play with scheduler. I use ScheduleTellRepeatedly method. The limitation I face now is that it only accepts explicit message instance and not factory. I would expect an overload with Func <object> messageFactory parameter.
Aaron Stannard
@Aaronontheweb
Sep 06 2016 17:31
@cgstevens @object we do have a Akka.Quartz plugin
@maxim-s developed it and I'm looking to use it in the project I'm working on
never used Quartz.NET before but that seems like the right answer for durable or long-term (daily / weekly / monthly) scheduling
the way that plugin is designed
is it just gives you a pre-defined Actor and some messages that can interop with an underlying Quartz.NET process
Vagif Abilov
@object
Sep 06 2016 17:34
Oh it's event updated to Akka.NET 1.1.1. Looks like this one will be our choice too.
We receive messages from RabbitMQ and we even looked at RabbitMQ plugin that supports scheduled queued messages.
But in our scenario we need to be able to update scheduled time so we want to have a better control of a scheduler than just queuing with postponed time.
So Quartz.NET + Akka.NET plugin for it seems to be the right choice.
qwoz
@qwoz
Sep 06 2016 18:00
Thanks @Horusiath -- I'm not too concerned about granularity of time (eg: being off by minutes) but rather the volume of actors that will need to be processed and where I might run into bottlenecks as a result. However, if there's no generic advice that could apply, I suppose the only thing that will identify that is actually implementing it and seeing where it might fall down so that's likely my next step.
qwoz
@qwoz
Sep 06 2016 18:08
Just a note about Quartz.NET: I tested using it to create custom schedules on a per-item basis and experienced horrible performance once the number of schedules got into some number of thousands. So it seems suitable for either a small number of items or for defining a schedule per interval you are concerned with (eg: one schedule for the "every 5 minutes" interval, one for the "every 10 seconds" interval, etc.) and then have your code lookup the objects that fit into the given interval. But unless my test was just plain wrong you're going to have a bad time with a schedule for each item you want to process if the number of items is sufficiently large.
Bartosz Sypytkowski
@Horusiath
Sep 06 2016 18:11
@qwoz maybe you can group your items? I.e. if you have 100 of events to activate at the same minute, just schedule it in quartz once, and them dispatch as 100 events in memory?
qwoz
@qwoz
Sep 06 2016 18:12
Yes, that's what I meant by doing it with intervals. One schedule for the "every 5 minutes" processing; when that triggers, your code loads up the 10,000 items that need processing every 5 minutes.
Bartosz Sypytkowski
@Horusiath
Sep 06 2016 18:12
if I remember correctly, quartz with persistence support may have such problems as it's storing each scheduled job call result in the persistent backend
qwoz
@qwoz
Sep 06 2016 18:14
It was definitely persistence that dragged it down. In-memory was orders of magnitude more performant but then you'd need to recreate the schedule every time the system restarted and it only delays the inevitable limit you'll run into.
Vagif Abilov
@object
Sep 06 2016 18:15
That's good to know. For us even a schedule per day would be sufficient but If I didn't know it could be slow I
... I'd create a schedule per item, and that could be thousands.
Damian Reeves
@DamianReeves
Sep 06 2016 18:27
Hey guys
does the current version of Akka.Remoting/Cluster support TLS. Are there any instructions on how to use secure connections between machines in Azure using IaaS
qwoz
@qwoz
Sep 06 2016 18:34
You'll probably want to create a virtual network in Azure for that and communicate over private IPs. My understanding (which may be outdated) is that you don't (yet) get TLS out of the box.
Arjen Smits
@Danthar
Sep 06 2016 18:42
@qwoz you are correct. We dont have TLS yet. The schedule is to introduce it in 1.5 when we introduce the streaming transport
Bartosz Sypytkowski
@Horusiath
Sep 06 2016 20:03
@DamianReeves TLS encryption is a feature of the underlying remote transport - I know from 1.5 this will be supported for sure. I'm not sure if Akka.IO or the latest Helios have support for it right now? @Aaronontheweb ?
other way is to apply encryption on the message serialization level - i.e. overriding default serializer to encrypt/descrypt serialized messages
Damian Reeves
@DamianReeves
Sep 06 2016 20:05
What I am really looking to do is have authentication/authorization for my actor system... i.e. only a coordinator can issue work to a worker
across VMs
Web app on 1 VM... worker(s) on another
qwoz
@qwoz
Sep 06 2016 20:34
TLS won't solve the problem of authentication; it would only ensure that messages are transported securely, even if the message originated from an unauthorized source (a non-coordinator). Can you make authentication part of the protocol? The message from the coordinator could use HMAC that the worker could validate and reject the message if the message doesn't check out.
Something akin to https://jwt.io/
Damian Reeves
@DamianReeves
Sep 06 2016 20:38
Ok. I see. And Akka does nothing special to inject Claims into message pipelines like ASP.NET would for example
Is this kind of behavior typically handled at the Actor level... i.e. coordinator or is inheritance or processing pipelines the way it is usually handled?
Bartosz Sypytkowski
@Horusiath
Sep 06 2016 20:41
@DamianReeves if you need some kind of extra behavior to be applied on any/choosen message kinds, you can override AroundReceive method of an actor - it's a hook, that gets called before Receive itself will occur
Damian Reeves
@DamianReeves
Sep 06 2016 20:53
ok... cool thanks. Signing with something like a JWT token amounts to putting an envelope around outbound messages... is this typically handled by people per message or do I somehow hook into an Akka system message? (I'm just trying to avoid reimplementing the wheel and I can't be the first person to need this)
Bartosz Sypytkowski
@Horusiath
Sep 06 2016 21:18
I would do that by wrapping custom message i.e. actorRef.Tell(new Authenticate(credentials, actualMessage)) and then unwrap and authorize it in AroundReceive - if auth fails, send back authentication failure. If it passes - unwrap the nested message and send in to actual receive message.
this way while message needs to be enveloped with Authenticate to be send with tell, but on the actor side it's actually transparent
Damian Reeves
@DamianReeves
Sep 06 2016 21:20
sounds straightforward and clean... thanks
Aaron Stannard
@Aaronontheweb
Sep 06 2016 22:20
@Horusiath @DamianReeves nope, neither supports TLS right now
1.5 will though