Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 10:12
    cptjazz synchronize #4242
  • Feb 22 12:02
    cptjazz opened #4242
  • Feb 21 19:37
    Arkatufus synchronize #4228
  • Feb 21 19:37
    Arkatufus ready_for_review #4228
  • Feb 21 15:42
    Aaronontheweb assigned #4241
  • Feb 21 15:42
    Aaronontheweb milestoned #4241
  • Feb 21 15:42
    Aaronontheweb labeled #4241
  • Feb 21 15:42
    Aaronontheweb labeled #4241
  • Feb 21 15:42
    Aaronontheweb labeled #4241
  • Feb 21 15:42
    Aaronontheweb opened #4241
  • Feb 21 01:47
    Arkatufus opened #4240
  • Feb 21 00:10
    Aaronontheweb synchronize #4212
  • Feb 20 23:50
    Aaronontheweb synchronize #4238
  • Feb 20 23:48
    Aaronontheweb commented #4234
  • Feb 20 23:47
    Aaronontheweb synchronize #4212
  • Feb 20 23:46

    Aaronontheweb on dev

    close #4234 - added CachingConf… (compare)

  • Feb 20 23:46
    Aaronontheweb closed #4239
  • Feb 20 23:46
    Aaronontheweb closed #4234
  • Feb 20 23:25
    Aaronontheweb synchronize #4239
  • Feb 20 23:24
    Aaronontheweb opened #4239
Aaron Stannard
@Aaronontheweb
and the mailbox is registered with the same name on both the deployer and deployee's HOCON too?
Ismael Hamed
@ismaelhamed
Is there anything like the Command Line Management available to manage a cluster in Akka.NET?
stevemesser
@stevemesser
U
Arsene
@Tochemey
@nvivo Tx
Thomas Tomanek
@thomastomanek
does anyone know what magic causes the ActorCellKeepingSynchronizationContext to be used by a TestActorRef'd actor but not by a regular LocalActorRef? As far as I can tell the sync context is applied in the testkit as the global SynchronizationContext always
Bartosz Sypytkowski
@Horusiath
@thomastomanek I'm not sure if I remember correctly, but it may be that testkit actor system runs executing everything in a single thread rather than on the thread pool
Thomas Tomanek
@thomastomanek
@Horusiath hey, yeah that's it I think. TestActorRef's use callingthreadispatcher by default.
@Horusiath unfortunately breaks any ReceiveAsync on that thread
Bartosz Sypytkowski
@Horusiath
can you setup an issue on that?
Thomas Tomanek
@thomastomanek
#2491 :)
Bartosz Sypytkowski
@Horusiath
:)
Caleb Vear
@caleb-vear

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 Akka.net 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
@Horusiath
@caleb-vear yes, you can send messages to Self in PreStart without problems ;)
Jakub Čermák
@jakubcermak
@Aaronontheweb yes, exactly; it's not working for me. Binary is present on both side, mailbox is registered on both sides as well
thanks
Ricky Blankenaufulland
@ZoolWay
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
@Danthar
@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
@Aaronontheweb
@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
@Aaronontheweb
@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
@conejo
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
@Aaronontheweb
not on Akka.IO
but on Akka.Remote, yes
Rich Cox
@conejo
Well, that's 1/2 way to good news!
Rich Cox
@conejo
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
@Horusiath
@conejo it's not released yet, but it'll boil down to setting correct password and certificate path under HOCON config
Andy Maesen
@arxae
Hello, i have 2 quick questions. 1. Which of the actors is preffered? (ReceiveActor or TypedActor) and 2. Is it better to keep a globally accessible reference to an actor, or use the ActorSelection method?
Bartosz Sypytkowski
@Horusiath
@arxae
  1. Use ReceiveActor. TypedActors are inefficient, very limiting and should be removed.
  2. IActorRef gives more power and it's faster. But once actor gets stopped, it's no longer valid - for good or bad, depending on your use case.
Maxim Cherednik
@maxcherednik
@Horusiath ReceiveActor slow as well ?
and what do you mean: it should be removed?
Bartosz Sypytkowski
@Horusiath
I meant TypedActors ;)
Caleb Vear
@caleb-vear
@Horusiath cool, thanks for the clarification.
Maxim Cherednik
@maxcherednik
so this one is ok: public abstract class ReceiveActor : UntypedActor, IInitializableActor ?
seems like Untyped:)
Bartosz Sypytkowski
@Horusiath
UntypedActor is ok, TypedActor is bad (as you cannot build state machines and it relies heavily on reflection)
last time I've checked, TypedActor was on average 10x slower than UntypedActor
Maxim Cherednik
@maxcherednik
Yeah - i ve seen this before. Was just a bit surprised about 'Use ReceiveActor. TypedActors are inefficient,'
Ricky Blankenaufulland
@ZoolWay
@Danthar Thanks for your input. Yes, I am a bit worried about implementing such a stuff on mailbox level and I guess there are many things which will can be done wrong. But also I could not come up with a proper flow how to handle it by the actor itself.
Now that you point again in that direction I think maybe I could have two stages of messages. The first one, plan-a-refresh, will set a flag on the actor. If another plan-a-refresh message occurs while that flag is true, it will be ignored. The first message but will not also set the flag but self-tell a do-a-refresh message. That one will be at the end of the actor mailbox queue and all already queued plan-a-refresh messages will be ignored due to that flag. The do-a-refresh message will when do it and reset the flag.
I am doing this because there are external events which will cause like 50 to 100 actors to notify this one actor to do a refresh and it would be nice to do the refresh after the last message or at least not as often as that number.
Arjen Smits
@Danthar
@ZoolWay maybe using the ReceiveTimeout feature would be enough ?
If your actor receives alot of messages throughout. You could also forward the refresh messages to a seperate actor. That utilizes the receive timeout functionality to detect when a surge of refresh messages has ended.
and have it send the actual refresh command
Ricky Blankenaufulland
@ZoolWay
Oh, I think that's a great idea!