Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 07:55
    ismaelhamed commented #3284
  • Sep 13 16:35
    Aaronontheweb commented #3905
  • Sep 13 16:35
    Aaronontheweb labeled #3905
  • Sep 13 16:35
    Aaronontheweb labeled #3905
  • Sep 13 16:35
    Aaronontheweb labeled #3914
  • Sep 13 16:34
    Aaronontheweb commented #3914
  • Sep 13 01:50
    Aaronontheweb synchronize #3914
  • Sep 13 01:45
    Aaronontheweb commented #3914
  • Sep 12 14:10
    Aaronontheweb synchronize #3914
  • Sep 12 14:10

    Aaronontheweb on dev

    name AzureDevops artifacts per … (compare)

  • Sep 12 14:10
    Aaronontheweb closed #3915
  • Sep 12 13:57
    Aaronontheweb synchronize #3915
  • Sep 12 13:37
    Aaronontheweb opened #3915
  • Sep 12 06:43
    Horusiath commented #3628
  • Sep 12 05:57
    Horusiath synchronize #3628
  • Sep 12 02:05
    Aaronontheweb synchronize #3901
  • Sep 12 02:04
    Aaronontheweb commented #3914
  • Sep 12 02:03
    Aaronontheweb synchronize #3914
  • Sep 12 01:11
    Aaronontheweb commented #3105
  • Sep 12 01:10
    Aaronontheweb closed #3105
wdspider
@wdspider
@peter-bannerflow I believe the default values are the values listed in the related config file. In the specific case of akka.remote.log-buffer-size-exceeding, the value 50000 is listed here https://github.com/akkadotnet/akka.net/blob/4acfa7c363bfa83ac71849a5a8487c8d6b1bbcb1/src/core/Akka.Remote/Configuration/Remote.conf#L146
Peter Bergman
@peter-bannerflow
@wdspider Ah, ok cool, thx. Do you know the internals of that buffer? Does it buffer messages before they are sent over the network?
wdspider
@wdspider
not really, pretty new to things myself. Just happened to have stumbled across the config files while looking at some of the source :)
Peter Bergman
@peter-bannerflow
Hehe ok, I see
Arsene T. Gandote
@Tochemey
Hi Gentlemen is there a way to check the existence of an Actor?
to11mtm
@to11mtm
@Tochemey you can send the actor an Identify message. You should get an ActorIdentity back if it exists : http://getakka.net/docs/Working%20with%20actors
Aaron Stannard
@Aaronontheweb
@ZoolWay that gist 404s
might have created it as private
Jordan S. Jones
@jordansjones
@Aaronontheweb Github is currently experiencing issues
wdspider
@wdspider
Is there an example of how to add a version path to your actor hierarchy so the path looks something like /user/v1/MyRootActorPool ? Or do you have to create an actual v1 actor that then has the MyRootActorPool as a child?
Curtis Swartzentruber
@skills0
We have an interesting usage of cluster with our app: 2 Windows services running in active/passive mode for failover. Both are configured as seed nodes. In some environments we can fail over back and forth no problem. In others we get "Leader can currently not perform its duties" when one node goes down and the up node goes into a association error loop. We were seeing this before 1.1 as well and hoped it would be fixed. 1.1 did improve the association issues when the down node comes back up. That is working much better. Any ideas what is causing this? We could have something misconfigured.
Arsene T. Gandote
@Tochemey
Can I please an example of exception handling with Actors? I have read we can handle exception in the supervisor. However I want to handle some exception in the actor due to external web service calls.
Bart de Boer
@boekabart
try/catch in the Receive handler is just fine
Arsene T. Gandote
@Tochemey
@boekabart Thank you. I thought as much but I needed a recommende way.
Bart de Boer
@boekabart
but the more typical way of working would be to use a Character Actor (thay may die) to do the dangerous work
Character actor being a child actor of the actor that's supposed to do the work
Arsene T. Gandote
@Tochemey
Hello I know that an Actor handle one and only one message at a time. Let us assume that we want to handle multiple instances of the same message concurrently. Can someone tell me the recommended and best approach to this problem?
Bart de Boer
@boekabart
broadcast it to N actors. Doesn't even have to be different instances, in fact.
If you mean 'multiple instances of the same message class', the typical way is to create N instances of your handler actor with a router Props.Create<HandlingActorClass>().WithRouter(...)
Arsene T. Gandote
@Tochemey
@boekabart Thank you. I have used another approach that is to create another instance of the same actor since I m dealing with Http request. And I want to use the request handler actor to handle each request that comes. I believe it is a good approach.
Another challenge I am facing is the Fault tolerance. I could not see any reliable article on it. Even the one on the site lacks code snippets http://getakka.net/docs/Fault%20tolerance
Peter Bergman
@peter-bannerflow
If I have a bunch of actors that are supposed to be quite short lived (100 ms max) and they have control over their own lifecycle (i.e each actor knows when its no longer needed), is it then good practice for the actor to somehow "shut down" itself?
Malisa Ncube
@malisancube
C f
Bart de Boer
@boekabart
@peter-bannerflow as far as I know, yes, it should just commit suicide (eg. Self.Tell(PoisonPill.Instance); )
Arsene T. Gandote
@Tochemey

