These are chat archives for akkadotnet/akka.net

30th
Nov 2017
Augustine Gyawu Adjei
@austinejei
Nov 30 2017 10:50
hello guys
what's the best way to send back large dataset from a remote actor system?
been playing with "send-buffer-size" and "receive-buffer-size"
what's the best practice here?
Paladin
@DeepChipolino_twitter
Nov 30 2017 12:51
Guys, do you have plans to update Cassandra journal to support the latest version of Cassandra in Akka.net ?
jalchr
@jalchr
Nov 30 2017 12:59
I need your recommendation about the following:
A service is processing large number of files. Each file is varying in size, so its processing time varies.
Each file name is persisted, before being actually processed.
Sometimes, the processing service gets restarted, and thus persistence recovering takes place.
Here is the issue:
I'm getting duplicates due to recovered messages and messages read by the watch folder. Adding to this multi-nodes in a cluster and things become strange.
Yes I'm using Entities and Singletons.
Question: What is the best way to avoid message duplication and tracking its state without going to my own persistence implementation ?
cyril andreichuk
@andreichuk
Nov 30 2017 13:20
@austinejei split a large dataset into smaller chunks and send them one by one
Jack Wild
@jackowild
Nov 30 2017 14:45
Hello, hoping for some guidance on an intermittent problem my team are having with Akka.Remote since upgrading from 1.0.8 to 1.3.2.
So we have actor system A initiating a remote connection to actor system B via actor selection. When we restart actor system A, most of the time it reconnects to actor system B with no problems.
However, sometimes we get an ActorNotFoundException in system A. We've written some retry logic so that it tries again every minute but we still get the ActorNotFoundException. To fix this, we have to restart actor system A.
Meanwhile over in actor system B, every time the restarted actor system A attempts to connect there are 2 log messages:
[11/30/2017 2:59:53 AM +00:00] [Warning] "AssociationError [akka.tcp://TestSystem@test:8097] -> akka.tcp://TestSystem@127.0.0.1:50661: Error [Association failed with akka.tcp://TestSystem@127.0.0.1:50661] []"
Followed by:
[11/30/2017 2:59:53 AM +00:00] [Warning] Tried to associate with unreachable remote address ["akka.tcp://TestSystem@127.0.0.1:50661"]. Address is now gated for 5000 ms, all messages to this address will be delivered to dead letters. Reason: ["Association failed with akka.tcp://TestSystem@127.0.0.1:50661"] "Caused by: [System.AggregateException: One or more errors occurred. ---> Akka.Remote.Transport.InvalidAssociationException: No connection could be made because the target machine actively refused it tcp://TestSystem@127.0.0.1:50661 at Akka.Remote.Transport.DotNetty.TcpTransport.<AssociateInternal>d__1.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Akka.Remote.Transport.DotNetty.DotNettyTransport.<Associate>d__22.MoveNext() --- End of inner exception stack trace --- at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions) at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification) at System.Threading.Tasks.Task`1.get_Result() at Akka.Remote.Transport.ProtocolStateActor.<>c.<InitializeFSM>b__11_54(Task`1 result) at System.Threading.Tasks.ContinuationResultTaskFromResultTask`2.InnerInvoke() at System.Threading.Tasks.Task.Execute() ---> (Inner Exception #0) Akka.Remote.Transport.InvalidAssociationException: No connection could be made because the target machine actively refused it tcp://TestSystem@127.0.0.1:50661 at Akka.Remote.Transport.DotNetty.TcpTransport.<AssociateInternal>d__1.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Akka.Remote.Transport.DotNetty.DotNettyTransport.<Associate>d__22.MoveNext()<--- ]"
As I said above, the only way to fix this is to restart actor system A. Anyone have any ideas how to fix this or is it a bug?
Carlos Torrecillas
@CarlosTorrecillas
Nov 30 2017 16:50
Hi guys, I'm getting an error when serializing an object and I would like to change the serializer of it. As I'm using a Pub/Sub, do I need to change the serializer for a Publish object or would it be for the object itself? I've tried the object itself but according to the stacktrace it looks like Hyperion is still used as opposed to the one that I configured ( JSON)
Stefano
@delfuria
Nov 30 2017 17:17
Json is deprecated as serializer
Carlos Torrecillas
@CarlosTorrecillas
Nov 30 2017 17:17
@jackowild if it is of any help I had that disconnection problem a few days ago with entities on a remote cluster and the problem was that the entity that was down had an exception that was unhandled that made the service to go down and got removed from the cluster. Then the other component couldn't communicate with it. Check if you have any unhandled code, catching awaits with timeouts, ContinueWith with cancelled/faulted tasks etc
@delfuria ok that's fine. Is Hyperion the one to use then?
Stefano
@delfuria
Nov 30 2017 17:53
Yes with hyperion I haven't no problem is fast and reliable
Aaron Stannard
@Aaronontheweb
Nov 30 2017 17:54
@jackowild any info on what the disassociation is happening?
serialization error?
restart?
etc
@CarlosTorrecillas could you post more information about the error message?
and your serialization configuration?
Jack Wild
@jackowild
Nov 30 2017 17:59
@Aaronontheweb it's when i restart the actor system that initiates the remote connection
Jack Wild
@jackowild
Nov 30 2017 18:04
it's actually a web api which gets recycled automatically at 3am every day
a couple of times a week we have this problem
Bartosz Sypytkowski
@Horusiath
Nov 30 2017 22:14
@object Quartz is pretty beefy. Akka.Persistence.Reminders is simple - it uses existing Akka.Persistence for durability and offers 4 options:
  • Scheduling message to be send to the provided path at fixed point in time (UTC date time)
  • Optionally add interval for repeatition of that message resend.
  • Cancel scheduled task (message send).
  • Read the current state - overall info about all scheduled requests that are waiting to be executed in the future
also I've already defined protobuf format for reminder state and events, so it's safe in this aspect too.