These are chat archives for akkadotnet/akka.net

23rd
Apr 2015
jcwrequests
@jcwrequests
Apr 23 2015 01:03
I have been playing around trying to find a good way to do stateful actors in a hierarchy. After talking with @Aaronontheweb that HashPooling was not a good idea so I came up with a sample project. Besides adding become logic I was wondering if anyone had any thoughts or criticism on how to model this using Akka.
I was going to combine some of the ideas with what @rogeralsing posted in his blog. Anything anyone would like to share is welcome.
Arjen Smits
@Danthar
Apr 23 2015 06:44
Any known issues with Akka running on .Net 4 ?
Roger Johansson
@rogeralsing
Apr 23 2015 06:46
Dont think anyone have tried tbh
Arjen Smits
@Danthar
Apr 23 2015 06:46
yeah me either
when I start thinking about it. There might be some TPL stuff
and there would be some minor perf issues in places where the concurrent collections are used. Those where horrible in perf in .Net 4
meh horrible is a bit much. But they weren't great.
Arjen Smits
@Danthar
Apr 23 2015 06:53
Do you guys make .Net 4 builds ?
ah, nuget says nope.
So in short: No known issues, but its not officially supported.
ugh! I hate this: https://skillsmatter.com/skillscasts/4081-greg-young-4081 "Because of its privacy settings: This video cannot be played here"
Arjen Smits
@Danthar
Apr 23 2015 09:24
@nvivo the new routing docs are great. But could use some extension on what resizers are and how they work.
Natan Vivo
@nvivo
Apr 23 2015 09:54
@Danthar, I'll take a look at that. Thanks
Arjen Smits
@Danthar
Apr 23 2015 10:15
@rogeralsing question. About DI and scopes. Currently the docs say that Actors must not have the singleton scope, since its not supported
However, that implies that other scope types are supported. But I think thats wrong, because as far as i understand it
only the transient scope is supported.
Due to how Akka works with location transparency and the lifetime of actors
but i could be wrong :P so im asking ;)
Roger Johansson
@rogeralsing
Apr 23 2015 10:30
You can still remotedeploy DI actors, the DI will occur on the remote system as the DI support is based on actor producers
Assuming the correct config exists on the remote system that is
Natan Vivo
@nvivo
Apr 23 2015 10:32
@rogeralsing so DI shouldn't affect remoting or clustering?
Arjen Smits
@Danthar
Apr 23 2015 10:33
@rogeralsing Ah I remember reading about that. But that is not what I was referring to.
Roger Johansson
@rogeralsing
Apr 23 2015 10:33
I havent tried it our but in theory it should work just fine as the props that are pushed to the remote system only contain the typename for the actor producer
Arjen Smits
@Danthar
Apr 23 2015 10:33
lets assume a non-remoting/clustering scenario for now.
lets say you are using an actorsystem in asp.net
Arjen Smits
@Danthar
Apr 23 2015 10:34
and you register your actors with an DependencyPerHttpRequest scope
Gerjan
@GerjanOnline
Apr 23 2015 10:34
Roger, who are these people?
Roland Kuhn?
Arjen Smits
@Danthar
Apr 23 2015 10:35
which would mean that the actors are disposed at the end of an httprequest. What i'm thinking is that this cannot work.
Roger Johansson
@rogeralsing
Apr 23 2015 10:36
@GerjanOnline yes, Roland Kuhn (akka lead for typesafe) holding the akka frame there.. no idea who the others are
Gerjan
@GerjanOnline
Apr 23 2015 10:37
okay thanks
Roger Johansson
@rogeralsing
Apr 23 2015 10:37
@Danthar hmm yes that sounds weird.. I have look that up
Gerjan
@GerjanOnline
Apr 23 2015 10:37
i think the java guy is Brian Goetz https://twitter.com/briangoetz
not sure, but thanks
Natan Vivo
@nvivo
Apr 23 2015 10:39
@rogeralsing, what prevents us from allowing system/context.ActorOf<ISomeInterface>() using DI internally instead of the context.DI().ActorOf<T>?
Arjen Smits
@Danthar
Apr 23 2015 10:39
@rogeralsing I think that any DI scope which effectively takes away lifecycle management from the ActorSystem, are not supported. Because it would mean that an Actor could be disposed without the Actor system being aware of it, or being the one who actually starts the dispose. Which in turn would cause all kinds of wierd stuff. As far as i can tell.
But maybe you guys have some voodoo code to manage those scenario's.
@nvivo nothing. Just that when you do that with Actor types. They wont be initialized properly. I take you mean something like this? :
This message was deleted
 myStaticDiContainer.Resolve<typehere>();
