These are chat archives for akkadotnet/akka.net

17th
Apr 2015
Natan Vivo
@nvivo
Apr 17 2015 00:00
question: the SmallestMailbox is provided only as Pool, there is no Group right?
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:00
correct
Natan Vivo
@nvivo
Apr 17 2015 00:00
thx
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:01
believe the reason is that it has to have an ActorRef for each routee in order to get the data it needs for its routing strategy
Natan Vivo
@nvivo
Apr 17 2015 00:03
right
trying to come up with some better explanations in the docs
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:04
good idea
you can use @rogeralsing's diagrams he did for the original docs - they should be in the /docs/images folder IIRC
or make new ones
Natan Vivo
@nvivo
Apr 17 2015 00:04
do you use a specific tool to create the diagrams?
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:05
I use SmartDraw
I think he uses PowerPoint
Natan Vivo
@nvivo
Apr 17 2015 00:05
ewww
:-p
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:05
to PowerPoint? :package:
Natan Vivo
@nvivo
Apr 17 2015 00:05
I hate powerpoint haha
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:05
haha
me too
but Roger does some amazing stuff in it
Natan Vivo
@nvivo
Apr 17 2015 00:05
too much time on enterprise meetings
You added some titles like "What actors do?" - "what dispatchers do?"
I'm adding the same to the routers
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:07
I think that's a good idea
Natan Vivo
@nvivo
Apr 17 2015 00:07
it's funny these akka docs, I think you don't notice
but they are very vague (the original ones) about stuff
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:07
yes they are
very academic
Natan Vivo
@nvivo
Apr 17 2015 00:07
as I know more about akka I start to not notice anymore
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:08
one of the things that really annoys me about people who give talks on distributed computing
and I try to hold myself to this standard too
is they ram a bunch of acronyms and technical jargon down the attendee's throats
as though this stuff isn't super specialized knowledge
"oh yeah, so we just use a consistent hash distribution here"
"so this is the first step in a two-phase commit"
"well, because EVERYONE knows you can't have a CA system"
Natan Vivo
@nvivo
Apr 17 2015 00:09
haha
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:09
the fewer assumptions the language makes about its reader
the better IMHO
Natan Vivo
@nvivo
Apr 17 2015 00:09
but it's hard to come up with good docs
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:10
yes it is
Natan Vivo
@nvivo
Apr 17 2015 00:10
it's much easier to complain about what is already there to do better
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:10
yep
someone had to be brave enough to go first
Natan Vivo
@nvivo
Apr 17 2015 00:10
well, at least I'm learning a lot as well... at some point I'll be able to write some code without so many questions
jcwrequests
@jcwrequests
Apr 17 2015 00:11
Hey guys sorry to interrupt. I had a question about actor selection.
Natan Vivo
@nvivo
Apr 17 2015 00:11
I was reading the clsuter stuff today, how the vector clock and convergence works
some heavy stuff there
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:11
@jcwrequests go for it
@nvivo yeah, the concepts behind Akka.Cluster are pretty specialized
the entire idea of clustering itself is pretty strange at first
the thing that helped me was working with Cassandra for a couple of years first before I started working on Akka.NET
Cassandra uses the same concepts and tools, except vector clocks
Natan Vivo
@nvivo
Apr 17 2015 00:13
I used to work on a telecom company, so I'm quite used to these details due to how network and dynamic routing works
but it's very interesting nonetheless
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:13
yeah
jcwrequests
@jcwrequests
Apr 17 2015 00:13
Okay. I know this may sound stupid but if I try to select an actor that is not there then there is no issue creating one. right.
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:13
@jcwrequests correct - it'll just go to deadletters
no exception or anything
unless the actor selection is literally not valid
i.e. fails Regex validation
which is a formatting issue
if you try to select an actor path that doesn't exist then the message just gets delivered to dead letters
Natan Vivo
@nvivo
Apr 17 2015 00:16
doc question: pool routers are supervisors, but group routers have no children right? in that case, the supervisors will be whoever created the actors, correct?
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:16
correct
Natan Vivo
@nvivo
Apr 17 2015 00:16
ok
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:16
the big distinction between group and pool routers
is that group routers route to pre-existing actors
so one of those routees might die
group router has no idea
Natan Vivo
@nvivo
Apr 17 2015 00:17
good. I'll add that
jcwrequests
@jcwrequests
Apr 17 2015 00:17
That won't work. I guess the supervisor would know all it's children easily right>
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:17
pool routers directly create and manage their routees
@jcwrequests yep, you can iterate through Context.GetChildren I believe
not sure what the exact method call is
let me check the api docs
jcwrequests
@jcwrequests
Apr 17 2015 00:18
Don't worry I am just thinking through a scenario.
jcwrequests
@jcwrequests
Apr 17 2015 00:20
I think I would have hashpool of say group actors then that group actor would be responsible for generating its members then I could I could forward messages from the group actor to the appropriate user actors.
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:23
I'd need to see a diagram to comment any further :panda_face:
I'm not totally following at the moment
jcwrequests
@jcwrequests
Apr 17 2015 00:24
It's like you have a bunch of chat rooms with unique users within each room.
But I understand about the diagram. That is a good idea.
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:32
ah got it
so you need a router to send a message to the right room
and then a message to the right recipient?
jcwrequests
@jcwrequests
Apr 17 2015 00:33
Yes. Except the difference is that the actor receiving the messages in the chat room handles all the state for one user.
So you have an app generating events. Those events have to go back to the application session for that user.
And at some points during the session the application may ask the actor for information about it's current state.
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:36
I would recommend using a user-defined actor to do the routing in that case then - stateful routing is tricky. If a user leaves the chat session then a consistent hash router is going to start routing messages belonging to one user somewhere else
CHR is pretty useful for making sure events end up on the right machine
but you still have to deal with network partitions and stuff in those cases
Natan Vivo
@nvivo
Apr 17 2015 00:37
@Aaronontheweb the docs say "[the router] uses Escalate and does not stop routees during restart"
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:37
not sure about hat
that*
I think Pool has a property called DefaultSupervisorStrategy
Natan Vivo
@nvivo
Apr 17 2015 00:38
sounds strange. It seems to imply the restart event won't fire or something, but I don't think this is what happens
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:38
check the source on that and see what it does
Natan Vivo
@nvivo
Apr 17 2015 00:38
ok
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:38
yeah I don't think so either
doesn't sound right to me
jcwrequests
@jcwrequests
Apr 17 2015 00:39
@Aaronontheweb that make sense. I just need to build a proof of concept. I am just brainstorming before writing any code.
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:39
ah got it
jcwrequests
@jcwrequests
Apr 17 2015 00:40
I know it will work. Performance is going to be important because of the large number of events that will be coming the actors way.
I am not sure if SQL Persistence can handle the IO. Been thinking about Cassanadra or the eventstore.
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:48
have a contributor who has an EventStore persistence module up and running
Natan Vivo
@nvivo
Apr 17 2015 00:49
@Aaronontheweb it seems the docs are wrong or the .net implementation sis different. the old docs say all routees are restarted if the router escalates, but akka.net uses OneForOne by default
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:49
in that case just update the docs to reflect the .NET implementation
Natan Vivo
@nvivo
Apr 17 2015 00:49
ok
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:49
all of our RouterSpecs pass
so I assume we're doing what we're supposed to be doing
Natan Vivo
@nvivo
Apr 17 2015 00:51
just checked akka source, it is the same of .net, so the docs are probably just outdated
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:52
cool
that's what I thought
our specs would explode if there was a major difference there
Natan Vivo
@nvivo
Apr 17 2015 00:54
ok, so I have a question here
The pool has strategy as new OneForOneStrategy(10, TimeSpan.FromSeconds(10), ex => Directive.Escalate)
this escalate means the error is passed to it's parent, right?
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:55
yep
Natan Vivo
@nvivo
Apr 17 2015 00:55
I did a test here, created a roundrobin pool and throw an exception. only that actor instance is restarted, not the router
why is that?
Aaron Stannard
@Aaronontheweb
Apr 17 2015 00:57
 internal class RouterActor : UntypedActor
    {
        public RouterActor()
        {
            if (!(Context is RoutedActorCell))
            {
                throw new NotSupportedException("Current Context must be of type RouterActorContext");
            }
        }

        protected RoutedActorCell Cell
        {
            get { return Context.AsInstanceOf<RoutedActorCell>(); }
        }

        protected override void PreRestart(Exception cause, object message)
        {
            //do not scrap children
        }
that's why
the router did restart
but the children don't die
everyone gets restarted though
IIRC
plus the RoutedActorCell is implemented differently
then the normal one
the RoutedActorCell's list of routees isn't affected by the restart
BTW, this is a level of detail that is not necessary for the docs
Natan Vivo
@nvivo
Apr 17 2015 01:00
right. I thought about removing that, I think this is implementation detail
Aaron Stannard
@Aaronontheweb
Apr 17 2015 01:00
yeah, exactly
just to see what happens. only the actor that handles a specific message is restarted, all the others aren't touched as far as I see
Aaron Stannard
@Aaronontheweb
Apr 17 2015 01:01
that makes sense
those other actors weren't in a faulted state
so no need to restart
so my bad - I got that wrong
first time around
Natan Vivo
@nvivo
Apr 17 2015 01:02
yep, makes sense to me. I'll remove these bits of the docs and just leave the high level explanation
Aaron Stannard
@Aaronontheweb
Apr 17 2015 01:02
:thumbsup:
Natan Vivo
@nvivo
Apr 17 2015 02:17
These settings in HOCON like "router = round-robin-pool" - is this just snake-case converted PascalCase to find the router, or is there a table defining these strings somewhere?
nevermind... found the Pigeon.conf
Joshua Benjamin
@annymsMthd
Apr 17 2015 02:41
xunit sure does some weird stuff with threads
Arjen Smits
@Danthar
Apr 17 2015 07:20
Is there anything special Akka.Net needs to do in order to work with OWIN ?
Roger Johansson
@rogeralsing
Apr 17 2015 07:34
I dont think so
Arjen Smits
@Danthar
Apr 17 2015 07:45
Hosting in OWIN should be almost as easy as hosting in a normal ASP.NET application. Ill work on making a write-up for the docs.
oh and just made a PR for ASP.NET hosting docs.
Natan Vivo
@nvivo
Apr 17 2015 13:02
not sure if this is on plans, but I think there could be some improvements on the HOCON parsin error area. I'm doing some examples for the docs, and usually if you have an error like a missing config, you get a very generic error like "Configuration problem while creating [akka://app/user/work-pool] with router dispatcher [akka.actor.default-dispatcher] and mailbox and routee dispatcher [akka.actor.default-dispatcher] and mailbox []."
It would be better if these errors could include something like "Can't find the configuration for actor ´/foo/bar'". something that tells me what caused the error.
I know I found other cases where these config errors are vague. should I create tickets for these cases I find?
Roger Johansson
@rogeralsing
Apr 17 2015 13:05
:+1: there are a lot of Type.GetType(name) for example, that are probably not checked for null result atm
Roger Johansson
@rogeralsing
Apr 17 2015 13:13
the most annoying problem imo is that single quote is not a string start.. but it can be part of an unquoted string. eg. someprop = 'hola that sets some prop to 'hola
so we can't throw as it is legit hocon
Natan Vivo
@nvivo
Apr 17 2015 13:14
funny things.... the problem for me is that I think of JSON as javascript, and it's actually only part of that
in the browser console you can just say "var x= 'foo'" and it works... I never have to write json manually, so every actual json always comes from a library.. never thought single quotes were not part of that =)
it's a highly voted question on stackoverflow
Roger, I have a question about website generation
I saw you changed from Jekyll to grunt
how hard would it be to add some macro to allow multi-language examples in boxes, instead of in sequence?
I was thinking something like MSDN where when there are multiple languages, you see only one but can choose the language to see... I could implement that code if there is a way to make the parser convert it
Roger Johansson
@rogeralsing
Apr 17 2015 13:23
shouldn't be that hard, the theme already supports it, so either we adapt the markdown to support tabs, or we just inline the html in the markdown to tabbify it
Natan Vivo
@nvivo
Apr 17 2015 13:24
right, could just inline html, no need to extend the markdown
I'll take a look later at this then
David Smith
@smalldave
Apr 17 2015 16:41

