but either way, this is the flaky test report for
ClusterSpec.A_cluster_must_complete_LeaveAsync_task_upon_being_removed
that information you just mentioned is very helpful. Confirms for me that this is a bug.
that under some circumstances, the
MemberRemoved event is not received or processed correctly
if you have some logs from that situation you described, that would be helpful
so back trying to debug why distributedpubsub isn't working for me. basically after some time period publish just stops working. I enabled DEBUG logging and for a while I see 'Received Akk.Cluster.GossipStatus' messages, and then it just stops after some time, and that's when publish stops working also
so it looks like possibly some bad logic in pruning. If I bump up pub-sub.removed-time-to-live the issue seems to go away. So what I was seeing is that pubsub worked until I unsubscribed from a topic, and that seemed to start a countdown where at the end, I couldn't publish to any topic. It's like the topic just isn't there anymore.
but you also can't resub to it either, it's like when it gets pruned it's then in a bad state where it's just not functional at all anymore
can take a look at the pruning logic and see what's up there
but outlining the steps you took to produce the error and the behavior you've observed would be valuable to capture
so you should, in theory, be able to do step-through debugging, but yeah
that's kind of an impractical way to do it given that step-through won't hit
all of the concurrent and async stuff
happening in the background over the network
anyways I'll file ticket a bit later, this has been haunting me for a while
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.
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?
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?
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
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)
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?
What advantages would this give you if any?
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.
What you are asking is doable, but separate machine is cleaner I guess.
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?
It would appear that I have a really bad production memory leak :worried: I have just started to dig and using the memory profiler it appears that it is the EF and data objects are not getting disposed. The normal use that the service I am using was originally designed is for our websites. I guess I could kill that actor off and recreate it but not sure I understand if that actor would get a new kernel or context and does everything go dispose correctly. I'm using DI to inject the service and tried a couple different scopes with the same result. Just not sure what the issue is really yet but wanted ask if any has had any similar issues. Should the data context be disposed or can it live forever?
So far I'm not seeing anything that stands out. Perhaps I'm actually doing a mutable object somewhere. I don't know. Will continue tomorrow. Thanks for any advice!
So far I'm not seeing anything that stands out. Perhaps I'm actually doing a mutable object somewhere. I don't know. Will continue tomorrow. Thanks for any advice!
@ckarcz I am using team city and I have it so I can deploy my services which is a member of the cluster to the same or different machine based on the configuration. Changing service name and port. Has worked out well for having 3 Dev environments on the same system and then push it to QA and prod. Then the same for our websites. Each member does have a specific role.
@mwpro regarding your yesterday question about Hyperion serializer: could you tell me please, where your problem actually lies? From what I see, all of those are standard issues of people overusing schema changes. Maybe it should be written more explicitly but Hyperion version tolerance is limited to adding new fields to existing schema and changing field names if their position and type (or to be more explicit binary representation of the value) doesn't change