Natan Vivo
@nvivo
Apr 23 2015 10:42
not exactly
what I mean is more the semantics than the implementation
imagine I have an actor that requires constructor parameters
today I'm required to create the props with DI or manually, and then pass to ActorOf
this creates 2 different ways to declare exactly the same thing
man.... personally I can explain things much better
Arjen Smits
@Danthar
Apr 23 2015 10:45
Oh
I think I know what you mean
Your talking about implicit support for DI. So you don't have to do context.DI().ActorOf<IMyInterface>
and you can simply do this: context.ActorOf<IMyInterface>()
Is that what you mean?
what I mean is: it should be possible to use context/system.ActorOf<T> anywhere and not care about DI
DI is an implementation. The default props resolver could just complain "hey, I cannot resolve this type, it requires parameters", while if you set the DI resolver it would work
Arjen Smits
@Danthar
Apr 23 2015 10:53
Ah yep. Thats exactly what I meant just now.
But this is not the first time we are having this particular discussion :P
Natan Vivo
@nvivo
Apr 23 2015 10:54
oh, sorry. yes.. that's it =) I was writing in the gist, didn't see your comment
Arjen Smits
@Danthar
Apr 23 2015 10:54
np
Natan Vivo
@nvivo
Apr 23 2015 10:54
currently, DIExt lives in an external assembly
if only that interface (or some new interface) was moved to Akka, some simple logic could be used inside the actor system and any children to use that automatically
I'm trying to understand if that would break anything. Can you think of something?
Arjen Smits
@Danthar
Apr 23 2015 10:56
I think @jcwrequests already explored this route. I remember him saying something along the lines: Not possible due to inner workings of Akka or something like that.
Natan Vivo
@nvivo
Apr 23 2015 10:56
actually, it's not possible because that involves changing the akka dll to know about this.
Arjen Smits
@Danthar
Apr 23 2015 10:57
I have no idea if that that is the case.
Natan Vivo
@nvivo
Apr 23 2015 10:57
if you change the right bits, it's possible to make akka cook hamburguers
=)
Looking at the Props, it works almost like a DI resolver
So, in theory it could decide "i can create this type or I'll delegate this to someone who can (the DI)"
but I'm not sure if this is a good approach
currently, the DI is registered inside the actor system. So, maybe the actor system could decide that...
Arjen Smits
@Danthar
Apr 23 2015 11:02
Well. Make an issue for it =) Better to have this discussion in the tracker then here anyway. Because then it will be documented.
Because we had this discussion, about integration the DI system. Multiple times now ;)
Natan Vivo
@nvivo
Apr 23 2015 11:07
yeah, I'm trying to understand if this is possible before opening a ticket
Nikita Tsukanov
@kekekeks
Apr 23 2015 11:20

I think that any DI scope which effectively takes away lifecycle management from the ActorSystem, are not supported. Because it would mean that an Actor could be disposed without the Actor system being aware of it

Just wrap your ActorRef in something that implements IDisposable and kills the actor after being disposed

interface IDisposableActor<T> : IDisposable
{
    ActorRef Actor{get;}
}

class DisposableActor<T> : IDisposableActor<T>
{
    public ActorRef Actor {get; private set;}
    public DisposableActor()
    {
          Actor = ActorSystem.ActorOf<T>();
    }
    public void Dispose()
    {
         Actor.Tell(oisonPill.Instance, ActorRef.NoSender);
    }
}
Roger Johansson
@rogeralsing
Apr 23 2015 11:22
Im not sure i follow, its not the actors that are injected, its dependencies into actors. So the actor ref would never be wrapped in anything in the di
Nikita Tsukanov
@kekekeks
Apr 23 2015 11:23
I think that @Danthar tries to inject ActorRef in ASP.NET controller
And have it's lifetime managed by DI-container
Roger Johansson
@rogeralsing
Apr 23 2015 11:25
Oh, that is not supported, you inject into actors, not actors into other stuff
Nikita Tsukanov
@kekekeks
Apr 23 2015 11:25
It shouldn't be ever supported by Akka itself
Natan Vivo
@nvivo
Apr 23 2015 11:25
@kekekeks actors don't need to be disposable
the actor system already knows exactly when they stop
Nikita Tsukanov
@kekekeks
Apr 23 2015 11:26

actors don't need to be disposable

If you want DI container to manage something's lifetime on per-request basis you need it to be IDisposable

