Character actor being a child actor of the actor that's supposed to do the work
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(...)
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
( http://getakka.net/docs/working-with-actors/stopping-actors elaborates on the methods )
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.
need to be 100% sure that no more messages are handled
And by the way, do you know how subsequent messages to an IActorRef of the dead actor will be handled? Deadletters?
since they are letters and the actor is dead ;)
@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.
@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.
in looking at @ZoolWay issue, it appears we are seeing some similar behavior
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:
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...
@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...
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