These are chat archives for akkadotnet/akka.net

19th
Oct 2017
fleed
@fleed
Oct 19 2017 04:09
Is the .net core dependency injection supported in Akka.net?
I’d need to inject services from my asp.net core app into actors
Arjen Smits
@Danthar
Oct 19 2017 06:40
@fleed not at the moment. Work is being done to overhaul the actor creation pipeline. Supporting the .net core dependency interfaces is something we plan to support eventually.
Arsene T. Gandote
@Tochemey
Oct 19 2017 11:13
Hello Geeks I would like to know which routing strategy I should use when I want to spin a number of actors to do the same job in parallel and collate the result as it comes.
Roman Golenok
@shersh
Oct 19 2017 12:07
Guys, any examples of using Framing.LengthField() method in Tcp.Streaming?
Roman Golenok
@shersh
Oct 19 2017 12:19
or maybe FramingSimpleFramingProtocol ?
Aaron Stannard
@Aaronontheweb
Oct 19 2017 13:44
@shersh good question cc @Horusiath
@Tochemey I'd probably just use a round robin router and have the routees all reply to sender once they're finished processing
Arjen Smits
@Danthar
Oct 19 2017 13:47
@Tochemey scatter gather.
There are some aggregator patterns floating around. @Horusiath has a nice example on his blog: http://bartoszsypytkowski.com/dont-ask-tell-2/
Aaron Stannard
@Aaronontheweb
Oct 19 2017 13:52
@annymsMthd planned on doing the 1.3.2 release today
I'll wait until your consistent hash router issue is fixed
so we can pack that into this release
awb99
@awb99
Oct 19 2017 15:14
I am having an issue where a Actor is not receiving messages. I am logging the actorRef that the sender uses, and it is identical tot he Self ref of the actor that does not get messages. To test if I have "wired" the events correctly, I do send my actor a demo message of the same type, which it does process. Any ideas what it could be?
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:15
can't tell you without seeing the code
awb99
@awb99
Oct 19 2017 15:15
@Aaronontheweb Can I send you a code snippet?
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:15
go for it
awb99
@awb99
Oct 19 2017 15:16
https://pastebin.com/u6pE2TP6 this is the broker that keeps a list of subscriptions and sends received data to the subscriber
https://pastebin.com/eQeyKMdC this is the fxConverter. It subscribes for different currencies, and then answers requests from clients to do fx rate conversions.
https://pastebin.com/2XDuv1D5 this is the logfile
In the fxConverter I am saving var MySelf = this.Self ,
so that I can pass the correct subscriber reference to the broker,
My summary is this: the sender is sending the correct message to the fxConverter; and fxConverter has the events linked correctly. The only issue that could be, that the fxConverter is not running anymore.
awb99
@awb99
Oct 19 2017 15:21
Like something would block receiving a specific message type.
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:22
can you point to the single line where the send is being executed?
awb99
@awb99
Oct 19 2017 15:22
I use the broker code also with other actors,
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:22
this is usually a pretty easy error to spot
if you can save me the trouble of digging through all of that
awb99
@awb99
Oct 19 2017 15:23
subscribers.ForEach(subscriber =>
{
Console.WriteLine($"Sending Market data to subscriber {subscriber} {marketData.symbol} {marketData.last}..");
subscriber.Tell(marketData);
});
subscriber.Tell(marketData);
I dont think that it is an issue in Sending the data.
Because the broker actor which is sending,
it does send it to other receipients
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:32
hmmm
don't see any deadletter or unhandled message notifications in the log
so the message is going somewhere
awb99
@awb99
Oct 19 2017 15:32
I am just doing Console.WriteLine
how can I init deadletter or unhandle message notifications?
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:33
the built-in Akka.NET logger
will write that stuff out to the console by default
or any other logging target you setup inside the akka.loggers configuration section
awb99
@awb99
Oct 19 2017 15:33
oh
the logger is complaining somewhere
[WARNING][10/19/2017 3:33:50 PM][Thread 0001][ActorSystem(TradingSystem)] NewtonSoftJsonSerializer has been detected as a default serializer. It will be obsoleted in Akka.NET starting from version 1.5 in the favor of Hyperion (for more info visit: http://getakka.net/docs/Serialization#how-to-setup-hyperion-as-default-serializer ). If you want to suppress this message set HOCON akka.suppress-json-serializer-warning config flag to on.
Dashboard created for BTC with 3
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:34
that reminds me...
awb99
@awb99
Oct 19 2017 15:34
I will setup the logging convert, and revert.
I think all my code is clean.
I spent all day long looking at this bug.
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:38
that warning is no big deal
going to remove it today actually
but yeah, you need the deadletter / unhandled message logs
the stuff you're logging isn't checking for the absence of anything
only the presence
the deadletter system automatically logs any messages that couldn't be delivered
and unhandled message system records messages which were received but not handled by an actor
if you don't have one of those two warnings
it means that your message is being handled by your own code
awb99
@awb99
Oct 19 2017 15:40
ok
thanks!
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:40
or, alternatively
that you're never sending the message in the first place
i.e. no Tell call to that actor
Jack Wild
@jackowild
Oct 19 2017 15:46
My team have an actor system running in a web api which connects to another actor system running as a windows service using akka remote (ask from the api, Sender.Tell from the windows service). If we restart the windows service, the asks from the api no longer receive a reply. In the windows service there is a log:
2017-10-19 16:13:56.702 +01:00 [Information] "Message MyMsg from akka.tcp://TestSystem@127.0.0.1:2104/temp/6 to akka://TestSystem/user/Views/Test was not delivered. 1 dead letters encountered."
This seems strange as the remote actor system receives the message but it doesn't forward it down to the actor and send a reply. To get this working we have to restart/recycle the web api. This is annoying as every time we release a change to the service we have to recycle the web api. My team did not have this problem before we upgraded from 1.0.8 to 1.3.1. Any ideas on how to avoid this?
awb99
@awb99
Oct 19 2017 15:48
I got the logging,
I have unreceive dmessages
It looks like the broker sends the market data message to itself.
how bizarre
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:49
looks like it
awb99
@awb99
Oct 19 2017 15:50
No. I was wrong. The broker sends the message to fxConverter, and in fxConverter it is unhandled.
So fxConverter does not handle them.
How can this be??
fxConverter does handle my test message that I send on startup correctly.
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:52
fxConverter is programmed to handle a list of market data
awb99
@awb99
Oct 19 2017 15:52
aHHH
I found it.
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:52
not an individual marketData message
awb99
@awb99
Oct 19 2017 15:52
It is receiving the list.
FUCK.
AMATEUR MISTAKE.
ahhhhhh
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:52
lol
awb99
@awb99
Oct 19 2017 15:52
@Aaronontheweb 100,000 thanks
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:52
you're welcome!
I've been building some fintech stuff on top of Akka.NET too
I feel your pain :p
awb99
@awb99
Oct 19 2017 15:53
I am just playing around for the moment.
I really like the concept.
But my brain needs to get completely rewired.
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:53
I'm doing real-time pricing / volume / trends analysis on order book data
awb99
@awb99
Oct 19 2017 15:53
There are some of the simple things that are pain.
Oh nice.
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:54
yeah the real trick with Akka.NET and the actor model
is not the syntax
it's the paradigm shift
awb99
@awb99
Oct 19 2017 15:54
I have found some mispricing in bitcoin across countries.
So want to write a very simple arbitrage robot.
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:54
the change in your thinking that it requires
shifting from invoking methods to sending messages
awb99
@awb99
Oct 19 2017 15:54
Yeah!
Exactly!
Actually, the switching to messages I sort of digested quickly,
because all the middleware is messenging based,
I used ZMQ or websocket to send verious data.
various.
So somehow it comes handy, that the complete app is internally also messenging mased.
I typically end up with Task issues.
Or knowing when Self is available and when not.
And how to get the message passed back to the queue.
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:56
Self is available in the context of an actor handling a message right now
but otherwise it's not
need a closure over the IActorRef otherwise
another thing we see often that trips users up is how the actor async paradigm works differently
awb99
@awb99
Oct 19 2017 15:57
What I noticed a lot,
is that when I write async functions,
then basically I get a Task of a Task.
Roman Golenok
@shersh
Oct 19 2017 15:57
@Aaronontheweb lol, but someone is still trying to do the opposite: https://github.com/SaladLab/Akka.Interfaced
awb99
@awb99
Oct 19 2017 15:57
I now ended up using a lot Task funcitons,
because async cannot return data.
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:58
@shersh I think that's a cool project actually
until we add something like Typed actor references in the future
that's probably the next best thing
there's some value in it
I personally kind of like the untyped nature of IActorRef
awb99
@awb99
Oct 19 2017 15:58
I am speaking more,
like when you branch out from the OnReceive methods,
then at some point I want to use async.
Roman Golenok
@shersh
Oct 19 2017 15:59
yeah, but i have a pain with this project. Code smells and author doesn't answer anywhere. And last commit was 1+ year ago (
awb99
@awb99
Oct 19 2017 15:59
and async functions that pass values back.
Aaron Stannard
@Aaronontheweb
Oct 19 2017 15:59
@jackowild ah, this is a bug we fixed
back in 1.1
TL;DR; before 1.1 if you had two actor systems communicating via Akka.Remote
system A has a reference to an actor on system B
if system B restarts and recreates that actor
the original actor reference system A had could still be used to deliver messages to the actor on System B
which is wrong - technically the actor reference on system A is dead. Points to a previous "incarnation" of that actor
in 1.1 we introduced the concept of UIDs to actors, which is something that the JVM had too
which is that each actor reference gets versioned
so long as that actor is alive, the UID on the actor ref and the actor's UID will match
and thus the messages sent to that actor reference can be delivered
however... if the actor is stopped and recreated with the same name
or if the process it's on is restarted and the actor is recreated
the old actor reference is correctly invalidated now
and won't allow you to deliver messages any more
awb99
@awb99
Oct 19 2017 16:03
cool
Aaron Stannard
@Aaronontheweb
Oct 19 2017 16:03
what you'll want to do in your scenario is have system A death watch (Context.Watch) the actor reference
on system B
and then re-acquire that actor reference once system B restarts
either that or use an ActorSelection to communicate with the actor
Jack Wild
@jackowild
Oct 19 2017 16:04
that explains it. Thanks a lot @Aaronontheweb
Aaron Stannard
@Aaronontheweb
Oct 19 2017 16:04
ActorSelection is less performant but doesn't have that restriction
it doesn't care about UIDs
you're welcome
Jack Wild
@jackowild
Oct 19 2017 16:05
I think we'll go with the death watch approach as we've also noticed it no longer logs when it detects the remote actor is no longer there
Aaron Stannard
@Aaronontheweb
Oct 19 2017 16:05
there's some inconsistency right now in how we handle dead letter logging over the network I think
the dead letter should be logged locally if you can't connect
remotely if you can connect but the actor reference doesn't exist
but I think there are some scenarios right now, like when a clustered router has no routees, where nothing gets logged
which is... not great
Jack Wild
@jackowild
Oct 19 2017 16:08
we recycle our web apis every night. Previously the remote actor systems it connected to would log an error when the recycle occurred. This doesn't happen anymore
Aaron Stannard
@Aaronontheweb
Oct 19 2017 16:15
well that's good
we've tried to keep the superfluous Akka.Remote connection error stuff out of the logs
Jack Wild
@jackowild
Oct 19 2017 16:16
is it? It was quite useful to know when the connection between the actor systems had dropped
Aaron Stannard
@Aaronontheweb
Oct 19 2017 16:16
we still log an info level message when it's a planned disconnect
and unplanned ones still og an error messge
Jack Wild
@jackowild
Oct 19 2017 16:22
strange, we're not seeing that in our logs. If we stop the api, the remote systems it was connected to don't log anything
Aaron Stannard
@Aaronontheweb
Oct 19 2017 16:22
are you sure the underlying socket gets reset?
that might be related to the DotNetty migration in 1.2.
Jack Wild
@jackowild
Oct 19 2017 16:23
ok, i'll check your release notes
Roman Golenok
@shersh
Oct 19 2017 17:30

I don't understand how TcpStreams works (
In "normal" Context.System.Tcp() I understand that messages like Tcp.Received is received new chunk of data and for sending data to client I need to tell Tcp.Write to connection actor.
But

Source<Tcp.IncomingConnection, Task<Tcp.ServerBinding>> connections =
    Sys.TcpStream().Bind("127.0.0.1", 8888);

connections.RunForeach(connection =>
{
    Console.WriteLine($"New connection from: {connection.RemoteAddress}");

    var echo = Flow.Create<ByteString>()
        .Via(Framing.Delimiter(
            ByteString.FromString("\n"),
            maximumFrameLength: 256,
            allowTruncation: true))
        .Select(c => c.ToString())
        .Select(c => c + "!!!\n")
        .Select(ByteString.FromString);

    connection.HandleWith(echo, Materializer);
}, Materializer);

Is absolutely unclear.

Aaron Stannard
@Aaronontheweb
Oct 19 2017 22:46
@shersh whoops, just saw this
sigh.... yeah... the Akka.Streams.IO stuff is not something I've used much nor wrapped my head around
I use Akka.Streams and Akka.IO heavily in production, but not the integration of the two that's been fine-tuned as of 1.3.0
we need some better examples and documentation around that
Akka.Streams and Akka.IO both individually need better documentation too
that syntax you're looking at, for instance, is an incoming TCP server
which spawns a brand new graph for each incoming connection which.... for reasons I totally do not understand (correction, I get it now)...
reads the incoming byte array, uses the built-in message framing, stringifies the output, updates the string, and then converts it to a byte array again
I suppose on that connection object, it's a sink that takes some sort of source as an input
which that Flow is, in essence
so it'll get echo'd back to the original sender on the other side of that connection
the thing that needs to be made clear here is how each part of the Stream relates to the individual clients, where the input comes from, etc
because if you're not already familiar with Streams this will look like Greek
(no offense to our actual Greek users, we love you)