So if you need an actor per request, you wrap it in something that creates an actor for you and then kills it when request is complete
Natan Vivo
@nvivo
Apr 23 2015 11:29
yes, but you don't need to do it with idisposable
you can just ask the actor to stop after your're done
it's already part of the actor system
Nikita Tsukanov
@kekekeks
Apr 23 2015 11:29
It's not the part of ASP.NET
Roger Johansson
@rogeralsing
Apr 23 2015 11:29
Actor lifecycle should never be handled by anything else than akka itself. Actors can restart and thus need its own pipeline into the DI container to resolve its own dependencies
Nikita Tsukanov
@kekekeks
Apr 23 2015 11:30
ASP.NET won't tell the actor that it's no longer needed
ASP.NET won't tell the actor that request is completed
So if one wants to have an actor per-request, he has to wrap an ActorRef into something that provides that glue
This shouldn't be used inside actor code however
Only by external consumers
Natan Vivo
@nvivo
Apr 23 2015 11:33
You can have an actor per request and never have to let asp.net know about that
Nikita Tsukanov
@kekekeks
Apr 23 2015 11:42
Generally a bad idea in terms of ASP.NET
Since in this case you have to manually manage actor's lifetime
instead of letting DI-container to do its work
Natan Vivo
@nvivo
Apr 23 2015 11:46
@kekekeks you need to consider actor lifetime is a feature of akka. it's not a burden.
Nikita Tsukanov
@kekekeks
Apr 23 2015 11:50
If external code claims some resource (actor in our case), it should free it at some point
Otherwise you'll get a lot of actors not being using and just eating the memory
Or you'll have to use RecieveTimeout to kill the actors
which isn't a good solution either, since it may kill the actor before request completes
Roger Johansson
@rogeralsing
Apr 23 2015 11:54
That is done using either .stop or sending poisonpill, not by calling dispose
See the actor system as its own container, bad idea to try to have two competing containers decide when to kill things
The same things that is
Roger Johansson
@rogeralsing
Apr 23 2015 12:05
You can create a factory that creates the actor for you, and if the factory is disposed, you send poisonpill to kill the actor. That way, the ActorSystem is in charge all the time, while you still can inject the factory and get the actorref
Natan Vivo
@nvivo
Apr 23 2015 12:06
@rogeralsing Is Pigeon.conf really always loaded by the actor system, or is it just a reference?
Roger Johansson
@rogeralsing
Apr 23 2015 12:06
Then DI the factory whereever you need it
Arjen Smits
@Danthar
Apr 23 2015 12:06
and back. catching up on reading
Roger Johansson
@rogeralsing
Apr 23 2015 12:06
Always loaded , its the fallback for properties that the user config didnt supply
Natan Vivo
@nvivo
Apr 23 2015 12:07
thanks
Roger Johansson
@rogeralsing
Apr 23 2015 12:07
There are probably some old JVM gunk in there still
Natan Vivo
@nvivo
Apr 23 2015 12:08
@rogeralsing about the dispatchers, do you have any other common use case for them, so I can mention in the documentation?
Roger Johansson
@rogeralsing
Apr 23 2015 12:11
Yes, we have one dispatcher that captures current synchronizationcontext , so you can run actors in gui threads and update controls and such w/o threading issues
Eg if you want to async fill a grid or something
Natan Vivo
@nvivo
Apr 23 2015 12:12
hmm. ok!
that's important
Roger Johansson
@rogeralsing
Apr 23 2015 12:12
(Those actors should ofc not do heavy work, just update gui in a reactive way)
Maybe a reactive gui app for stock prices are a good example
There is also a pinned thread dispatcher, if you want to dedicate an entire thread to a specific actor
And the forkjoindispatcher, that has its own dedicated threadpool, to avoid noisy neigbours. Eg if some actors are more important than others, it can be isolated from the default shared threadpool
Natan Vivo
@nvivo
Apr 23 2015 12:21
Thanks! that helps a lot, gave me already some direction
Arjen Smits
@Danthar
Apr 23 2015 12:22
@rogeralsing You basically confirmed what I already expected. Akka uses the DI container to create an instance of your Actor, and after that, Akka is responsible for the lifecycle of the Actor. And not the DI container.
So that confirms my remarks about not supporting any DI lifetime scope except Transient/InstancePerDependency
Roger Johansson
@rogeralsing
Apr 23 2015 13:18
it depends on what you mean with scope i guess, lets say you have one dependency that should be recreated for each usage in a dependency graph, that ofc works, and of there is some dependency that should be unique per resolve, that would work too... Eg if a foo have a ref to 5 bars and 3 baz. It could be resolved as 5 bars and one single baz. For the same foo, if foo is injected to the actor
Natan Vivo
@nvivo
Apr 23 2015 13:41
@rogeralsing please correct if I'm wrong. Most of the JVM akka docs say that hocon configuration overrides code config. But some tests I did here shows the opposite. For example, if you specify WithRouter(...) in code, it overrides any hocon config. Is it correct that Akka.net gives preference to code over config or I missed something?
Arjen Smits
@Danthar
Apr 23 2015 13:58
@rogeralsing I'll do a write-up about this for the http://getakka.net/docs/Dependency%20injection page. Ill run it by you guys when im done.
Arjen Smits
@Danthar
Apr 23 2015 14:04
General question to whomever can answer this :P. My ActorSystem behaves in such a way, that it can be in an 'idle' state. Which effectively means that the mailboxes for a few key Actors in my system are empty. Does Akka currently has a way for a user of the framework to monitor this kind of state for an actor ?
So something along these lines:
    actor1.Ask<bool>("areyoubusy")