Hello I would like to know when I have this in my App.Config file

akka {  
    stdout-loglevel = DEBUG
    loglevel = DEBUG
    log-config-on-start = on        
    actor {                
        debug {  
              receive = on 
              autoreceive = on
              lifecycle = on
              event-stream = on
              unhandled = on
        }
    }

Do I need to call _log.Debug("Some message"); in my Actors? Or Akka take cares of that for me.

Peter Bergman
@peter-bannerflow
@boekabart Thanks for the info. I think that in my case I want to go with Stop() since the dying actor might have a large unprocessed mailbox that I no longer care about.
Bart de Boer
@boekabart
Context.Stop(Self) is what I use in exactly such a case
need to be 100% sure that no more messages are handled
Peter Bergman
@peter-bannerflow
Yes, exactly. Thanks :)
And by the way, do you know how subsequent messages to an IActorRef of the dead actor will be handled? Deadletters?
Bart de Boer
@boekabart
Can't imagine anything other that that, indeed
since they are letters and the actor is dead ;)
Peter Bergman
@peter-bannerflow
Yeah, pretty obvious I guess... :P
Arsene T. Gandote
@Tochemey
Also I would like to know whether it is necessary to provide a ToString method for my message POCO in case I want to log them or I can use the Seriliazation feature to do that. The best will be that Akka takes care of that. Any idea gentlemen?
Bart de Boer
@boekabart
well that depends on the verbosity you want. using serialization will produce very verbose (large) logs vs using optimized ToString per PoCo. We prefer the latter.
Bartosz Sypytkowski
@Horusiath
@Tochemey if you'll use serialization to log the content of a message, you're introducing quite a big footprint for such a simple step
Bart de Boer
@boekabart
Might be worth it only for exceptional cases (eg. errors that really aren't supposed to happen)
Ricky Blankenaufulland
@ZoolWay
@Aaronontheweb Sorry, there has a bracket splipped into the URL. Should be https://gist.github.com/ZoolWay/8092e7c2aa3a86b009981885cd4aa271 - but it is basically the same as the code in the GitHub repository which shows Cluster.Leave for three types. Interestingly the shown method for ASP.NET Core does not work in a larger project of mine, still checking on that. But the gist shows the exceptions and deadletters in its comments, though.
Ricky Blankenaufulland
@ZoolWay
@Aaronontheweb Here is another gist https://gist.github.com/ZoolWay/2af4eb1815c6a5c41cdeb440dd0cd36b which is in my opinion the same leave-code like in the GitHub example but the node does not leave the cluster. Instead the other nodes continue to try to reconnect every 5s. The gist shows the ASP.NET Startup.cs and the output the node generates itself when trying to leave the cluster.
Curtis Swartzentruber
@skills0
still would like some thoughts on my "Leader can currently not perform its duties" issue. should I open a bug with details?
in looking at @ZoolWay issue, it appears we are seeing some similar behavior
Ricky Blankenaufulland
@ZoolWay
@skills0 The leaving issue with ASP.NET Core?
Ricky Blankenaufulland
@ZoolWay
I got a rather basic question about how to define the message receive handlers. In http://getakka.net/docs/working-with-actors/sending-messages#ask-send-and-receive-future we have this hint: When using task callbacks inside actors, you need to carefully avoid closing over the containing actor’s reference, i.e. do not call methods or access mutable state on the enclosing actor from within the callback. This would break the actor encapsulation and may introduce synchronization bugs and race conditions because the callback will be scheduled concurrently to the enclosing actor.
Is this violated when I define the handler like this: Receive<SubscribeToDeadLetters>((message) => ReceivedSubscribe(message));? Because calling a method just feels like making the code more readable (and stacktraces too) but if it endangers my actor system...
Curtis Swartzentruber
@skills0
no, i'm actually seeing a similar issue in standard C# where a node doesn't leave a 2 node cluster properly and the other node keeps trying to connect to it. not exactly the same, but some similar errors to your gist.
Peter Bergman
@peter-bannerflow
@ZoolWay I would assume that the issue with synchronization only applies to cases where you fire off a task (as with the Ask example) and the callback is being executed sometime in the future. I use the same structure as you do in my Receive handlers. But perhaps someone else can confirm this...
Marc Piechura
@marcpiechura
@ZoolWay @peter-bannerflow yep that's right
Ricky Blankenaufulland
@ZoolWay
Good to know, thanks! @Silv3rcircl3 @peter-bannerflow
Jared Lobberecht
@Jared314
Is there a form of the Akka.Tools.MatchHandler.MatchBuilder.Match that accepts a MethodInfo object?