These are chat archives for akkadotnet/akka.net

21st
Sep 2017
Ismael Hamed
@ismaelhamed
Sep 21 2017 05:24 UTC
I think my next software company is just going to automate away front-end development in its entirety, mostly out of spite for JavaScript developers specifically
what about FrontPage for a name?
Andrew Spiering
@wackoisgod
Sep 21 2017 05:54 UTC
Lol
Vagif Abilov
@object
Sep 21 2017 06:53 UTC
@wackoisgod Thanks for the information. Yes, they are entitled to their own versioning policies, for us it just means more yakshaving.
Joshua Garnett
@joshgarnett
Sep 21 2017 11:07 UTC
It caused us a little bit of a headache, since we treat warnings as errors and I couldn’t find an easy way to resolve that warning without just turning it off.
sebhaub
@sebhaub
Sep 21 2017 12:04 UTC
hi there. a question regarding best practices. are there any tips in how to document the "api" of an actor? i mean something like which messages are handled and what responses are generated?
Alex Michel
@amichel
Sep 21 2017 13:17 UTC
image.png
after upgrade to 1.3.1/1.3.2 actor paths in sharded cluster are now under system and not under user path as they were before
I had to change all paths to /system/sharding/ in clients
Joshua Garnett
@joshgarnett
Sep 21 2017 13:22 UTC
I believe that more closely matches with the JVM Akka impl. Out of curiousity, why are you hard coding paths?
Alex Michel
@amichel
Sep 21 2017 13:22 UTC
I didn't say I am hardcoding
but in tester code the prefix actually was hardcoded to /user/sharding/
Joshua Garnett
@joshgarnett
Sep 21 2017 13:23 UTC
oh interesting
Alex Michel
@amichel
Sep 21 2017 13:23 UTC
btw, cmd plugin appears under user
Joshua Garnett
@joshgarnett
Sep 21 2017 13:24 UTC
@Aaronontheweb might have some more thoughts on that.
Alex Michel
@amichel
Sep 21 2017 13:24 UTC
so to get full hierarchy I had to set system address explicity
couldn't use default of actor hierarchy
it would return only cmd actors - not my system
Aaron Stannard
@Aaronontheweb
Sep 21 2017 14:04 UTC
@amichel yeah, the cmd plugin actors live under the /user hierarchy because I didn't want to access the "SystemActorOf" method, which is internal :p
the way it works by default is we query everything under the /user root by default
wrote it that way because I didn't think users would be interested in the /system hierarchy, but it turns out you can hack it to get that information anyway
you can also use that tool to query the hierarchy of a remote actor system that doesn't have Petabridge.Cmd installed on it, btw
just need to pass in the root address of that node
do you think I should query the root guardian by default and expose all of the /system actors too?
that'd be an easy change to make
Thomas Denoréaz
@ThmX
Sep 21 2017 17:54 UTC
Hi! I have a really weird problem and I'm wondering wether it can be a bug with Akka.Remote, I'm using Akka 1.3.1 on .NET Core 2 on OSX, I implemented a simple Ping-Pong using Remote, the Ping is sent and received, but the Pong can't be received. It is like all communication from client to server is working but not from server to client. Any idea?
Joshua Garnett
@joshgarnett
Sep 21 2017 17:54 UTC
How are you sending your reply, does your Tell on the Ping side include the reference to the sender?
Thomas Denoréaz
@ThmX
Sep 21 2017 17:55 UTC
I basically did Sender.Tell("pong", Sender)
I checked the Sender and it's a RemoteActorRef
Joshua Garnett
@joshgarnett
Sep 21 2017 17:56 UTC
Should be something like:
remoteActorRef.Tell(“ping”, Self)
Sender.Tell(“pong”, Self)
Thomas Denoréaz
@ThmX
Sep 21 2017 17:58 UTC
Sender is a RemoteActorRef
Aaron Stannard
@Aaronontheweb
Sep 21 2017 18:00 UTC
Sender.Tell("pong") is the way to go - looks like one of the nodes is replying back to itself
Thomas Denoréaz
@ThmX
Sep 21 2017 18:01 UTC
I guess it's worth mentioning that by activating all the logs, an ActorIdentity is received from the destination ActorRef, but no pong afterwards
Tried Sender.Tell("pong") but it's not working either :(
I don't see any receive message from RemoteLogging
Joshua Garnett
@joshgarnett
Sep 21 2017 18:02 UTC
what does the ping side look like?
Thomas Denoréaz
@ThmX
Sep 21 2017 18:04 UTC