where the "areyoubusy" is a system(?) message which tells me if there are messages in the actor1's mailbox
Alexander Prooks
@aprooks
Apr 23 2015 14:14
I'd beter save info when last message is processed, and on 'areyoubusy' report if any message is processed for the last second/minute whatever you need
Natan Vivo
@nvivo
Apr 23 2015 14:29
@Danthar It's a good idea to leave a note on akkadotnet/getakka.net#7 to help coordinate the efforts
depending on the size of your changes
@Danthar by chance I'm looking at the resizer implementation. It seems that if you create a custom router, you can use ActorRefRoutee to lookup this information: https://github.com/akkadotnet/akka.net/blob/dev/src/core/Akka/Routing/Resizer.cs#L245
Natan Vivo
@nvivo
Apr 23 2015 14:40
I guess the way to do it then would be create a parent to intercept "are you busy" messages and the actor would ask the custom router directly
Arjen Smits
@Danthar
Apr 23 2015 14:51
@aprooks a busy message based on actor idle time/last message processed would work. But I am not sure it fits my scenario. Would have to think about it some more.
Natan Vivo
@nvivo
Apr 23 2015 14:54
fwiw, i did the same with actors directly and a simple "entry" record for each child
Arjen Smits
@Danthar
Apr 23 2015 14:54
@nvivo a group-router-like actor could definitely be used to wrap the idle-monitoring behaviour.
Natan Vivo
@nvivo
Apr 23 2015 14:55
basically created a class Entry { ActorRef Actor; bool Busy; }
and set the flags on request response. this of course depended on all answers going back to the actor I had
this model is so flexible there are many ways to do the same thing
Arjen Smits
@Danthar
Apr 23 2015 14:55
Yup
Thats why I was asking if there is anything in Akka right now, that can be used to achieve the same thing. Without me having to manually implement it.
Brandon Wilhite
@JediMindtrick
Apr 23 2015 14:57
Is there a way to allow an akka.net actor to interact with a remote akka (jvm) actor? Akka-jvm has a wire protocol, would this allow it?
Natan Vivo
@nvivo
Apr 23 2015 14:59
not currently
Brandon Wilhite
@JediMindtrick
Apr 23 2015 15:01
ok, so not currently. If we wanted to build such a thing, does anyone know if the wire protocol might be the enabling tech for it? OR is there really not any enabling tech (other than design off of http/tcp/whatever from the ground up)?
Arjen Smits
@Danthar
Apr 23 2015 15:05
When you start talking about communicating between the CLR and JVM It suffers from the same problems as any remoting tech. The wire protocol is the least of your problems.
Brandon Wilhite
@JediMindtrick
Apr 23 2015 15:06
Sure, there would be a lot of obstacles.
There's a lot of complexity there that would have to be handled. My thought was that possibly the Akka wire protocol was defined to help handle some of it....not really just worried about the transport here.
Arjen Smits
@Danthar
Apr 23 2015 15:07
@Aaronontheweb would know alot more about this topic.
Brandon Wilhite
@JediMindtrick
Apr 23 2015 15:08
k, thanks
Arjen Smits
@Danthar
Apr 23 2015 15:09
He's the one who worked on Helios/Lighthouse and alot of the remoting stuff (afaik). So he is probably much better equipped to tell you what kind of cesspool your walking into ;)
Brandon Wilhite
@JediMindtrick
Apr 23 2015 15:11
lol, y I'm sure...I'm not really contemplating this for any actual work project, more as a persistent itch I've had the last few years...just to see if it can be done
Natan Vivo
@nvivo
Apr 23 2015 15:20
anything is possible, few things are worth the trouble
I believe if you want to communicate between 2 different systems, it's easier to build some http layer through json nowadays outside of akka and just use that
Brandon Wilhite
@JediMindtrick
Apr 23 2015 15:21
and also...just because it can be done doesn't mean you should do it :)
Natan Vivo
@nvivo
Apr 23 2015 15:22
yeah.. think about it, yo usually won't couple 2 applications made with different versions of .NET
even more with 2 applications made for different languages at that level
Brandon Wilhite
@JediMindtrick
Apr 23 2015 15:22
don't get me wrong....I'm not advocating people should do what I'm asking about...I'm more just curious about this since the idea of rpc is kind of built into akka from the get-go
after all...if I'm sending a message to a remote actor, what should it matter what kind of runtime is running over there? But my experience with akka is limited and this is just something I've wondered about for awhile now.
i'd think supervision, deathwatch and probably other things would get pretty hairy
Natan Vivo
@nvivo
Apr 23 2015 15:25
sure
from what I read here, one of the big problems would be endianess, as the protocol is binary and java and .net use different ways to encode these stuff
it would be possible if the two systems used exactly the same serializer, then you'd go into the next issues with message formats...
Brandon Wilhite
@JediMindtrick
Apr 23 2015 15:51
so what kind of problems would you hit if you bumped up another level and tried to do something like akka-jvm proxy -> json over (pick your transport) <- akka.net proxy
obviously, you'd have to track liveliness somehow
Natan Vivo
@nvivo
Apr 23 2015 16:00
this is the kind of question for @Aaronontheweb.
Brandon Wilhite
@JediMindtrick
Apr 23 2015 16:02
k, thanks again, useful exchange
Natan Vivo
@nvivo
Apr 23 2015 16:03
sure
Arjen Smits
@Danthar
Apr 23 2015 16:28
@JediMindtrick if your going that route. Why use a raw HTTP endpoint with json? why not explicitly model that communication with message types. And use a messagebus like RabbitMq for that?
Joshua Benjamin
@annymsMthd
Apr 23 2015 16:59
@Aaronontheweb looks like i have a few run away builds
Joshua Benjamin
@annymsMthd
Apr 23 2015 17:10
@rogeralsing If you have access to the teamcity site can you cancel those runaway builds i caused?
Andrew Skotzko
@skotzko
Apr 23 2015 17:23
@annymsMthd stopped them for you
Joshua Benjamin
@annymsMthd
Apr 23 2015 17:23
thanks
Aaron Stannard
@Aaronontheweb
Apr 23 2015 17:36
@annymsMthd our build server just really liked XUnit 1.9.2 is all
btw, just deputized you as an official contributor to Akka.NET now - you've earned it
@JediMindtrick ahhh... the joys of JVM <---> .NET wire compatibility
Joshua Benjamin
@annymsMthd
Apr 23 2015 17:40
\o/
Aaron Stannard
@Aaronontheweb
Apr 23 2015 17:40
pull up a chair, and hear my song: a tale of woe about endianness, built-in serializers, and wire format compatibility
Joshua Benjamin
@annymsMthd
Apr 23 2015 17:41
lol
Arjen Smits
@Danthar
Apr 23 2015 17:41
hehe ^^
Aaron Stannard
@Aaronontheweb
Apr 23 2015 17:42
many moons ago, computer organizers decided for no apparent reason to organize words in memory in completely backwards orders
across different systems for reasons that are arbitrary
but that matters not
the JVM architects decided, for their own reasons, that big endianness was the one true way to organize bytes
and Microsoft, being the arch-nemesis of any company run by open source birkenstock-wearing hippies
decided that little endianness must be the one true way
Arjen Smits
@Danthar
Apr 23 2015 17:43
birkenstock lol
Joshua Benjamin
@annymsMthd
Apr 23 2015 17:43
and so the battle of endianness swept the land into darkness and despair
Aaron Stannard
@Aaronontheweb
Apr 23 2015 17:44
yes, indeed
file format and wire compatibilities were hopelessly dashed
and many heated arguments between bearded UNIX-y types ensued
and for all a time, there was nothing but darkness spread across the land
Aaron Stannard
@Aaronontheweb
Apr 23 2015 17:46
but as the years crept by, legends arose in the Microsoft community of new projects in JVM land
of unspeakable power
distributed databases, batch processing systems, streaming ETL pipelines
much like the citizens of East Germany living in the shadow of the Berlin wall, we dismissed these stories as just JVM propaganda
and chuckled smugly to ourselves as we patiently waited for SQL Server 2013 Super Streaming MapReduce Does Everything Edition
but as the years ticked by, these stories stepped into the realm of fact
and us CLR developers, seeing with our own eyes for the first time, decided that the great Endian war must come to an end
so we learned how to use byte[].Reverse()
But no, my sweet summer child, that was not the end
indeed... as it turns out - none of our built-in serializers are cross-platform compatible
and thus the small light of hope we only just recently lit was in danger of being squelched by the aftermath of the Endian war after all
Aaron Stannard
@Aaronontheweb
Apr 23 2015 17:51
But we said "enough!" and developed cross-platform wire formats that used their own serializers, like Thrift and Protobufs
and finally tore the great format wall down once and for all
ok, I can't keep telling this like an Epic poem
gave it everything I had
lol
Joshua Benjamin
@annymsMthd
Apr 23 2015 17:52
clapping
Aaron Stannard
@Aaronontheweb
Apr 23 2015 17:53
the lesson of the story is - if you want Akka --> Akka.NET interop, then you will need to add a cross-platform object representation format
and make sure both ends serialize using that
might be as simple as adding a JSON serializer as the default for Akka
and then on the CLR side you'll need to account for endianness
probably better off just making an Akka.IO wrapper in C#
and use that to communicate as a client
rather than attempt to get Akka.Remote / Akka.Cluster to be JVM-compatible
was wondering when Galdalf the Red, Blue, Yellow and Green would come in
Joshua Benjamin
@annymsMthd
Apr 23 2015 18:01
those are the bearded UNIX-y types
Arjen Smits
@Danthar
Apr 23 2015 18:02
lol. Some Magica pics would be suitable as well ^^
Natan Vivo
@nvivo
Apr 23 2015 18:03
Arjen Smits
@Danthar
Apr 23 2015 18:03
rofl
Aaron Stannard
@Aaronontheweb
Apr 23 2015 18:03
at some point we'll do an Akka.NET conference and I'll try to come up with an interpretive dance version of this story
lol @nvivo
Arjen Smits
@Danthar
Apr 23 2015 18:04
@Aaronontheweb be carefull now. We will hold you to that!
Aaron Stannard
@Aaronontheweb
Apr 23 2015 18:04
I used the word > try
that's my get out of jail free card
Arjen Smits
@Danthar
Apr 23 2015 18:04
try?
there is no try?
there is only Do :P
Natan Vivo
@nvivo
Apr 23 2015 18:05
first let's make sure you didn't forget your zipper down on .net fringe. you may need to decide if you want to appear in public after that :-p
Aaron Stannard
@Aaronontheweb
Apr 23 2015 18:05
clearly I am a consummate professional when it comes to public speaking @nvivo
Arjen Smits
@Danthar
Apr 23 2015 18:05
hah. About that. Are the vids from .netfringe online yet ?
Aaron Stannard
@Aaronontheweb
Apr 23 2015 18:06
good question
I need to follow up with those guys today - think they needed @skotzko and I's powerpoints
senor @skotzko gave a talk on how to model distributed transactions with Akka.NET actors
5 minute lightning talk
he did a great job but I think Glenn Block might have cut him off lol
Natan Vivo
@nvivo
Apr 23 2015 18:17
doc question: why would one use the TaskDispatcher currently? partial trust?
Aaron Stannard
@Aaronontheweb
Apr 23 2015 18:17
yeah, that's my understanding
Natan Vivo
@nvivo
Apr 23 2015 18:17
ok
Aaron Stannard
@Aaronontheweb
Apr 23 2015 18:17
although we just patched the normal dispatcher to be able to run under partial trust now
that'll be going live in Akka.NET v1.0.1
(the release for that was supposed to happen today but we decided it'd be best to get the Akka.Persistence.SQLServer stuff pulled in and the ConfigureAwait stuff first)
so it'll probably end up going out Monday / Tuesday next week instead
Natan Vivo
@nvivo
Apr 23 2015 18:18
right
Aaron Stannard
@Aaronontheweb
Apr 23 2015 18:22
we need some documentation on using the Inbox
that'd probably fall under the miscellaneous bucket
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:19
yo everyone! :)
Andrew Skotzko
@skotzko
Apr 23 2015 19:20
@danfma yo!
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:20
:smile:
Aaron Stannard
@Aaronontheweb
Apr 23 2015 19:20
what's shakin
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:22
hey guys, do you know if there is any problem with the routers and the config at the app.config?
Andrew Skotzko
@skotzko
Apr 23 2015 19:22
@danfma can you be more specific? what’s happening?
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:23
sorry, I am slow here! :D
I created an actor as a router (round-robin) in the config
then I tried to create that actor inside another one
 _executors = Context.ActorOf(
                Props.Create(() => new JobExecutor(_application))
                    .WithRouter(FromConfig.Instance),
                "Executors");
