Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 10:13
    nagytech commented #3954
  • 05:29
    nagytech commented #4090
  • 05:29
    nagytech opened #4090
  • Dec 11 23:52
    scptre commented #4082
  • Dec 11 14:26
    nagytech commented #3954
  • Dec 11 11:18
    nagytech edited #4089
  • Dec 11 11:17
    nagytech opened #4089
  • Dec 11 11:00
    nagytech commented #4083
  • Dec 11 08:34
    jiyeongj commented #4083
  • Dec 11 08:33
    jiyeongj commented #4083
  • Dec 11 08:33
    jiyeongj commented #4083
  • Dec 11 07:57

    dependabot-preview[bot] on nuget

    (compare)

  • Dec 11 07:57

    dependabot-preview[bot] on dev

    Bump MongoDB.Driver from 2.9.1 … (compare)

  • Dec 11 07:57
    dependabot-preview[bot] closed #104
  • Dec 11 07:52
    dependabot-preview[bot] synchronize #104
  • Dec 11 07:52

    dependabot-preview[bot] on nuget

    Bump MongoDB.Driver from 2.9.1 … (compare)

  • Dec 11 07:52
    dependabot-preview[bot] edited #104
  • Dec 11 07:51
    dependabot-preview[bot] edited #104
  • Dec 11 07:51
    dependabot-preview[bot] edited #104
  • Dec 11 07:51
    Aaronontheweb commented #104
Bart de Boer
@boekabart
Character actor being a child actor of the actor that's supposed to do the work
Arsene
@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
@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
@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
@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?
Aaron Stannard
@Aaronontheweb
@skills0 in a 2-node cluster unless both nodes have the other node listed as a seed node, you are going to run into that
that's on you, in other words
if one node is a seed and the other isn't
when the seed node restarts
it knows it's a seed
and will join itself and form its own cluster if there are no other seeds listed
so you'll end up with a split brain
Akka.Cluster is not magic - it uses the same dynamo-style clustering system that Cassandra, Riak, DynamoDb, and others use
all of those systems require minimum seed node count >= 2
@ZoolWay I did disable Helios's logging system inside Akka.Remote so I'm a bit surprised this shows up
ERROR 13:55:24 [ 3] ios.TcpClientHandler - Error caught channel [[::ffff:127.0.0.1]:12301->[::ffff:127.0.0.1]:4053](Id=ChannelId(1600056064))
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.Sockets.Socket'.
   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, SocketError& errorCode)
   at Helios.Channels.Sockets.TcpSocketChannel.DoReadBytes(IByteBuf buf)
   at Helios.Channels.Sockets.AbstractSocketByteChannel.SocketByteChannelUnsafe.FinishRead(SocketChannelAsyncOperation operation)
ERROR 13:55:24 [ 3] ios.TcpServerHandler - Error caught channel [[::ffff:127.0.0.1]:12300->[::ffff:127.0.0.1]:12311](Id=ChannelId(-18529280))
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.Sockets.Socket'.
   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, SocketError& errorCode)
   at Helios.Channels.Sockets.TcpSocketChannel.DoReadBytes(IByteBuf buf)
   at Helios.Channels.Sockets.AbstractSocketByteChannel.SocketByteChannelUnsafe.FinishRead(SocketChannelAsyncOperation operation)
that exception is nothing to worry about
happens in Helios and in DotNetty whenever a socket is closed, even gracefully
Aaron Stannard
@Aaronontheweb
the SocketAsyncEventArgs object that those libraries use to asynchronously read / write from the socket is always waiting in a read state
when we close the socket, we have to interrupt the pending async read operation in order to complete shutdown