Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 03:08
    hhko commented #4094
  • Dec 13 21:37
    Aaronontheweb commented #4085
  • Dec 13 20:28
    IgorFedchenko commented #4085
  • Dec 13 20:27
    IgorFedchenko commented #4085
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb milestoned #4096
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb opened #4096
  • Dec 13 10:41
    peirens-bart opened #4095
  • Dec 13 08:37
    Aaronontheweb synchronize #4071
  • Dec 13 08:13
    jiyeongj opened #4094
  • Dec 12 15:42
    Aaronontheweb synchronize #4086
  • Dec 12 15:42
    Aaronontheweb closed #4083
  • Dec 12 15:42

    Aaronontheweb on dev

    Fix #4083 - Endpoint receive bu… (compare)

  • Dec 12 15:42
    Aaronontheweb closed #4089
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb opened #4093
  • Dec 12 14:20
    Aaronontheweb commented #4092
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
that exception is what's doing it
I have it on my to-do list to review some of the inocuous remoting exceptions and prevent them from being logged
in this case the reason why you're seeing two instances of the exception
one is for the client currently connected to another node
the other is for the socket that is used to accept inbound connections
Peter Bergman
@peter-bannerflow
Nice, I wa actually scratching my head over that one as well
Aaron Stannard
@Aaronontheweb
yeah, it's annoying
the exception gets thrown on that Socket.Receive call