Aaron Stannard
@Aaronontheweb
Apr 23 2015 19:24
what's the config look like?
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:25
but I always got a strange error, something saying that the actor has already being configured
just the same as the example from the site
Aaron Stannard
@Aaronontheweb
Apr 23 2015 19:25
which one?
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:26
akka.actor.deployment {
  /Executors {
    router = round-robin-pool
    nr-of-instances = 5
  }
}
Aaron Stannard
@Aaronontheweb
Apr 23 2015 19:27
ah, I see what your issue is - you want to re-use that router configuration in multiple places
right?
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:28
no, I just wanted to define the router at config and not at code
the exception is
`

An exception of type 'Akka.Configuration.ConfigurationException' occurred in Akka.dll but was not handled in user code

Additional information: Configuration problem while creating [akka://BeedroneProcessor/user/Monitor/Executors] with router dispatcher [akka.actor.default-dispatcher] and mailbox and routee dispatcher [akka.actor.default-dispatcher] and mailbox [].

`
Andrew Skotzko
@skotzko
Apr 23 2015 19:28
I think your actor path is wrong
your router is not a top level actor in this case
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:28
user/Executors?
Andrew Skotzko
@skotzko
Apr 23 2015 19:29
/Monitor/Executors in the config
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:29
ops
let me check that
Andrew Skotzko
@skotzko
Apr 23 2015 19:29
or /*/Executors to reuse it
under other top level actors
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:30
You are right! I was dumb here! I forgot that actor is a child of another one!
:D
Andrew Skotzko
@skotzko
Apr 23 2015 19:30
no worries :)
key thing is that your actor path needs to be right in the config, so double check that first
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:31
ok
another question, let me say that I want to create some kind of processors on demand
I created a service with a queue of messages
the actors should pop some messages from time to time
Joshua Benjamin
@annymsMthd
Apr 23 2015 19:33
Maybe a pooled router with a resizer?
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:33
I was thinking in use the router to create that behaviour, while checking from time to time that queue
yes!
that's the point!
I created some actors using the async behaviour
Andrew Skotzko
@skotzko
Apr 23 2015 19:34
i guess you could have one actor scheduled to receive messages off the queue and then hand them to a resizable pool router for scalable processing
s/them/the messages
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:34
that's what the monitor is doing the previous code
the Executors is a pool of actors routed by the monitor
Andrew Skotzko
@skotzko
Apr 23 2015 19:35
ah
ok
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:35
one thing is funny
if I use the async from the .NET then the actors does not respect the default behaviour that only one message is processed by an actor at a time, apparenly
apparently*
is the the right thing when using async or a problem
Roger Johansson
@rogeralsing
Apr 23 2015 19:36
What version are you using?
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:36
the last one
just checking
Andrew Skotzko
@skotzko
Apr 23 2015 19:37
default respects one message at at time
Roger Johansson
@rogeralsing
Apr 23 2015 19:37
And what async behavior? Suspend or reentrant?
Natan Vivo
@nvivo
Apr 23 2015 19:37
this async stuff must be a problem with Brazilians...
Andrew Skotzko
@skotzko
Apr 23 2015 19:37
you have to specifically enable reentrant
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:37
the version on nuget is the 1.0.0
yes, I configured that
kkkkkkkkkkkkk
is there another one here?
Natan Vivo
@nvivo
Apr 23 2015 19:38
you should leave the default or specify Suspend
are you using ReceiveActor?
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:38
yes
I will write one example here, just a moment
Natan Vivo
@nvivo
Apr 23 2015 19:38
just do Receive<Foo>(async foo => { .. })
the default behavior is Suspend already
Roger Johansson
@rogeralsing
Apr 23 2015 19:39
Btw async await is broken in nuget 1.0 package
Natan Vivo
@nvivo
Apr 23 2015 19:39
oh, right!
Andrew Skotzko
@skotzko
Apr 23 2015 19:39
but fix coming next week
in 1.0.1
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:39
ahhhh
Natan Vivo
@nvivo
Apr 23 2015 19:39
@danfma I'm Brazilian
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:39
:D
me too
and good to say that was not a problem with me this time
:D
public class JobExecutor : ReceiveActor
    {
        private readonly Application _application;
        private bool _working = false;

        public JobExecutor(Application application)
        {
            _application = application;

            Receive<BeginWork>(AsyncBehavior.Reentrant, _ => _application.ExecuteInScope(() => OnBeginWork()));
        }

        private async Task OnBeginWork()
        {
            if (_working)
            {
                Console.WriteLine("Executando trabalho ainda {0}", Thread.CurrentThread.ManagedThreadId);
                return;
            }

            _working = true;

            Console.WriteLine("Iniciando trabalho {0}", Thread.CurrentThread.ManagedThreadId);
            //Thread.Sleep(8000);
            await Task.Delay(10000);
            Console.WriteLine("Finalizando trabalho {0}", Thread.CurrentThread.ManagedThreadId);

            _working = false;
        }
    }
Natan Vivo
@nvivo
Apr 23 2015 19:41
Reentrant means exactly that messages will be processed during task awaits
you want the non-reentrant behavior
Andrew Skotzko
@skotzko
Apr 23 2015 19:41
yeah you want the suspend behavior
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:41
if I use the suspend the message will be processed only one time
Natan Vivo
@nvivo
Apr 23 2015 19:41
Yes, and that's the default, you don't need to provide an argument
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:42
ok I will check
Natan Vivo
@nvivo
Apr 23 2015 19:42
out of curiosity, what is that Application you have there? Are you executing that code somewhere else?
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:43
I created an instance of my app, which starts the windsor and others services, so that application is where my services are
Natan Vivo
@nvivo
Apr 23 2015 19:44
You can use DI with akka, there are some docs with that
and as a general rule, you should never touch actor state from threads other than what the actor is running on
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:45
yes, I know, I will check that too, I just want to use quickly here to test
Natan Vivo
@nvivo
Apr 23 2015 19:45
right
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:45
that's the problem
Natan Vivo
@nvivo
Apr 23 2015 19:46
In essense, you should have only Receive<BeginWork>(_ => OnBeginWork())); and get your services in some other way, as dependencies for example
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:47
yes
but in this case, some services lives only that the scope defined by that call, that's why I used that.
it just wraps the call with a scope
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 19:54
@skotzko Thanks for the site! I already saw part of it before, but I will read the rest! :D
Andrew Skotzko
@skotzko
Apr 23 2015 19:57
sure thing
Brandon Wilhite
@JediMindtrick
Apr 23 2015 20:01
@Danthar That's why I had in parens (pick your transport)...going that way you have a number of options. Rabbit would be a good choice too, imo.
Brandon Wilhite
@JediMindtrick
Apr 23 2015 20:11
@Aaronontheweb Thanks for the story :) ...y, I knew as soon as the other guy mentioned endianness there was a problem. Akka.io wrapper seems like a suitable strategy.
Daniel Ferreira Monteiro Alves
@danfma
Apr 23 2015 20:41
@skotzko Thanks for that link! I read it to the end here and now I can see what was happening! :)
Andrew Skotzko
@skotzko
Apr 23 2015 20:50
@danfma you’re welcome :)
Natan Vivo
@nvivo
Apr 23 2015 20:53
In Pigeon.conf, are these settings for "default-dispatcher" valid also for other dispatchers?
Bartosz Sypytkowski
@Horusiath
Apr 23 2015 20:55
each dispatcher may use it's own keys, but type and throughput are common
Natan Vivo
@nvivo
Apr 23 2015 20:55
what about shutdown-timeout?
Sean Gilliam
@sean-gilliam
Apr 23 2015 20:56
Maybe I'm missing something but lulz
    /// <summary>
    /// XML (omg not XML!) implementation of the <see cref="IPersistentTestRunStore"/>
    /// </summary>
    public class JsonPersistentTestRunStore : IPersistentTestRunStore
Roger Johansson
@rogeralsing
Apr 23 2015 20:56
And deadline-time
Aaron Stannard
@Aaronontheweb
Apr 23 2015 20:56
@sean-gilliam lol yeah
my bad on that one
was going to go with XML for the reporting tools on the multinode test runner so it felt all enterprisey and browser-viewable
then I got really lazy
went with JSON
Sean Gilliam
@sean-gilliam
Apr 23 2015 20:57
:smile:
Roger Johansson
@rogeralsing
Apr 23 2015 20:57
Hahaha
Natan Vivo
@nvivo
Apr 23 2015 21:00
so, common between all dispatchers is shutdown-timeout, throughput and throughput-deadline-time, correct?
Roger Johansson
@rogeralsing
Apr 23 2015 21:01
  throughput-deadline-time = 0ms
That one is used by the mailbox together with througput to determine when to exit mailbox run
Shutdow timeout, not sure if that one is implemented?
Natan Vivo
@nvivo
Apr 23 2015 21:03
but they are valid for other dispatchers as well?
or just for threadpool?
Aaron Stannard
@Aaronontheweb
Apr 23 2015 21:05
those settings are valid for all dispatchers
they get used by the mailbox
to determine how long each mailbox run is
Roger Johansson
@rogeralsing
Apr 23 2015 21:07
Where is shutdown timeout used? Mailbox cleanup?
Aaron Stannard
@Aaronontheweb
Apr 23 2015 21:07
not sure if we use that setting anywhere
maybe inside the ActorCell when it's getting detatched
Roger Johansson
@rogeralsing
Apr 23 2015 21:09
Do a search for it and file an issue if its not used, just so we dont forget about it
Aaron Stannard
@Aaronontheweb
Apr 23 2015 21:09
fixed #884
man, nasty bug
repointable actor ref couldn't look up its own children
Roger Johansson
@rogeralsing
Apr 23 2015 21:10
Im on the road so i cant check
Ouch
Aaron Stannard
@Aaronontheweb
Apr 23 2015 21:10
wasn't a remoting / serialization problem at all
Natan Vivo
@nvivo
Apr 23 2015 21:12
ok
thanks
Aaron Stannard
@Aaronontheweb
Apr 23 2015 21:24
starting to think we might need some more build agents...
Joshua Benjamin
@annymsMthd
Apr 23 2015 21:24
something is up with my run
Aaron Stannard
@Aaronontheweb
Apr 23 2015 21:25
free edition of TeamCity only lets me scale it up to 3 - JetBrains OSS sponsorship might allow for more
@annymsMthd want me to cancel it?
Joshua Benjamin
@annymsMthd
Apr 23 2015 21:25
it just finished. I'm going to look at the logs
Roger Johansson
@rogeralsing
Apr 23 2015 21:29
Whats the price for a bigger one?
Aaron Stannard
@Aaronontheweb
Apr 23 2015 21:30
$300 per additional build agent
$2000 gets us enterprise which can scale up to 100 agents
Roger Johansson
@rogeralsing
Apr 23 2015 21:31
Per what? One time fee?
Aaron Stannard
@Aaronontheweb
Apr 23 2015 21:31
yeah - you update the license and get the new agent capabilities
Joshua Benjamin
@annymsMthd
Apr 23 2015 21:31
Do they have any deals for Open Source projects?
boom
as long as the projects we run on the build server are FOSS
then we're good to go
Roger Johansson
@rogeralsing
Apr 23 2015 21:32
Nice :)
Joshua Benjamin
@annymsMthd
Apr 23 2015 21:33
winning
Aaron Stannard
@Aaronontheweb
Apr 23 2015 21:33
cool, I'll apply for one
would be happy to write up a blog post about how we use their Azure auto-scaling module
since that's pretty cool
Aaron Stannard
@Aaronontheweb
Apr 23 2015 22:08
@annymsMthd dude, holy crap - did you get the MultiNodeTestKit to pass?!
I just saw the message on the build server
Joshua Benjamin
@annymsMthd
Apr 23 2015 22:08
negative. I turned it off for now
Aaron Stannard
@Aaronontheweb
Apr 23 2015 22:08
NOOOOOOOOOO
I was stoked for a second there
Joshua Benjamin
@annymsMthd
Apr 23 2015 22:09
I can turn it back on:)
Aaron Stannard
@Aaronontheweb
Apr 23 2015 22:09
haha no probably best to leave it off fornow
Joshua Benjamin
@annymsMthd
Apr 23 2015 22:10
#888 does have the appdomain improvements and some fixes for them. They are not quite fully stabilized yet, still having intermittent issues.
My build does seem to have more tests for some reason. I looked through the list and there isn't duplicate runs
jcwrequests
@jcwrequests
Apr 23 2015 23:42
@kekekeks https://skillsmatter.com/skillscasts/5137-event-store jump about 1:4o mins in.