Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 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
  • Feb 20 23:14
    Aaronontheweb commented #4234
Rahul Singh
@xingh
anyone know of a good reference application that leverages akka (scala) and akka.net on dotnetcore .. with or without an intermediary queue engine like rabbitmq
Aaron Stannard
@Aaronontheweb
@jakubcermak yep, you can do both
but the priority mailbox works only for specific actors
but it sounds like remote deployment with a custom mailbox is not working? am I correct in understanding that?
if so, could you please open up a Github issue for that? should be easy for us to test if that's the case
might be an issue with the fully qualified name of the mailbox not being passed through correctly
also: the binary that defines the custom mailbox is present on both the deployer and the deployee , right?
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)