These are chat archives for akkadotnet/akka.net

3rd
Nov 2017
kwojciechowski
@kwojciechowski
Nov 03 2017 11:42
Hi, could someone advice me please? I have 3 systems (client, server and hub). Client and server are running on the same VM and hub runs somewhere else in the world. I have set the public-hostname on the server, so the hub is able to connect and send/receive messages. But since I have public-host name set on the server, the server is dropping messages sent from the client (localhost). I receive the following entry in the server log file
Dropping message [Akka.Actor.ActorSelectionMessage] for non-local recipient [[akka.tcp://AppServer@localhost:8085/]] arriving at [akka.tcp://AppServer@localhost:8085] inbound addresses [akka.tcp://AppServer@xx.xx.xx.250:8085]
when I remove public-hostname from the server, then client can talk to the server
but hub no (as the pubhostname is gone)
Joshua Garnett
@joshgarnett
Nov 03 2017 12:51
@kwojciechowski yeah you need to always use the host configured in your messages. So you’d need to adjust your messages from the client. One way you could do this is just add a hosts entry for your domain name and point it to 127.0.0.1.
kwojciechowski
@kwojciechowski
Nov 03 2017 12:55
@joshgarnett thanks
Joshua Garnett
@joshgarnett
Nov 03 2017 12:56
The best parallel I can give is sorta how https works, if you hit the server with the wrong dns name it’s going to complain about the certs not matching.
I’ve personally never been a fan of how this works for Akka, but it’s been around in JVM Akka forever so I don’t see it changing.
Alexey Kushnikov
@akushnikov
Nov 03 2017 13:05
hi everyone, I'm a little bit confused with logging using Akka.Remote. Can I write to log incoming messages? I've seen an article that shows my case but without remoting. http://gigi.nullneuron.net/gigilabs/actor-logging-with-akka-net/
Rob Purcell
@RobPurcellUK
Nov 03 2017 16:19
Hello, hello. I've spent the whole day yesterday and half of today trying to figure something out, and I'm hoping someone her can help me. I have a new project at work which seems to fit akka nicely, so we're trying it out. Cluster with a few nodes, to segregate parts which are unstable (ODBC to Hadoop) or CPU intensive (OCR processing) from the rest (web ui, organisational stuff).
I'm seeing soem odd behaviour, in that some messages appear to just vanish.
this is when running the system locally for dev/debug, so it's all on one machine (Win 10). The apps are netcore 2 console / asp.net core 2
I've put together a simple reproduction of it here https://github.com/RobPurcellUK/akka-cluster-issue
Aaron Stannard
@Aaronontheweb
Nov 03 2017 16:22
hi @RobPurcellUK
are you seeing any disassociation error messages show up?
Rob Purcell
@RobPurcellUK
Nov 03 2017 16:23
the oddest bit is a console app sending itself a message succeeds 100% using direct local actor ref, but only about 80% using a group router to the same local actor
hi
Aaron Stannard
@Aaronontheweb
Nov 03 2017 16:23

the oddest bit is a console app sending itself a message succeeds 100% using direct local actor ref, but only about 80% using a group router to the same local actor

a cluster group router?

Rob Purcell
@RobPurcellUK
Nov 03 2017 16:23
no, none. I have that as another issue on a second projet
yes
Aaron Stannard
@Aaronontheweb
Nov 03 2017 16:24
so cluster group routers have a huge behavioral difference that folks need to be aware of
which is that unlike local routers
they add their routees at run-time as the cluster propagates MemberUp notifications
therefore, if you create a router and use it immediately afterwards (like one line after the other)
that router might be routing your messages over a bridge to nowhere
since it needs to get a notification back from an internal cluster actor about who is in the cluster right now
however, if you have a cluster router declared with allow-local-routees = true
those local routees should be available immediately
and the router, once it has its routees added, shouldn't drop messages
so are you seeing message drops happening after longer periods of time, i.e. after the router has been up for a couple of seconds?
Rob Purcell
@RobPurcellUK
Nov 03 2017 16:26
yep, got that. I'm delaying 5 seconds before starting the repeated ping, ignoring the logged failures before cluster members are up etc. The missing messages are in the middle of steady flow, gossip happening ec
Aaron Stannard
@Aaronontheweb
Nov 03 2017 16:26
(and there are suitable cluster nodes)
hmmm
Rob Purcell
@RobPurcellUK
Nov 03 2017 16:27
and even to the same node
with allow-local-routes = true
Aaron Stannard
@Aaronontheweb
Nov 03 2017 16:28
ok, let's file an issue then
Rob Purcell
@RobPurcellUK
Nov 03 2017 16:28
I can't see anything logged, down to debug logging level, that tells me where they go. not in deadletters
Aaron Stannard
@Aaronontheweb
Nov 03 2017 16:28
and I'll start an investigation
Rob Purcell
@RobPurcellUK
Nov 03 2017 16:28
ok, thanks
shall I raise it with info I've put here?
RoBiK75
@RoBiK75
Nov 03 2017 16:35
Hey Aaron, did you have time to think about my predicament with the multiple actors using the same CUDA context?
Aaron Stannard
@Aaronontheweb
Nov 03 2017 17:03
@RobPurcellUK yes, that would be helpful
@RoBiK75 not yet :(
I will though!
Bart de Boer
@boekabart
Nov 03 2017 20:38
For ease of debugging (unit tests or simple real code flows), it would be extremely useful to have a dispatcher that actually immediately processes the target mailbox (meaning, the just Telled message) if possible. Does anyone know of a dispatcher implementation like that?
RoBiK75
@RoBiK75
Nov 03 2017 21:19
CallingThreadDispatcher
Bart de Boer
@boekabart
Nov 03 2017 21:43
Sounds logical, thanks 1048576!
Rob Purcell
@RobPurcellUK
Nov 03 2017 21:59
Hi @Aaronontheweb - i was entering the issue and checking the repro code again to clean up a bit, and i just learnt something :-)Round robin router with a specified role and path to route to: It will try to route to that path on all nodes with that role, not what i thought would happen which is routing to the set of actors with that path on those nodes. Could you confirm that's the expected behaviour, please?
If I'm not being clear what I'm asking, tell me :-)
I'm saying it will round robin for to the nodes with that role, regardless of whether they have an actor at the specified path. The router registers the nodes when they come up, not the node+path
Rob Purcell
@RobPurcellUK
Nov 03 2017 22:05
The'missing' messages were being sent to the other console app node, which was dropping them in it's deadletters