These are chat archives for akkadotnet/akka.net

22nd
Apr 2015
Joshua Benjamin
@annymsMthd
Apr 22 2015 00:16
I now know more about the XUnit inner working than I ever wanted to know.
Aaron Stannard
@Aaronontheweb
Apr 22 2015 00:17
@annymsMthd if you stick around on Akka.NET long enough you'll use that sentence for a lot of different things
oh hey, here's how the JVM type system does X!
:P
Joshua Benjamin
@annymsMthd
Apr 22 2015 00:17
lol
Joshua Benjamin
@annymsMthd
Apr 22 2015 01:28
@smalldave Did you see @Aaronontheweb and my conversation about the MultiNodeTestRunner this morning?
Nikita Tsukanov
@kekekeks
Apr 22 2015 05:54

and small examples do fit nicely in the comments - we do that in a few places

Oh, yeah, I remember that ReSharper tooltip that covered almost entire 27" screen with example from Xamarin.Forms while I was typing.

SQL-server Akka.Persistence Impl

I'm wondering, why the code is so MSSQL-specific. It was easy just to use something lightweight like linq2db and get support for almost all database engines.

Nikita Tsukanov
@kekekeks
Apr 22 2015 09:05
Is there any way for an actor to have "wildcard" address? I. e. I want to have some EntityLazyLoaderActor to recieve all messages to /user/entities/* and then load an actor from persistent storage if it's not already in the memory
Natan Vivo
@nvivo
Apr 22 2015 09:38
I think you can do exactly that with actorselection to send messsages. But Akka cannot start actors by itself only by the path
Nikita Tsukanov
@kekekeks
Apr 22 2015 09:39

can do exactly that with actorselection

Nope, ActorSelection does exactly the opposite

Natan Vivo
@nvivo
Apr 22 2015 09:39
?
Roger Johansson
@rogeralsing
Apr 22 2015 09:40
ah you want to "intercept" the path and then start actors that arent started, right?
Natan Vivo
@nvivo
Apr 22 2015 09:40
Exactly that = use /path/to/manyactors/*
Nikita Tsukanov
@kekekeks
Apr 22 2015 09:40
Yup
Roger Johansson
@rogeralsing
Apr 22 2015 09:40
like a proxy
Nikita Tsukanov
@kekekeks
Apr 22 2015 09:40
exactly
If you have, like, 1KK entities it would take a lot of time to load them from the storage
Roger Johansson
@rogeralsing
Apr 22 2015 09:41
imo, easiest way, make a proxy that acts like the consistent hash router. but with the ability to start actors also
all messages goes to the same actor, and then use a property of the messages to identify what child to route to
Natan Vivo
@nvivo
Apr 22 2015 09:44
This looks like the concept from orleans right?
Nikita Tsukanov
@kekekeks
Apr 22 2015 09:44
So I'm stuck with old pattern of having ISmthManager that asks you for an id of that something in every call
meh
Quite kills the idea of just passing ActorRef around
Natan Vivo
@nvivo
Apr 22 2015 09:45
I think you can do that with rogers idea
Ask a single actor for a message that contains an actorref
Let that single actor give you the reference somehow
Nikita Tsukanov
@kekekeks
Apr 22 2015 09:47
And then be unable to unload that actor after inactivity timeout
but might just work in most cases
Since having an actor is cheap anyway
Natan Vivo
@nvivo
Apr 22 2015 09:47
You can unload with SetTimeout and watch in the parent
Roger Johansson
@rogeralsing
Apr 22 2015 09:48
Akka does not support the concept of virtual actors, we follow the JVM impl, they are looking into that on their side.. but as of now, there is no "on demand" activation of actors
Nikita Tsukanov
@kekekeks
Apr 22 2015 09:48
Yup. Ask the parent for the reference, timeout expired, actor died, ActorRef is void
So these "ondemand" actors should live forever
Is it actually a good idea to have an actor for every entity in the system?
Natan Vivo
@nvivo
Apr 22 2015 09:50
This is the orleans concept, akka is different. But both can achieve similar results. Looks like you want a specific solution, not a specific goal
Nikita Tsukanov
@kekekeks
Apr 22 2015 09:50
Or just go with instances of UserManagerActor routed via consistent hash
Roger Johansson
@rogeralsing
Apr 22 2015 09:51
depends on its responsibillities, if the actor is a heart beat creator for a heart machine, i'd say yes :) if it's a business entity / aggregate root, then no
Natan Vivo
@nvivo
Apr 22 2015 09:51
Honestly I have a hard time to see the benefit of the virtual actor model for regular services.
Nikita Tsukanov
@kekekeks
Apr 22 2015 09:52
I want to try event sourcing, so I'll need to have a PersistentActor for everything
just not sure that it should be exposed to the system or just incapsulated inside the parent that manages its lifetime
Natan Vivo
@nvivo
Apr 22 2015 09:55
You don't necessarily need every entity of your system to be a persistent actor to do event sourcing, that's the point
This is a design choice
Nikita Tsukanov
@kekekeks
Apr 22 2015 09:56
If entities are incapsulated inside SmthManagerActor it's just implementation detail.
Hm. It's actually not a "virtual actor" it's just something like url rewriting
Roger Johansson
@rogeralsing
Apr 22 2015 09:59
There is the concept of Virtual Containers in Akka. the RemoteDaemon uses that for remote deployed actors, that pretty much do what you want.. but youd have to do all the plumbing yourself to implement a custom container for that.. but a good start is to look at the RemoteDaemon
Nikita Tsukanov
@kekekeks
Apr 22 2015 10:00
wow
thanks
Roger Johansson
@rogeralsing
Apr 22 2015 10:00
but this is way down in the dark dungeons of akka. not user facing standard api
Nikita Tsukanov
@kekekeks
Apr 22 2015 10:01
I might just stick with something that wraps a message into another (containing path information) and passes it to a standard ActorRef
Shouldn't be that hard
Natan Vivo
@nvivo
Apr 22 2015 10:01
This looks like one of those cases where it's better to understand "how should I do this in Akka" then trying to make akka match your mind model. But it's a nice exercise..
Nikita Tsukanov
@kekekeks
Apr 22 2015 10:04
It's kinda hard after you had a system that used AMQP's topic exchanges for the same thing )
Nikita Tsukanov
@kekekeks
Apr 22 2015 10:13
Well, having a bunch of SmthManagerActor routed with consistent hash is much more cluster-friendly
So exposing an ActorRef to underlying actors is probably a bad idea
Bartosz Sypytkowski
@Horusiath
Apr 22 2015 10:21
@kekekeks take a look here - I think, I've implemented there what you want
you have concept of AggregateRoots accessed indirectly by AggregateCoordinator actors
coordinator works similiar to the consisent hash router, but it's able to manage lifecycle of it's children
Nikita Tsukanov
@kekekeks
Apr 22 2015 10:24
And coordinators themselves can be routed via consistent hash
looks great
Bartosz Sypytkowski
@Horusiath
Apr 22 2015 10:25
  • if there is a message addressed to persistent actor which doesn't occupy memory it becomes recovered from persistent storage
  • also when children count overcomes specified threshold, some of them become harvested/killed (since their state is already persisted)
Nikita Tsukanov
@kekekeks
Apr 22 2015 10:26
Exactly what I'm looking for
Any plans of publishing it as NuGet package?
Bartosz Sypytkowski
@Horusiath
Apr 22 2015 10:31
I think, that this issue should be solved in scope of Akka.Cluster.Sharding plugin, when it comes out
my solution is good for copy/pasting (all code from repo is MIT-licensed) or to be described as a design pattern, but I think it's not sufficient and configurable enought to have it's own NuGet package
David Smith
@smalldave
Apr 22 2015 12:41
@annymsMthd problems with the multi-node testing? not got far with the documentation I'm afraid
Roman Golenok
@shersh
Apr 22 2015 13:12
Hi all. What if I need to create push-notification backend with different push services (WinPhone, APS, Android service, etc.). So what will be better:
  • Have coordinator, that have refs to workers and each worker have refs to actors which implements own service deliver
  • Have coordinator, that have refs to specified Actors routers that implements service.
    ?
Nikita Tsukanov
@kekekeks
Apr 22 2015 13:12
Just use PushSharp, it already has that functionality
It doesn't actually have built-in worker support, but the first variant can be easily implemented with it
Roman Golenok
@shersh
Apr 22 2015 13:15
@kekekeks thanks, I did see that project. My question is just for self-learning
Joshua Benjamin
@annymsMthd
Apr 22 2015 16:02
@smalldave About running the Node tests in an AppDomain instead of starting a new process for each
Joshua Benjamin
@annymsMthd
Apr 22 2015 16:11
@smalldave @Aaronontheweb My local branch now uses AppDomain for the individual nodes in multinode tests and i can debug the process without additional addons. Xunit actually does this under the covers when it runs a test suite. It has helped me spot a few race conditions going on. I am also seeing an issue with the ClusterDeathWatchSpec though. The node that was downed by the leader isn't recognizing that it itself is down and therefore isn't shutting down.
Nikita Tsukanov
@kekekeks
Apr 22 2015 18:04
Dumb question. How does Akka.Persistence deal with renamed classes/namespaces?
I've seen "$type" in snapshots with FQ type names
Bartosz Sypytkowski
@Horusiath
Apr 22 2015 18:05
It's pretty simple: it doesn't :)
That depends on used serializer (I don't remember how JSON.NET behaves in situation when $type field addresses non-existing type)
Roger Johansson
@rogeralsing
Apr 22 2015 18:09
It would be pretty easy to add some resolver for that
Bartosz Sypytkowski
@Horusiath
Apr 22 2015 18:11
If you have to, you could always use custom serializer, which is able to handle that problem for persistent events
Nikita Tsukanov
@kekekeks
Apr 22 2015 18:12
Is there some way to access default serializer's configuration?
Bartosz Sypytkowski
@Horusiath
Apr 22 2015 18:14
i.e. you could persist your events with protocol buffers serializer - since they use explicit proto schemas, as long as your mapped classes satisfy schema (which depends only on fields order and type, not even names) they're good to go
Nikita Tsukanov
@kekekeks
Apr 22 2015 18:15
Well, I'm usually against using human-inreadable formats for persistence
Aaron Stannard
@Aaronontheweb
Apr 22 2015 18:16
the serialization layer is fully pluggable
Nikita Tsukanov
@kekekeks
Apr 22 2015 18:16
And with protobuf you can't switch data types (eg. from int to double, string, etc)
Aaron Stannard
@Aaronontheweb
Apr 22 2015 18:16
the strong typing protobufs introduces is where all of the serialization performance benefits come from
Bartosz Sypytkowski
@Horusiath
Apr 22 2015 18:17
but you can change field names, and protobuf is faster and more compact
Nikita Tsukanov
@kekekeks
Apr 22 2015 18:18
Protobuf is great for transfering data on the wire, but for something that will be stored for years? Probably not.
Aaron Stannard
@Aaronontheweb
Apr 22 2015 18:18
yep, I agree with that
serialization overhead isn't something that matters much in the context of durable stores
Aaron Stannard
@Aaronontheweb
Apr 22 2015 18:28
alrighty, meeting time
Joshua Benjamin
@annymsMthd
Apr 22 2015 18:31
Is the meeting in here?
Natan Vivo
@nvivo
Apr 22 2015 18:33
@Aaronontheweb, @rogeralsing about the dispatchers. From what I understood, the main use cases to set a dispatcher are a) specify a thread model for performance reasons, so your actor is bound to one or more specific threads, or b) to limit the damage area in case too much work is being done, so you don't starve the rest of the system. Is that right? Are other common use cases?
Nikita Tsukanov
@kekekeks
Apr 22 2015 18:37
To limit the number of concurrent connections to something like Postgres (which really doesn't like when you have >100 connections to it)
David Smith
@smalldave
Apr 22 2015 18:40
sorry guys. as you might have gathered I'm not going to make the meeting tonight
@annymsMthd sounds good. we did discuss using appdomains instead of processes before. somebody came up with what I remember being a good reason not to. possibly @rogeralsing. certainly not against the idea though. would make things a lot easier.
Arjen Smits
@Danthar
Apr 22 2015 19:58
@skotzko interesting email
Bartosz Sypytkowski
@Horusiath
Apr 22 2015 20:10

To limit the number of concurrent connections to something like Postgres

@kekekeks This doesn't sound like a job for a dispatcher, rather the matter of design constrained pool of actors managing the connections

Nikita Tsukanov
@kekekeks
Apr 22 2015 20:11
Do you use database from a single actor type?
Natan Vivo
@nvivo
Apr 22 2015 20:11
@Horusiath I'm looking for things to write in the dispatcher documentation. like "reasons you might want to do this". if you have more recommendations, I'd be glad to hear
Nikita Tsukanov
@kekekeks
Apr 22 2015 20:12
I. e. one can have a ton of different actors that act like a repository
Natan Vivo
@nvivo
Apr 22 2015 20:12
@kekekeks you can restrict concurrent connections to a database with routers, I have been doing with actors only
Bartosz Sypytkowski
@Horusiath
Apr 22 2015 20:12
@kekekeks you may wrap database access layer in actor
Nikita Tsukanov
@kekekeks
Apr 22 2015 20:13
And lose access to ORM?
nope
Natan Vivo
@nvivo
Apr 22 2015 20:13
you don't need to lose ORM
Nikita Tsukanov
@kekekeks
Apr 22 2015 20:13
You lost me here
You can't use one pool since actors are actually of different types
i. e. UsersRepository, MessageRepository and so on
and even have pools for groups of actors of one type
Natan Vivo
@nvivo
Apr 22 2015 20:15
it all depends on how you see the problem
Nikita Tsukanov
@kekekeks
Apr 22 2015 20:15
In this case you'll have a lot of actors that do exclusively DB operations but are limited by DB connection pool
Arjen Smits
@Danthar
Apr 22 2015 20:15
Besides leveraging the supervision capabilities, and perhaps error handling. Why would you want your data access, which is already abstracted into repositories. abstracted behind an Actor?
Natan Vivo
@nvivo
Apr 22 2015 20:15
if you want to restrict all queries to a database, you could create an actor that routes or executes only 5 queries a time for example (an idea)
if you want to abstract per repository, then you can use all your ORM inside that actor
Nikita Tsukanov
@kekekeks
Apr 22 2015 20:16
in this case I'll have to do everything in one god-class
Arjen Smits
@Danthar
Apr 22 2015 20:16
@nvivo true. but if you are using an ORM, access to that level, for that kind of manipulation is abstracted away
Natan Vivo
@nvivo
Apr 22 2015 20:16
the point is that there is not a single way to do it. akka don't require you to stop using an orm
depends on the orm right?
Arjen Smits
@Danthar
Apr 22 2015 20:17
true
Joshua Benjamin
@annymsMthd
Apr 22 2015 20:17
One of the main things to note here is the Actor Model != OOP. There are fundamental differences in the way things are modeled and architected.
Nikita Tsukanov
@kekekeks
Apr 22 2015 20:17
I mean, different types of actors can share a single resource
jcwrequests
@jcwrequests
Apr 22 2015 20:17
Get rid of the ORM and use Event Sourcing :)
Natan Vivo
@nvivo
Apr 22 2015 20:17
=)
jcwrequests
@jcwrequests
Apr 22 2015 20:17
Or use a micro ORM
Nikita Tsukanov
@kekekeks
Apr 22 2015 20:18
Well, show me how to do full text search with event sourcing effectively
Bartosz Sypytkowski
@Horusiath
Apr 22 2015 20:18
there are plenty ways to do it. I've got idea, when db connections are distributed using token pattern - there is an actor which holds pool of tokens/db connections, and passes them on demand to other actors inside the same actor system, actors which needs a db access, ask provider wth token request and release the token after their job is done
however it's only an idea, I didn't test it yet
Natan Vivo
@nvivo
Apr 22 2015 20:18
@kekekeks what @annymsMthd said is completely true. the thing to realize is: Akka has 5 years of battle tested implementation working for lots of people in most varied environments. It's more about understanding how you can do it than anything else. the model itself doesn't restrict much, but you need to change your application architecture to embrace it.
Nikita Tsukanov
@kekekeks
Apr 22 2015 20:19
I don't see why it can't be done with a dispatcher that just limits the number of threads
Arjen Smits
@Danthar
Apr 22 2015 20:19
@nvivo Thats very true
Natan Vivo
@nvivo
Apr 22 2015 20:20
it's not that it can't be done. it's more that it shouldn't =)
dispatchers control how threads are used. you can run 10 queries using a single thread if you're using async
Arjen Smits
@Danthar
Apr 22 2015 20:20
@kekekeks The dispatcher is not meant for solving those kind of problems
Natan Vivo
@nvivo
Apr 22 2015 20:20
you shouldn't require messing with threads only to control connections
(that's exactly why I'm trying to come up with some reasons why someone should touch dispatchers - we need some good examples on why one would care about that)
Arjen Smits
@Danthar
Apr 22 2015 20:22
Honestly @nvivo I think that if the default dispatcher is properly optimized. The list of scenario's of wanting to implement your own is very small.
Natan Vivo
@nvivo
Apr 22 2015 20:22
I agree
Arjen Smits
@Danthar
Apr 22 2015 20:23
And thats besides the fact that implementing your own dispatcher if fraught with all kinds of subtleties
Natan Vivo
@nvivo
Apr 22 2015 20:23
just so you understand, I'm rewriting the docs to be more "human readable"
Arjen Smits
@Danthar
Apr 22 2015 20:23
Yes i know :) been lurking here for days, Just heaven't been very active due to.. stuff
Natan Vivo
@nvivo
Apr 22 2015 20:23
currently, if you go to the Dispatchers docs, you can read the entire thing and there is nothing there saying what it actually does and why you should change that
Bartosz Sypytkowski
@Horusiath
Apr 22 2015 20:23
I've already proposes an experiment for custom dispatcher built on top of Hopac to see, if there is a possible performance gain
Arjen Smits
@Danthar
Apr 22 2015 20:23
iv'e been eyeing the DI examples doc as well. That could use some love.
Hopac. yeah that should be interesting
Natan Vivo
@nvivo
Apr 22 2015 20:24
the official akka doc is more like "integers: we implemented using a custom machine architecture where bits are randomly swapped bla bla bla " - when they could just said "they are numbers"
you don't notice after some time. but for people learning, it's a lot of words that don't mean a lot
Bartosz Sypytkowski
@Horusiath
Apr 22 2015 20:27
I mean a lot, when you have to deep dive into internals or have some problem
Natan Vivo
@nvivo
Apr 22 2015 20:27
all I got from the docs is "it's the engine that makes akka tick".. all the rest I'm going through the source
yep, exactly
I agree they are useful. but it's not what akka.net needs to attract new people
I tried to explain akka.net to some friends, they have a lot of questions that I only know because I'm here everyday and reading the issues and going through the source. it's not a good path for everyone
Arjen Smits
@Danthar
Apr 22 2015 20:29
Yup. And not everything is updated for 1.0 yet. Or so it seems. Sometimes hard to judge, other than the fact stuff could be more clear.
Natan Vivo
@nvivo
Apr 22 2015 20:29
writing code is easy. it's much harder to document it =)
Arjen Smits
@Danthar
Apr 22 2015 20:30
heh, they respond with 'thats very interesting' and leave it at that :P
they deal with very different problems than me :P
Natan Vivo
@nvivo
Apr 22 2015 20:31
my wife calls me the king of nerds, and I come here and I see I'm not half of what it takes to code some of this stuff haha
you guys win hands down
Arjen Smits
@Danthar
Apr 22 2015 20:33
I know the feeling. In the land of the blind, the man who can see is king
Natan Vivo
@nvivo
Apr 22 2015 20:33
:-p
Arjen Smits
@Danthar
Apr 22 2015 20:35
And the fact that this profession has an huge amount of interest areas
jcwrequests
@jcwrequests
Apr 22 2015 23:37
Nikita Tsukanov
@kekekeks
Apr 22 2015 23:37
Oh, thanks