These are chat archives for akkadotnet/

Feb 2017
Caleb Vear
Feb 06 2017 05:02

I've been trying to figure out where the best place to do some initialisation is. PreStart seems like the logical place, but I'm having a little trouble finding in the docs how exceptions there are handled. My actor is managing an external connection which may fail if for some reason the remote host is unavailable.

It seems like trying to connect inside of the message handler might be better as then my actor will automatically be restarted.

I'm pretty new to so I'm not quite sure what the best option is. If I go with doing it in a message handler is it considered acceptable practice for me to publish a message to Self from the PreStart method?
Bartosz Sypytkowski
Feb 06 2017 06:01
@caleb-vear yes, you can send messages to Self in PreStart without problems ;)
Jakub Čermák
Feb 06 2017 08:30
@Aaronontheweb yes, exactly; it's not working for me. Binary is present on both side, mailbox is registered on both sides as well
Ricky Blankenaufulland
Feb 06 2017 12:31
I would like to have an actor which "debounces" messages if he got them multiple times. Lets say the mailbox has a "refresh-message", an "info1-message" and a "refresh-message". Upon working on the first refresh message I would like to recognize that there is already a later "refresh message" so I will skip it. Or more low level, when a second "refresh-message" is enqued, the earlier one is dropped from the queue.
Will I have to write my own custom mailbox to do this?
Arjen Smits
Feb 06 2017 14:48
@ZoolWay I would be very careful in implementing a mailbox with that kind of behavior. Because what happens if you use that actor in reliable message delivery scenario's ?
Or what happens if you utilize stashing and unstash a whole bunch of messages ?
I would handle this on the actor level.
Maybe you treat the refresh-message as an indication for intent, instead of actually performing the refresh action
you could do something like schedule a message to perform refresh in X amount of time, upon receiving the refresh-message. And invalidate that timer upon certain events.
Like a sliding-expiration-timer mechanism you see in caching
just a thought.
Aaron Stannard
Feb 06 2017 15:29
@jakubcermak would you mind creating an issue for that? looks like we're probably leaving that information out of the Deploy data that gets serialized and sent over the wire
Aaron Stannard
Feb 06 2017 15:48
@ismaelhamed not at the moment - that uses a construct in the JVM called the Java Management Experience
allows you to remotely access information about any Java Virtual Machine process
the CLR doesn't have anything like that built-in
Rich Cox
Feb 06 2017 16:44
It looks like there has been quite a bit of work recently on Akka.IO, Is it possible to do TLS on socket connections now?
Aaron Stannard
Feb 06 2017 16:46
not on Akka.IO
but on Akka.Remote, yes
Rich Cox
Feb 06 2017 16:48
Well, that's 1/2 way to good news!
Rich Cox
Feb 06 2017 16:55
I'm going to have a client actor systems deployed on machines I don't trust, I'm not sure I'd want them to be connected via Akka.Remote to my actor system running as the server.
Is there an example to look at for TLS on akka.remote?
Bartosz Sypytkowski
Feb 06 2017 18:16
@conejo it's not released yet, but it'll boil down to setting correct password and certificate path under HOCON config