These are chat archives for akkadotnet/akka.net

7th
Dec 2018
Peter Huang
@ptjhuang
Dec 07 2018 13:22
Would this be of any interest to anyone for akka.net contrib? https://doc.akka.io/docs/akka/2.5.9/actor-discovery-typed.html
Maciek Misztal
@mmisztal1980
Dec 07 2018 16:17
Hey guys, can anyone tell me how many fallbacks does the config support? I've just tried to assemble my config from a parsed Config + 2 fallbacks, when the ActorSystem was created, It didn't contain all of the configs I've chained via the .WithFallback
Jorge Candeias
@JorgeCandeias
Dec 07 2018 19:19
I’m not aware of limits, but on one project we have about eight fallbacks and they work fine. The one occasion where they weren’t working and I was scratching my head was because of a hard to spot typo in the hocon text.
Mike Bridge
@mikebridge
Dec 07 2018 19:20
I have a WebApi app that is running in an Azure App Service and I was about to try to get it to communicate back and forth with a remote actor system running on a VM. However, I don't think I can open up a port on the App Service that the remote actor system can communicate with. If I understand correctly, attaching to a vnet will only give my WebApi app access to the things in the VNet, but not vice-versa. Do I need to move the webapp to an App Service Environment or is there a better way of accomplishing this?
Shukhrat Nekbaev
@snekbaev
Dec 07 2018 22:15
heh, similar question to @mikebridge. I've been using remoting on Azure with WebApps (not ASE) since the end of September. Occasionally messages were not received back from the VM, but VM always got them. In general, WebApp restart seemed to be the way to address it. Recently it's been happening more frequently. Not sure if it has anything to do with an upgrade to 4.7.2 and/or latest Akka+dependencies. I do use VNET. When I start WebApps first and then the windows service on the VM - everything is fine. It can last for days. Basically it seems to pair webapp -> VM and keeps it like that. However, when I restart the WebApp I see "connection was reset by peer" on the VM and then when WebApp is started and the message is sent then I see the debug text in the VM's service: attempt to associate WebApp -> VM, which seems to pass, then it receives the message, processes it and tries to reply. And this fails because at this moment VM's service tries to pair back to the WebApp and I get a warning that remote is not accessible and it is gated etc. etc. What's interesting is that it doesn't happen in the happy path start-up order, but does if WebApp is restarted (at least). BTW, happy path works well in the scale-out scenario too. Is there a way to configure VM's service to not try to pair back on connection resets? :) I understand that's against the peer-to-peer nature of Akka where both endpoints should be reachable... However, ASE is not an option and given that it already works half-way... maybe there's some tweak? :) Or is this trully the case (as per docs) for a custom low-level Akka I/O approach? @Horusiath, @Aaronontheweb what do you guys think?
Mike Bridge
@mikebridge
Dec 07 2018 22:26
@mikebridge In my particular case my webapp's communication with the remote actorsystem is only ever one-way. My best guess is that a better solution is to get rid of Akka.Net in WebApi and rewrite the remote actor system as a Rest API that uses Akka.Net internally. ASE looks like overkill for this system, and redeploying in a VM isn't difficult but seems like a hassle just to open a port in WebApi that isn't receiving any messages anyway. (It would be too bad, because the remote actor works great in all my internal deployment scenarios.)
Peter Huang
@ptjhuang
Dec 07 2018 22:54
If we want to implement Akka.Monitoring AND establish tenant/user context AND do some authorisation checks based on message header, what's a good way to do it without multiple inheritance and traits, and with much of these infrastructural needs requiring access to lifecycle overrides of the Actor. I'm thinking of a ReceiveActor derived class (e.g. AspectReceiveActor) that provides extension points to an ordered list of "aspects" to be executed AroundXYZ. The aspect list is populated by the derived class of AspectReceiveActor in its constructor. Any other better ideas?
Shukhrat Nekbaev
@snekbaev
Dec 07 2018 22:54
@mikebridge the reason I used VNET pairing - wanted all Akka traffic to be completely internal. Yes, it costs ~23 EUR, but not nearly as much as ASE :)
(and yeah, the port part too)