daily afternoon update. firstly never use NLog and UDP when you actually care about seeing log messages. that's led me up a number of blind alleys.
secondly I'm now sure I've found the problem with my test
In TcpServerHandler InitInbound

listener.Notify(new InboundAssociation(handle));

This should pass InboundAssociation to the AkkaProtocolManager via an ActorAssociationEventListener.
The reference to the manager that ActorAssociationEventListener holds just dead letters the InboundAssociation.
The manager is definitely up and is receiving other messages (as far as I can tell through the same Actor Ref).
Any ideas what might cause the messages to be dead lettered?

Aaron Stannard
@Aaronontheweb
Apr 17 2015 16:43
could you inspect the actorref and see if it's pointing to the same version of the AkkaProtocolManager?
the addresses should be different each time the transport restarts
atomic counter update
at least for the AkkaProtocolActor FSM - not sure about the manager
David Smith
@smalldave
Apr 17 2015 16:44
this is a new actor system it's tcp.0
Aaron Stannard
@Aaronontheweb
Apr 17 2015 16:47
it deadletters immediately for a new actorsystem?
David Smith
@smalldave
Apr 17 2015 16:48
nope. it receives an Akka.Remote.Transport.AssociateUnderlyingRefuseUid message
if you look in ActorTransportAdapter you can see the manager reference being set. this is used to send AssociateUnderlyingRefuseUid and seems to work
the one that is returned in the new ActorAssociationEventListener doesn't for some reason
the manager field is only set once as far as I can see in the logs
Aaron Stannard
@Aaronontheweb
Apr 17 2015 16:52
why is the RefuseUid being sent? due to quarantine?
David Smith
@smalldave
Apr 17 2015 16:54
good question. not sure. the manager gets that message before inbound associate when it works too
Aaron Stannard
@Aaronontheweb
Apr 17 2015 16:57
ah nevermind
the RefuseUid only matters if the UID field is populated
otherwise it's the default connection type for outbound communication
David Smith
@smalldave
Apr 17 2015 16:57
yep just looking at that
if I push this test up to my fork can you take a look
Aaron Stannard
@Aaronontheweb
Apr 17 2015 16:59
I'm not going to have much time over the next few days
tied up doing customer stuff
David Smith
@smalldave
Apr 17 2015 16:59
ok. when do messages go to deadletters?
Aaron Stannard
@Aaronontheweb
Apr 17 2015 17:00
if you're sending messages to an actorref
the only time messages go to deadletters is if that actor is dead
if you're sending messages to an actor selection
then it's because the actor either never existed or is now dead
only exception to those rules are if the actor does something special that routes particular types of messages to deadletters explicitly before it dies
David Smith
@smalldave
Apr 17 2015 17:03
i think I know the answer to this but is there some way I can tell if what is at the end of an actor ref is alive or dead?
Aaron Stannard
@Aaronontheweb
Apr 17 2015 17:04
if the message goes to deadletters :p
David Smith
@smalldave
Apr 17 2015 17:06
poststop a good way to log when the actor dies?
Aaron Stannard
@Aaronontheweb
Apr 17 2015 17:06
yes
David Smith
@smalldave
Apr 17 2015 17:07
ok I'll keep going. pretty confused at this point
last question. best way to monitor dead letters
Aaron Stannard
@Aaronontheweb
Apr 17 2015 17:07
same here - sounds like the problem is that some piece of dead infrastructure on the inbound side gets re-used when it shouldn't and the problem is probably inside Akka.Remote
you turn on log-dead-letters in config
the default config will do that
you can also write your own code to subscribe to Deadletter events on the EventStream
David Smith
@smalldave
Apr 17 2015 17:10
ok. i did the second and sounds like the first was already done for me. no deadletters. when I debugged the code to see what was going on the message went to the deadletters mailbox but I guess that may be a timing issue. I'll double check
Aaron Stannard
@Aaronontheweb
Apr 17 2015 17:19
I have an idea what it might be
maybe the issue is the IAssociationListener
on the inbound side
#region ActorBase / ActorTransportAdapterManager overrides

        protected override void Ready(object message)
        {
            message.Match()
                .With<InboundAssociation>(ia => //need to create an Inbound ProtocolStateActor
                {
                    var handle = ia.Association;
                    var stateActorLocalAddress = localAddress;
                    var stateActorAssociationListener = associationListener;
David Smith
@smalldave
Apr 17 2015 17:21
i've checked that. the message doesn't make it there or to the base class before it's become ready
if that is what you are thinking?
too weird. not a timing issue. stuck a bit of logging in actorcell post and it is definitely going to the dead letters mailbox
David Smith
@smalldave
Apr 17 2015 17:32
blob
you can see the manager receive the associateunderlyingrefuseuid message and then the inboundassociation go to deadletters and then the manager get the next associateunderlyingrefuseuid
both messages should be told to the same actor ref. i guess that can't be the case
Aaron Stannard
@Aaronontheweb
Apr 17 2015 18:26
@smalldave aren't these two different managers? one outbound one inbound
the ProtocolManager that sends the associateunderlyingrefuseuid isn't the same one that receives the inboundassociation
different ends of the pipe
seems like the protocolmanager on the inbound side died
David Smith
@smalldave
Apr 17 2015 18:53
ah that would make sense
Natan Vivo
@nvivo
Apr 17 2015 18:57
question about TailChopping... if no messages arrive in the "within" interval, how does it timeout? does it send a Timeout message to the sender?
oh.. got it... PipeTo converts the exceptin into a Failure
Joshua Benjamin
@annymsMthd
Apr 17 2015 19:58
some quirky things happening with the build. Hopefully I'm getting them fixed up