These are chat archives for akkadotnet/akka.net

31st
Aug 2015
Ryan Davis
@rdavisau
Aug 31 2015 03:19
so if I were to inherit a ReceiveActor in F#, how should I get to Sender? I haven't quite worked out how F# wants me to write that. Alternatively, using the F# api helpers, can I achieve things like OnPreStart()to make the actor do something once it is born and inside the actorsystem?
Ryan Davis
@rdavisau
Aug 31 2015 03:38
maybe a pattern of deploy then send init message?
Ryan Davis
@rdavisau
Aug 31 2015 03:53
although then it feels like I'm building all of the actorsystem stuff into my "creator" function, humm
Ryan Davis
@rdavisau
Aug 31 2015 03:59
annnnnnnd the trick for the ReceiveActor was to access Context from within a member rather than a basic let binding. Move along, nothing to see here :smile:
Bartosz Sypytkowski
@Horusiath
Aug 31 2015 06:08
@rdavisau using F# API, you don't have direct access to lifetime events, but you can make their equivalents https://gist.github.com/Horusiath/ba2e5b33dc4377a0f018
Ryan Davis
@rdavisau
Aug 31 2015 06:19
@Horusiath thank you.. and then at the 'pre-start' time there, it is appropriate to spawn any child actors using the mailbox.Selfcontext, yes?
Bartosz Sypytkowski
@Horusiath
Aug 31 2015 07:37
yes
Oleg Gavrilov
@OlegGavrilov
Aug 31 2015 08:05
hi guys! quick question - is "var result = await actorRef.Ask<string>(new Message());" is supported way of asking actors?
Roger Johansson
@rogeralsing
Aug 31 2015 08:16
yes that works fine. but do note that there are some special conditions when asking from within another actor..
Oleg Gavrilov
@OlegGavrilov
Aug 31 2015 08:17
@rogeralsing thanks! is there any docs to read about that special conditions?
Roger Johansson
@rogeralsing
Aug 31 2015 08:18
it will only work from within a ReceiveActor and only if the receive handler is declared as "async msg => { .... }"
Roger Johansson
@rogeralsing
Aug 31 2015 08:23
You should also take a look at this https://github.com/petabridge/akkadotnet-code-samples/tree/master/PipeTo , it describes how to use async operations from within a normal actor too
Oleg Gavrilov
@OlegGavrilov
Aug 31 2015 08:26
@rogeralsing thank you!
also, I would like to visualize ActorSystem to some sort of graph - is there anything already done for that?
no platform requirements
Roger Johansson
@rogeralsing
Aug 31 2015 08:53
actorgraph.png
Im working on that right now
Oleg Gavrilov
@OlegGavrilov
Aug 31 2015 09:11
@rogeralsing looks good
Roger Johansson
@rogeralsing
Aug 31 2015 09:17
its a tool that joins an akka.net cluster and extracts the topology that way
Ryan Davis
@rdavisau
Aug 31 2015 10:33
I noticed that CONTRIBUTING.md is missing the command to run tests. (p.s. what is that command?)
Raymen Scholten
@raymens
Aug 31 2015 10:34
seems to be build.cmd RunTests
Ryan Davis
@rdavisau
Aug 31 2015 10:37
ty :star2:
Roger Johansson
@rogeralsing
Aug 31 2015 11:29
super noob question from me here, but anyone know what actually happens to applications during suspension? (e.g. screensaver or closed laptop) does it simply "pause" every process or what does it do technically?
Ryan Davis
@rdavisau
Aug 31 2015 11:30
I think screensaver will not suspend anything
but I have seen after suspending (e.g. sleep from the start menu or close lid) that some applications will log the fact that they noticed that the clock moved forward a significant amount, suggesting they were kind of just "paused"
Roger Johansson
@rogeralsing
Aug 31 2015 11:32
right , but you can set it so that after x time it goes to sleep completely, what happens to running processes during this? is it just as if they "freeze"
if we take akka.net for example, I can see that it stops sending anything during this time, but sockets seems to still be open and there are no disconnects, everything just continues as if nothing happened
Ryan Davis
@rdavisau
Aug 31 2015 11:36
curious - I have seen cluster nodes that had dropped coming back up after resuming, but that may be because they had a heartbeat time out, etc. in general I would expect connections to die on suspension because surely the interface would go down. I guess it might not count for localhost connections though
Anthony Brown
@bruinbrown
Aug 31 2015 12:15
I'm having a few difficulties using Barriers in the MultiNode tests, they work fine when they're running normally, but as soon as I attach a debugger, they just blow up and completely stop the test runner from continuing at all. I've narrowed it down to an ask timeout somewhere. Anybody seen anything like that?
This is the exception I'm seeing in the debugger
[NODE2][12:19 PM]: SPEC FAILED: Akka.DistributedData.Tests.MultiNode.ReplicatorS
pecNode2.ReplicatorSpecTests FAIL
[NODE2][12:19 PM]: SPEC FAILED: Type: System.AggregateException
[NODE2][12:19 PM]: SPEC FAILED: Type: System.Threading.Tasks.TaskCanceledExcepti
on
[NODE2][12:19 PM]: SPEC FAILED: Message: One or more errors occurred.
[NODE2][12:19 PM]: SPEC FAILED: Message: A task was canceled.
[NODE2][12:19 PM]: SPEC FAILED: StackTrace: at System.Threading.Tasks.Task.Th
rowIfExceptional(Boolean includeTaskCanceledExceptions)
[NODE2][12:19 PM]: SPEC FAILED: StackTrace:
[NODE3][12:19 PM]: SPEC FAILED: Akka.DistributedData.Tests.MultiNode.ReplicatorS
pecNode3.ReplicatorSpecTests FAIL
[NODE3][12:19 PM]: SPEC FAILED: Type: System.AggregateException
[NODE3][12:19 PM]: SPEC FAILED: Type: System.Threading.Tasks.TaskCanceledExcepti
on
[NODE3][12:19 PM]: SPEC FAILED: Message: One or more errors occurred.
[NODE3][12:19 PM]: SPEC FAILED: Message: A task was canceled.
[NODE3][12:19 PM]: SPEC FAILED: StackTrace: at System.Threading.Tasks.Task.Th
rowIfExceptional(Boolean includeTaskCanceledExceptions)
[NODE3][12:19 PM]: SPEC FAILED: StackTrace:
Anthony Brown
@bruinbrown
Aug 31 2015 12:20
*test runner not debugger
Roger Johansson
@rogeralsing
Aug 31 2015 12:25
could it be the recent addition of a Ask default timeout?
if the ask takes too long and the awaiting task is cancelled while you are debugging
or there is no ask involved in that flow at all?
Anthony Brown
@bruinbrown
Aug 31 2015 12:29
@rogeralsing There is an ask somewhere along the line, the difficulty is the exception only happens when a debugger is attached
Roger Johansson
@rogeralsing
Aug 31 2015 12:30
I know that @Aaronontheweb and someone else talked about disabling the heartbeat check if there was a debugger attached too, not sure if that have been implemented though
to avoid disassociation exceptions when debugging
Anthony Brown
@bruinbrown
Aug 31 2015 12:32
There doesn't even have to be a breakpoint though which is strange, if the debugger's attached but dormant the exception happens
Raymen Scholten
@raymens
Aug 31 2015 13:27
Is it somehow possible that akka.net will recreate an actor before the previous one is properly killed and releases the unique actor name?
and thus will not be able to recreate the actor instance because it's name is not unique
Raymen Scholten
@raymens
Aug 31 2015 13:53
Our system seems to have stopped working after updating to 1.0.4, investigating now
Bartosz Sypytkowski
@Horusiath
Aug 31 2015 13:54
@raymens how are you recreating an actor?
Raymen Scholten
@raymens
Aug 31 2015 13:55
@Horusiath yeah so it seems to be happening when an actor accepts _ (F#) as a message. Changing this to () fixes this.
_ works fine on 1.0.3
and any version before that (including 0.8)
Bartosz Sypytkowski
@Horusiath
Aug 31 2015 13:59
code sample?
if I'm right only change in 1.0.4 for F# API was a hack over JSON.NET to handle at least some of the Discriminated Union message serializations
Raymen Scholten
@raymens
Aug 31 2015 14:00
Yeah I saw that when I looked into the changelog
I'll try to create a simple reproduce
@Horusiath It's basically this:
let getWhateverHandler (mailbox : Actor<'a>) _ =
    mailbox.Sender() <! someResult

let parentMessageHandler (mailbox : Actor<KeyMessage>) =
    let getWhateverChildActor = spawn mailbox "Whatever" (actorOf2 getWhateverHandler)

    let messageHandler (msg : KeyMessage) =
        let keys =
            async {
                let! blabla = getMWhateverChildActor <? ()
            } |> Async.RunSynchronously

    let rec loop() =
        actor {
            let! msg = mailbox.Receive()
            messageHandler msg
            return! loop()
        }
    loop()
Bartosz Sypytkowski
@Horusiath
Aug 31 2015 14:03
what is the KeyMessage?
Raymen Scholten
@raymens
Aug 31 2015 14:04
A DU. But that seems to be receiving just fine
When I debug, it gets to let! blabla = getMWhateverChildActor <? (). But not into the getWhateverHandler. Unless I change the _ to ()
Raymen Scholten
@raymens
Aug 31 2015 14:10
@Horusiath Oh and I just saw actually replied to your question about a different question. The recreating of an actor is a different issue :)
Bartosz Sypytkowski
@Horusiath
Aug 31 2015 14:12
could you set an issue on github for those? I don't want to loose track
Raymen Scholten
@raymens
Aug 31 2015 14:13
@Horusiath about the recreating, the actors crashed because of an exception (http request gone wrong) inside the actor. We use the default supervisor settings etc.
sure
for both I presume?
Bartosz Sypytkowski
@Horusiath
Aug 31 2015 14:13
yes
Raymen Scholten
@raymens
Aug 31 2015 14:31
@Horusiath One of the issues: akkadotnet/akka.net#1285 with a small sample
Bartosz Sypytkowski
@Horusiath
Aug 31 2015 14:35
thx
Raymen Scholten
@raymens
Aug 31 2015 14:43
No thank you :)
Aaron Stannard
@Aaronontheweb
Aug 31 2015 15:08
@bruinbrown @rogeralsing haven't implemented that yet
Aaron Stannard
@Aaronontheweb
Aug 31 2015 16:44
@garrardkitchen glad you liked the article! That's more or less how I designed MarkedUp In-App Marketing but with Akka.Remote only, since Akka.Cluster didn't exist at the time. Had my REST API (stateless) pipe all relevant messages to my in-app marketing nodes and they would accumulate, aggregate, and filter state for key events
each of the stateful nodes represented all possible campaigns for all users as FSM actors
and it would only have actors alive for users who had triggered an event within the past 60 seconds, so I could keep our memory consumption bounded
all state transitions for any of those FSMs would be persisted to Cassandra (did this manually, since no Akka.Persistence either)
and those actors could be rehydrated back into their previous state later if the user became active again
scaled beautifully and delivered amazingly fast response times
Aaron Stannard
@Aaronontheweb
Aug 31 2015 16:50
@bobanco mr. @bruinbrown has been working on it - you two should link up
Anthony Brown
@bruinbrown
Aug 31 2015 16:54
@Aaronontheweb finished porting it across, just porting across specs but I've been hitting some problems I mentioned above
Bartosz Sypytkowski
@Horusiath
Aug 31 2015 16:57
#1287 - I've added xunit 2 equivalent of console output logger
Aaron Stannard
@Aaronontheweb
Aug 31 2015 23:52
kind of sitting off on its own at the moment