Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 02:22
    kimbyungeun opened #4098
  • Dec 15 19:47

    Aaronontheweb on dev

    TypeExtensions.TypeQualifiedNam… (compare)

  • Dec 15 19:47
    Aaronontheweb closed #4071
  • Dec 15 19:47
    Aaronontheweb closed #3767
  • Dec 15 19:47
    Aaronontheweb labeled #3767
  • Dec 15 19:47
    Aaronontheweb labeled #3767
  • Dec 15 19:47
    Aaronontheweb milestoned #3767
  • Dec 15 19:44
    Aaronontheweb labeled #4097
  • Dec 15 19:44
    Aaronontheweb milestoned #4097
  • Dec 15 13:23
    Aaronontheweb commented #4096
  • Dec 15 13:22
    Aaronontheweb commented #4093
  • Dec 15 13:16
    ismaelhamed commented #4093
  • Dec 15 13:04
    ismaelhamed edited #4097
  • Dec 15 13:04
    ismaelhamed opened #4097
  • Dec 15 12:50
    ismaelhamed commented #4096
  • Dec 15 12:48
    ismaelhamed commented #4096
  • Dec 15 12:05
    Aaronontheweb commented #4096
  • Dec 15 11:43
    ismaelhamed commented #4096
  • Dec 14 19:13
    hwanders commented #4096
  • Dec 14 13:05
    IgorFedchenko commented #4085
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
which is basically what's going to be run asynchronously by the SocketAsyncEventArgs object we're using
we could probably handle that up the stack better
so in effect
the fact that we have these inocuous errors
is a user-experience issue on our part
Aaron Stannard
@Aaronontheweb
makes the user think they did something wrong
when they didn't
Peter Bergman
@peter-bannerflow
Yeah
Aaron Stannard
@Aaronontheweb
We might release 1.1.1 today
depends on if I can get one more hostname / binding bug fixed
fixed IPV6 support already
have one more issue with public-hostname that needs to be resolved
Peter Bergman
@peter-bannerflow

Here goes a kind of an open question... Does anyone have some insights to share on Akka.Cluster perfomance in terms of throughput of messages from the network into the actor system. For example, what kind of throughput can we expect to one single actor (running on one machine) that receives messages from other remote nodes in the cluster? Of course it depends on what that actor actually do with the messages as well as hardware specs and such but any insights would be appreciated. Real world experience anyone? For example, can we expect 10k messages/second or 100k messages/second. I have seen this article https://petabridge.com/blog/performance-testing-mandatory/ and from that I gather that around 10k messages/second is reasonable?

Also, does anyone have some insight in OS (Windows Server) level tweaks that could be made in order to increase the message throughput into the actor system from the network?

Aaron Stannard
@Aaronontheweb
check out the benchmarks on each pull request
green check mark next to perf-tests
that will take you to a folder chock full of them