These are chat archives for akkadotnet/akka.net

1st
Feb 2017
Chris G. Stevens
@cgstevens
Feb 01 2017 02:20
Question. I have multiple members that do work and have a common status to report back to a managing dashboard that is is also a member part of the cluster using the Cluster.Tools with PubSub. That is simple with an Interface and Publish to my Topic. My problem is I have details that are unique now for each worker. What is a good approach? Before I was sending just a object with simple common stats but now my classes that have those extra properties outside of the interface are null. Before I go down any rabbit holes I figure I would ask. Thank you so much in advanced.
Chris G. Stevens
@cgstevens
Feb 01 2017 03:20
Can you have an immutable object that has a dynamic property? Hmm
Chris Karcz
@ckarcz
Feb 01 2017 04:54
Hi guys. I have a question. I have some legacy code I'd like to run in a distributed manner (cluster). I'd like to deploy a small service (w/ Actor) that creates its own supervised cluster that it distributes work to (group). I'd like to be able to create these child actors in their own AppDomains. The legacy code is not threadsafe and so I'd like to host these child actors in their own app domain. What's the best way to go about this? I'd like to have one main process that spawns these children (deploying remote actors in their own app domain would be great features too
My thoughts being I deploy one instance of the service (a group router), and its either configured to spawn x children in their own appdomain on startup (or like i mentioned above, it starts up and these children are remotely deployed from else where, in their own app domains). Is there a way to hook into remote/router child creation to take over the creation in oder to initialize child in separate appdomain?
Maciej Wódke
@mwpro
Feb 01 2017 08:47

Hi everyone! I'm struggling with extending class for already persisted messages. I added new field, new messages are serializing propeply but when I try to recover my actor I receive

Persistence failure when replaying events for persistenceId [someId]. Last known sequence number [8]", "timestamp": "2017-01-31 09:30:05.9723", "stack": "System.InvalidCastException: Okre\u015blone rzutowanie jest nieprawid\u0142owe.\r\n   w lambda_method(Closure , Stream , DeserializerSession )\r\n   w Hyperion.ValueSerializers.ObjectSerializer.ReadValue(Stream stream, DeserializerSession session)\r\n   w Hyperion.Serializer.Deserialize[T](Stream stream)\r\n   w Akka.Serialization.HyperionSerializer.FromBinary(Byte[] bytes, Type type)\r\n   w Akka.Persistence.Sql.Common.Journal.AbstractQueryExecutor.ReadEvent(DbDataReader reader)\r\n   w Akka.Persistence.Sql.Common.Journal.AbstractQueryExecutor.<SelectByPersistenceIdAsync>d__44.MoveNext()\r\n--- Koniec \u015bladu stosu z poprzedniej lokalizacji, w kt\u00f3rej wyst\u0105pi\u0142 wyj\u0105tek ---\r\n   w System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   w System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   w Akka.Persistence.Sql.Common.Journal.SqlJournal.<ReplayMessagesAsync>d__32.MoveNext()" }

According to Hyperion's documentation, it's version tolerant, so as far as I understand this therm, it means I should be able to add/remove field to the contract. I created simple project https://github.com/mwpro/Hyperion-VerionTolerance that reproduces my issues. Can you guys look at it please and tell me if I am doing something wrong or if there is some king of bug with version tolerance?

Bartosz Sypytkowski
@Horusiath
Feb 01 2017 09:12
@mwpro using default serializer for persistence is generally a bad idea (Hyperion was created for remoting in mind)
until it gets to 1.0, binary encoding may change anyway
I'll take a look at it later, it may be a sign of a bug in the implementation
Maciej Wódke
@mwpro
Feb 01 2017 09:55
@Horusiath thanks for reply. So I should switch my app to another serializer like ProtoBuf or MS Bond (as suggested in Hyperion docs) to avoid versioning problems. From your experience, is any of them is ready for production use with Akka.Persistence?
Bartosz Sypytkowski
@Horusiath
Feb 01 2017 09:58
yes, I'd consider protobuf and ms bond a pretty mature options - I'm a fan of having well-defined schema files, as they make your data contracts explicit, so you can version them in explicit way too. But tbh you need to test yourself. Maybe simple json serializer will be enough for you.
also remember, that serialization sometimes depends on persistent provider you're going to use (i.e. MongoDB uses custom bson-based, Postrgres can be configured to use jsonb column type)
Alex Michel
@amichel
Feb 01 2017 10:26
@ckarcz Why would you bother with appdomain and not just run separate processes? You will need remoting anyway, so it will be transparent with Akka to have them in different cluster nodes on same or separate machines.
Alex Michel
@amichel
Feb 01 2017 10:31
@cgstevens will sending collections work for you? send lists of key/value tuples if you want to work loosely typed.
if you want strongly typed messaging, consider encapsulation
Nick Cuthbert
@ncthbrt
Feb 01 2017 11:18
I was watching this NDC video, and the presenter was running 5 identical nodes of an actor systems on a single machine: https://vimeo.com/189191045
What advantages would this give you if any?
Chris G. Stevens
@cgstevens
Feb 01 2017 12:59
Thanks @amichel I think the KeyValue will work just fine for what I need and I think I have a plan.
Jose Carlos Marquez
@oeaoaueaa
Feb 01 2017 12:59
@ncthbrt maybe queuing and concurrency control?
Chris Karcz
@ckarcz
Feb 01 2017 18:04
For my question- My thinking is that the parent actor can have children and monitor them as akka normally supports, the only difference being them running in a separate app domains. If one app domain crashes or runs out of memory (remember this is old legacy code) it would not affect the others and the parent would hopefully be able to restart a new child in a new app domain and retry. It'd also be easy to spawn child actors from configuration/message/code instead of deploying more instances of a service/package to the same machine, which when using a CD tool (octopus/xldelploy) is not straightforward.
Maxim Cherednik
@maxcherednik
Feb 01 2017 19:14
To deploy an extra node is not that complicated with octopus.
What you are asking is doable, but separate machine is cleaner I guess.
wingedmachine
@wingedmachine
Feb 01 2017 21:19
I have an actor I'm stopping, and afterwards it doesn't respond to messages (as expected), but it also doesn't send a Terminated message to a watching actor, and if I try to make a new actor with the same name, I get an exception because the name isn't unique. Does anyone know what could be causing that?
wingedmachine
@wingedmachine
Feb 01 2017 21:36
Oh, nevermind. One of the actor's children had while(true) going on, and wasn't checking it's messages