Client:
[DEBUG][9/21/17 5:49:45 PM][Thread 0011][[akka://abc-extension/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2Fabc%40localhost%3A8081-1/endpointWriter#356171488]] received local message [RemoteMessage: <ActorIdentity>: [akka.tcp://abc@localhost:8081/user/transporter#944672290] - MessageId= to [akka://abc-extension/temp/f]<+akka://abc-extension/temp/f from [akka.tcp://abc@localhost:8081/user/transporter#944672290]]

Server:
pointWriter#827780461]] received local message [RemoteMessage: ping to [akka://abc/user/transporter#944672290]<+akka://abc/user/transporter from [akka.tcp://abc-extension@localhost:8082/user/transporter#52061278]]
[DEBUG][9/21/17 5:49:45 PM][Thread 0005][[akka://abc/user/transporter#944672290]] ping from [akka.tcp://abc-extension@localhost:8082/user/transporter#52061278] Akka.Remote.RemoteActorRef

Aaron Stannard
@Aaronontheweb
Sep 21 2017 18:05 UTC
ohhhhhhhh man.... is the issue that you're replying over and over again to the temporary actor created for an Ask ?
Thomas Denoréaz
@ThmX
Sep 21 2017 18:05 UTC
Nop there's no Ask
Aaron Stannard
@Aaronontheweb
Sep 21 2017 18:05 UTC
akka://abc-extension/temp/f
the /temp part of the actor hierarchy is reserved for one-off actors
the only one of which we really use much is the FutureActorRef for Ask operations
you as an end-user can't manually create an actor there
Thomas Denoréaz
@ThmX
Sep 21 2017 18:06 UTC
Yeah but I'm not the one creating this actor
It is just what I received
Aaron Stannard
@Aaronontheweb
Sep 21 2017 18:07 UTC
IMHO, you should post the ping side code
save everyone a lot of trouble
Thomas Denoréaz
@ThmX
Sep 21 2017 18:07 UTC
var transporter = actorSystem.ActorOf(Transporter.Props(), Transporter.Name);
var remoteTransporter = await actorSystem.ActorSelection(remoteUrl + Transporter.Name).ResolveOne(timeout);
remoteTransporter.Tell("ping", transporter);
Aaron Stannard
@Aaronontheweb
Sep 21 2017 18:07 UTC
var remoteTransporter = await actorSystem.ActorSelection(remoteUrl + Transporter.Name).ResolveOne(timeout);
uses Ask internally
what does the pong side actor code look like
Thomas Denoréaz
@ThmX
Sep 21 2017 18:08 UTC
That's inside my Actor
case "ping":
                {
                    _log.Debug($"ping from {Sender} {Sender.GetType()}");
                    Sender.Tell("pong", Self);
                    break;
                }

                case "pong":
                {
                    _log.Debug($"pong from {Sender}");
                    break;
                }
Aaron Stannard
@Aaronontheweb
Sep 21 2017 18:08 UTC
although you can't really cache the sender on an ActorIdentity call
since that gets handled automatically
ok, that looks fine
and you never receive the "pong" ?
Thomas Denoréaz
@ThmX
Sep 21 2017 18:09 UTC
Nop
Aaron Stannard
@Aaronontheweb
Sep 21 2017 18:09 UTC
what does that debug line you're logging say?
Thomas Denoréaz
@ThmX
Sep 21 2017 18:10 UTC
DEBUG][9/21/17 5:49:45 PM][Thread 0005][[akka://jita-vision/user/transporter#944672290]] ping from [akka.tcp://jita-vision-extension@localhost:8082/user/transporter#52061278] Akka.Remote.RemoteActorRef
Aaron Stannard
@Aaronontheweb
Sep 21 2017 18:11 UTC
looks right
so have you tried to setup a break point inside that actor and see if it gets hit before your switch statement?
Thomas Denoréaz
@ThmX
Sep 21 2017 18:13 UTC
I tried, but it does not go into
I also have log-received-messages = on in my config and don't see any pong
Aaron Stannard
@Aaronontheweb
Sep 21 2017 18:13 UTC
well, the Akka.Remote connection is fine otherwise you'd be seeing screaming red error messages
Thomas Denoréaz
@ThmX
Sep 21 2017 18:14 UTC
Well the message just disappears, I would prefer red stuff, at least I would know where to look :D
Aaron Stannard
@Aaronontheweb
Sep 21 2017 18:14 UTC
without looking at it more I don't know what to tell you - try cloning some of our samples and see if you can make those work
the message has to go somewhere when you Tell it, dead letters being the ultimate destination
Thomas Denoréaz
@ThmX
Sep 21 2017 18:14 UTC
do you think is is an dotnet core issue on mac os?
Aaron Stannard
@Aaronontheweb
Sep 21 2017 18:15 UTC
people have been able to run Akka.Cluster natively on OS X just fine
but I don't know to be honest, never tried it myself
Thomas Denoréaz
@ThmX
Sep 21 2017 18:16 UTC
We are not using cluster, but only Akka.Remote
I'll set up a Gist tomorrow
Thank you for your help :)
Aaron Stannard
@Aaronontheweb
Sep 21 2017 18:19 UTC
no problem, please post that Gist when you get the chance
Phil Sandler
@philsandler_twitter
Sep 21 2017 20:31 UTC
If I use a consistentHashingPool, how does the system decide which work to give to which actor in the pool? Is it more or less a round robin?
Michel van den Berg
@promontis
Sep 21 2017 20:54 UTC
@Horusiath I've created a repository for the issue (cluster sharding not being restarted after the second time) I'm having: https://github.com/promontis/stylister.sample I know you are busy, but hopefully you can have a quick look at the issue I'm having :) The repo contains a readme with the steps (and some pictures).
Augustine Gyawu Adjei
@austinejei
Sep 21 2017 22:57 UTC
@Aaronontheweb thanks. it's fine now.
Anders Storhaug
@andersstorhaug
Sep 21 2017 23:37 UTC
using PersistenceQuery for a SQL projection, any suggestions on how to persist checkpoints? I'm currently batching via .GroupedWithin(100, TimeSpan.Seconds(1)), applying the batch of events to an in-memory model, and then transactionally writing to the DB along with a checkpoint sequence. Issue there though is that this doesn't play well with the SqlServer journal & its internal PersistenceQuery batching. Not sure if playing with group batch size will help here
in my case having a lag of 1s for eventual consistency is acceptable, but seems that this kind of batching (that I'm doing, not journal) is not optimal for replays specifically, otherwise this works fine enough for "live" streams