These are chat archives for akkadotnet/akka.net

11th
Aug 2015
jweimann
@jweimann
Aug 11 2015 00:31
what's the best implementation for getting messages from an async source in an actor then getting that sent into the system? was about to copy my old implementation and realized someone probably has a better way to do it
specifically a prism msg being sent from the aggregator to the actor
Roger Johansson
@rogeralsing
Aug 11 2015 05:49
@Horusiath akkadotnet/akka.net#1232 .. all tests passes locally
Bartosz Sypytkowski
@Horusiath
Aug 11 2015 07:05
@rogeralsing I'll try it myself today evening or tomorrow morning
Bartosz Sypytkowski
@Horusiath
Aug 11 2015 07:30
this info about serializing delegates and expressions is great, esspecialy when I think about using become in persistent actors
k0dem0nkey
@k0dem0nkey
Aug 11 2015 08:26
Hi all. I hope this is the right place to ask a question that has been asked (usually regarding the JVM version), but for which I can't find a conclusive answer. Is it possible to build a system in Akka.NET that supports both real-time usage, as well as a 'discrete-event simulation mode' where the passage of time (and hence temporal semantics of message processing) is under the control of the simulation?
Specifically, this is for an algorithmic trading engine that would run in real-time for live use, but must also be able to run backtests where large amounts of historical data are replayed as a discrete-event simulation. In order for the simulation to be deterministic, it must be able to ensure e.g. all messages posted at a certain simulated time have finished being processed by downstream actors before time advances to the next scheduled event.
k0dem0nkey
@k0dem0nkey
Aug 11 2015 08:40
(Obviously it could be done explicitly with a rather involved signalling protocol between actors; my hope is that it wouldn't have to come to that). I've previously implemented this kind of system in a non-Actor-based fashion by scheduling callbacks (akin to messages in the Actor model) with a Scheduler class that maintains a time-ordered queue of events. For real-time use, the scheduler uses the real time clock and multiple threads, while for backtests it uses a single thread (to ensure determinism) that loops until no further events are scheduled, at which point the simulation is complete. Is it possible to do something simular in Akka.NET?
k0dem0nkey
@k0dem0nkey
Aug 11 2015 08:58
Also if it's not currently supported but wouldn't require huge changes and is of interest to others, I'm happy to have a go at it if someone could help point me in the right direction.
Roger Johansson
@rogeralsing
Aug 11 2015 09:08
@k0dem0nkey as this is .NET, we can only support "soft" realtime as we cant really prevent garbage collection pauses. and the same ofc applies to Java.. regarding simulated time, we do have some support for it using virtual time, there is support for changing how fast time passes for our scheduler. there is also an ongoing work for a PR to provide virtual time support.. I do however not know exactly how extensive that effort is aiming to be as there are a lot of things that can take time into consideration, eg. .NET's Task Parallel Library, so we can not force that to behave differently, only modify time values passed to it
Its a vague answer but its the best I can give atm
tstojecki
@tstojecki
Aug 11 2015 09:37
has anyone had any 'real world' experience with the eventstore persistence plugin?
just by looking at the repo, it appears to be slightly behind - no nuget package, no readme....
just some small warning signs when compared to other plugins
k0dem0nkey
@k0dem0nkey
Aug 11 2015 09:54
Thanks for the info Roger. Soft real-time is fine (no ultra low-latency requirement); the big question mark I think is on the simulation side. Just speeding up the passage of time alone naturally magnifies any processing delays (e.g. if it takes 1ms to process a message in real-time, having 'virtual time' running 1000x real-time means that message now takes 1 virtual second). That's why it really needs to run as a discrete event simulation where time only advances once all processing for the current simulated time has been completed
k0dem0nkey
@k0dem0nkey
Aug 11 2015 10:06
I.e. simulated/virtual time needs to be completely disconnected from real time/wall clock time
I can't see any PRs/GitHub branches that are obviously related; do you know if this ongoing work is currently public?
Aleksandrs
@sonicflare
Aug 11 2015 11:00
has anyone tried to do something like spray?
i'm looking to owin webapi, that does not have a lot of dependencies, to contruct webapi controller on the other end of pipe
Anthony Brown
@bruinbrown
Aug 11 2015 11:07
@sonicflare there's talk that a bit further down the line Akka-Http will be ported across but it has a few dependencies which haven't been ported yet
Aleksandrs
@sonicflare
Aug 11 2015 11:10
@bruinbrown how do you plan to make http resource configuration? asp.net webapi, nanyfc, spray configuration, spray dsl?
Anthony Brown
@bruinbrown
Aug 11 2015 11:16
@sonicflare Akka-Http is an existing Akka project by the developers of Spray and Tyrpesafe designed to make a HTTP API interface which works directly with actors themselves http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala/http/
@sonicflare If you're not wanting to wait for the release of Aka.Http then it's possible to use any of the existing HTTP API libraries (ASP.Net WebAPI, Nancy, WCF etc) and there's a couple of options on getting your API endpoints connected to your actor system
Aleksandrs
@sonicflare
Aug 11 2015 11:21
@bruinbrown yeah, that looks like the stuff. but will you keep the route configuration compatible?
val route =
path("order") {
get {
complete("Received GET")
} ~
post {
decodeRequest(Gzip) {
complete("Received POST")
}
}
}
Anthony Brown
@bruinbrown
Aug 11 2015 11:22
I don't know yet, it's still a few months off, somebody else might know more than me about it though
Aleksandrs
@sonicflare
Aug 11 2015 11:22
@bruinbrown yeah, im currently looking to just throw HttpResponse messages to sent from a actor, and a client webapi controller generator based on some interface + attribute
fair enough
Anthony Brown
@bruinbrown
Aug 11 2015 11:24
@sonicflare I seem to remember somebody in here doing something with HttpListener where they passed the request context to an actor and then worked with it like that, I can't remember who it was though
Thomas Tomanek
@thomastomanek
Aug 11 2015 12:14
@tstojecki I've used it on a non production system at home but yes you're right, it is behind and would be wary using it in prod at the moment, if only because there are no tests. But it's not far off from being ready, wouldn't take long to write a build script for it to package it up and write some tests
tstojecki
@tstojecki
Aug 11 2015 12:59
i see, thanks for the update @sadprofessor
Aaron Stannard
@Aaronontheweb
Aug 11 2015 16:28
@tstojecki yep, ask @tnrbrgr about it
whoops, I meant @trbngr
Bartosz Sypytkowski
@Horusiath
Aug 11 2015 20:10
@rogeralsing how do we use serialization manifests right now? If they are not empty they are recognized as fully qualified type names, right?
Weston
@ronnyek
Aug 11 2015 20:11
so I assume the IO stuff made it out
allowing for tcp connections etc?
Aaron Stannard
@Aaronontheweb
Aug 11 2015 20:14
@ronnyek yessir it did
as part of 1.0.4
Bartosz Sypytkowski
@Horusiath
Aug 11 2015 20:14
@ronnyek yes, but there are still a little CPU overuse problems
(however it looks like it will be fixed soon)
Weston
@ronnyek
Aug 11 2015 20:16
sweet
are there specific demos of that somewhere?
Aaron Stannard
@Aaronontheweb
Aug 11 2015 20:18
has an example and explains how it works
Weston
@ronnyek
Aug 11 2015 20:18
thank you thank you!
Bartosz Sypytkowski
@Horusiath
Aug 11 2015 20:18
I've created an echo server example. You can invoke it with standard telnet
Roger Johansson
@rogeralsing
Aug 11 2015 20:19
@Horusiath yes
its used for serializers that dont embed type info in the payload
Bartosz Sypytkowski
@Horusiath
Aug 11 2015 20:32
@Aaronontheweb it think, that Akka.IO should be mentioned to the wider audience. Right now it's came quite siliently with 1.0.4.
Roger Johansson
@rogeralsing
Aug 11 2015 20:32
Btw, the migrant guys are already pushing fixed for that fsi bug
Bartosz Sypytkowski
@Horusiath
Aug 11 2015 20:33
I think this is a great point for IoT
@rogeralsing thats great. I can't wait to play with it, unfortunatelly I'm stuck with event adapters atm :/
Roger Johansson
@rogeralsing
Aug 11 2015 20:34
Throw some mqtt love at akka io and people will talk about it
Evert Mulder
@evertmulder
Aug 11 2015 20:34
When I use Akka.IO and the client sends its message really quick <5ms the server receives the message as 1 single message. Is this the expected behavior?
Bartosz Sypytkowski
@Horusiath
Aug 11 2015 20:35
@evertmulder could you precise what do you mean?
Roger Johansson
@rogeralsing
Aug 11 2015 20:36
Thats normal socket behavior afaik , cc @Aaronontheweb
Aaron Stannard
@Aaronontheweb
Aug 11 2015 20:38
@rogeralsing we have an Mqtt codec for DotNetty already
Evert Mulder
@evertmulder
Aug 11 2015 20:39

On the client side I pass a message like this:

                   Thread.Sleep(3);
                    count++;

                    connection.Tell(Tcp.Write.Create(ByteString.FromString((string)count.ToString() + "\n")));
                    if (count < 10)
                    {
                        Self.Tell(count.ToString());
                    }

where connection is the TCP connection

On the serverside I sometime receive multiple send messages

        protected override void OnReceive(object message)
        {
            if (message is Tcp.Received)
            {
                var received = message as Tcp.Received;
                string data = received.Data.DecodeString();
                string[] parts = data.Trim().Split(stringSeparators, StringSplitOptions.None);
                if(parts.Length==1)
                    Console.WriteLine("OK - {0}",parts[0]);
                else
                    Console.WriteLine("NOK - {0}", string.Join(", ", parts));
            }
            else
            {
                Console.WriteLine("Unhandled");
                Unhandled(message);
            }
        }
Aaron Stannard
@Aaronontheweb
Aug 11 2015 20:41
ah yes my son
Evert Mulder
@evertmulder
Aug 11 2015 20:41
On the server side the NOK is printed to the console, indicating the TCP.Received data contained multiple sepperately send messages. If that makes sens.
Aaron Stannard
@Aaronontheweb
Aug 11 2015 20:41
welcome to the world of message framing
Evert Mulder
@evertmulder
Aug 11 2015 20:42
I can work around this, but is it a bug or something to expect...
Aaron Stannard
@Aaronontheweb
Aug 11 2015 20:43
this is something to expect
so the way sockets work is much more low-level than we're used to with web requests
you can potentially have multiple messages all written to the buffer between reads
so you have to use message framing, like you're doing using a separator
to parse the messages out of the buffer
Andrew's post on large socket messages in Akka.NET explains this pretty well https://petabridge.com/blog/large-messages-and-sockets-in-akkadotnet/
Roger Johansson
@rogeralsing
Aug 11 2015 20:46
Nice
Is there any progress going on there?
Evert Mulder
@evertmulder
Aug 11 2015 20:46
@Aaronontheweb aha nice. Thanks for clearing this up. Perhaps something to add to the Akka.IO telnet sample
Aaron Stannard
@Aaronontheweb
Aug 11 2015 20:47
@rogeralsing yeah, I set up CI for it last week
having some discussions now about whether or not we should strong sign the NuGet package
the Microsoft guys want us to
me on the other hand
nooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Roger Johansson
@rogeralsing
Aug 11 2015 20:48
:+1: :)
Aaron Stannard
@Aaronontheweb
Aug 11 2015 20:48
I'll create a Github issue for that
and invite some more opinions
I'm pretty excited about DotNetty - it's exactly what I wanted for Helios 2.0
only issue with it thus far is that because Microsoft owns the project, there's a much bigger process involved in how they do things like NuGet releases
not the fault of the developers who work on it
but I think that's getting better quickly - the guys who started it there really want to make it a successful OSS project
Roger Johansson
@rogeralsing
Aug 11 2015 20:51
So we fork it, patch it and they will follow the users over to us ;)
Aaron Stannard
@Aaronontheweb
Aug 11 2015 20:52
yeah, that'd be the nuclear option I suppose if the bureaucratic bottleneck became an insurmountable obstacle
I'm working on getting CI and some contribution guidelines set up so I can start directing people to the project
make it easier for other people to get involved
Anthony Brown
@bruinbrown
Aug 11 2015 21:06
How do we get at the MonotonicClock? It's not exposed anywhere as far as I can tell
Jonathan Ohlrich
@johlrich
Aug 11 2015 21:48
Are there any specific rules around when you can send the Tcp.Bind command to system.Tcp? I went to create an echo service via FSharp and the first naive way I went to proceed sends the Bound response to deadletters (it still received Connected though). I tried two other approaches to creating the actor and both received Bound + Connected alright
Roger Johansson
@rogeralsing
Aug 11 2015 22:01
in the first case, you are not inside the context of an actor, and thus, there is no Sender given to the <! operator
tell takes two arguments, message and sender. the last argument is optional and if you are inside an actor, Akka.NET will figure out who the current actor is and use that as sender.