Keep it up and we won't have to hire ya, Aaron! :P
@Aaronontheweb@skotzko great meetup guys
@Aaronontheweb :+1: it's awesome work! Thanks! =)
Does anyone have any guidelines or steps in getting akka.net working remotely in terms of getting messages from a machine or VM to another machine or VM. I have been able to get this working locally, using 127.0.0.1 or localhost with a specified port. But I have had no luck in finding any material on how to set up the access from one machine to another. I have a Azure Windows 2012 VM, where I have one akka.net service running. But I have had no luck in establishing the communication to it from my client akka.net service. Has anyone had any joy in getting something like this working, what gotchas should I be aware of that might help? :worried:
@ianbarry are you using cloudservices or just vanilla VM's?
If you haven't already, open firewall port in the VM and also in the portal you need to configure the private/public endpoints.
It varies depending on your setup though. e.g. you may not need to expose public endpoints if you're communicating between two VMs on the same VNET.
@jberzy thanks for your reply. It's a standalone cloud service. I've gone so far as turning off the firewall to check if I can gain connection. I have been able to access websites running on the VM over the internet, but not my akka.net process.
@ianbarry Did you map the endpoints? If you go in the portal under the VM configuration you'll find a section where you can specify the public-private endpoint config.
this is separate from the VM firewall configuration.
Ah finally some sort of breakthrough, thanks @jberzy . I had been looking at configuring the endpoints in the portal. I changed the http port 80 to the akka.net port it is listening on. and this worked. Worked in that, it certainly received something, but on the listener, it throw an error with "Dropping message [Akka.Actor.ActorSelection] for non-local-recipient". But this is fine, this is due to the server not being able to communicate back to a publicly available IP (which is the client).
grafana looks nice, but looks like it has some of the same problems that cactus does.. the numerical information is not presented well, and while the graphs are prettier than cactus it's still kind of generic.
@annymsMthd thanks! it was good seeing you guys, thanks for coming to the meetup
@rodrigovidal@trbngr@shersh thanks guys, glad you liked it!
@Mystere Hystrix looks interesting. Right now we support StatsD, as @Horusiath mentioned
@ianbarry would it be helpful if @skotzko and I put together some DevOps videos for that sort of issue?
we've been getting asked about that sort of stuff from a lot of folks who've just started using Akka.Remote / Akka.Cluster
@Aaronontheweb That would be awesome if you could do that. I felt the barrier to entry on getting started with akka.net was really low and the petabridge bootcamp has greatly helped with that. And then I came across remote and clustering between machines as being a bit more of a barrier, when getting down and dirty and trying to apply it to what I needed, with any examples pointing at localhost on the same machine. Thanks! :smile:
@ianbarry yeah, I know what you mean. The DevOps overhead for any applications that depend on sockets rather than HTTP goes up considerably
I had to learn a lot of that stuff the hard way and it really sucked