Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 06:42
    dependabot-preview[bot] labeled #4237
  • 06:42
    dependabot-preview[bot] opened #4237
  • 06:42

    dependabot-preview[bot] on nuget

    Bump Microsoft.Data.SQLite from… (compare)

  • 06:41

    dependabot-preview[bot] on nuget

    Bump LightningDB from 0.10.0 to… (compare)

  • 06:41
    dependabot-preview[bot] labeled #4236
  • 06:41
    dependabot-preview[bot] opened #4236
  • 00:28
    Aaronontheweb labeled #4235
  • 00:28
    Aaronontheweb labeled #4235
  • 00:28
    Aaronontheweb milestoned #4235
  • 00:28
    Aaronontheweb commented #4235
  • 00:27
    Aaronontheweb commented #4212
  • 00:26
    Aaronontheweb edited #4212
  • 00:26
    Aaronontheweb synchronize #4212
  • Feb 19 22:57
    nagytech commented #4235
  • Feb 19 22:57
    nagytech opened #4235
  • Feb 19 21:46
    Aaronontheweb edited #4212
  • Feb 19 21:46
    Aaronontheweb edited #4212
  • Feb 19 21:46
    Aaronontheweb edited #4212
  • Feb 19 21:46
    Aaronontheweb synchronize #4212
  • Feb 19 21:46
    Aaronontheweb edited #4212
Arjen Smits
@Danthar
@garrardkitchen ask can only return one response. But im not sure how it would react, i would expect it to return as soon as the first response is received.
But if you want behavior like that, it sounds like you would be better of with an scatter gather router: http://getakka.net/docs/working-with-actors/Routers
Alex Michel
@amichel
Anyone worked with Akka.Persistence.Redis ?
Garrard Kitchen
@garrardkitchen
Thank you @Danthar
Alex Michel
@amichel
WIth Cluster Sharding if I don't care about state of actor, but only about serializing all messages to my entities, I don't have to make it a persistent actor. It is enough that Shard will be serialized and persisted along with its messages buffer and relevant actor refs, right?
Bartosz Sypytkowski
@Horusiath
@amichel yes
keep in mind that message buffer is not persisted. Messages will be redirected when graceful shutdown will occur, but in case of hard crash messages are lost
@conejo akka io doesn't use tcp client, it operates on raw sockets. This is an implementation detail thou - in near future it will work over AsyncSocketEventArgs
Arsene
@Tochemey
Hello Geeks
Alex Michel
@amichel
@Horusiath Is there a way to persist message buffer, or better just use RabbitMQ and subscribe to it from Akka if I want be able to consume requests published when node or whole cluster was down?
Arjen Smits
@Danthar
@amichel you could certainly use RabbitMQ as an front facing message buffer for your cluster. However depending on your use case, you might very well be moving the problem elsewhere, instead of fixing it.
Alex Michel
@amichel
@Danthar I understand. Just trying to figure out how to solve it. With pure RabbitMQ implementation, durable queues and router/exchange of my choice I don't have this problem when consuming it from several instances, but then I need to handle the logic of moving shards and rebalancing when one of instances fails. With Akka I don't have durability. Should I implement durable message buffer with RabbitMQ?
Bartosz Sypytkowski
@Horusiath
@amichel common pattern is to set a persistent queue in front of the cluster. Most of the time what you want to persist are user requests or some important domain requests, but usually there's not sense in persisting every message passed between two actors
Alex Michel
@amichel
@Horusiath it means I can't use cluster proxy in frontend, but run cluster in backend with actors consuming persistent queue?
Bartosz Sypytkowski
@Horusiath
@amichel when using persistent queue at frontend, then yes. But it really depends on what you need:
  • you could potentially use AtLeastOnceDelivery with Akka.Persistence module (I've created a sample of such persistent gateway some time ago), but this comes with performance drop and potentially the same message being emitted more than once.
  • For immediate user requests you can also simply use request/response pattern with message timeouts - so if you have cluster proxy in frontend, simply send request to target actor and expect response within specified timeout. If response won't arrive (cluster node has crashed or message has been lost for any other reason), consider request as unfulfilled.
Alex Michel
@amichel
@Horusiath Thanks a lot. I will stick with proxy and the request/response solution
Alex Achinfiev
@aachinfiev

I am trying to use Become in PersistentReceiveActor to switch from Uninitialized to Initialized state but I get an error:
[Akka.Actor.OneForOneStrategy]: You may only call Recover-methods when constructing the actor and inside Become().
In my actor I have:

Become(Uninitialized);
private void Uninitialized()
{
        Recover<SecurityCreated>(e => Create(e));
        Command<CreateSecurity>(c => ...);
}

This used to work in the PersistentActor before. How should Become be declared now? Is there an updated example? Or if I use anonymous action inside Become call, how do I switch to it from other parts of the code? Thanks.

Alex Achinfiev
@aachinfiev
@aachinfiev Update:
So it looks like I just need to move all Recover methods back to ctor and leave commands in corresponding Initialized/Uninitialized actions that are switched using Become.
Aaron Stannard
@Aaronontheweb
oh I see
yeah it's not being able to mix and match Recover and Command inside the same behavior
Recover only gets used during the actor's initial recovery phase
those should be called from the CTOR, like you said
the commands behave like normal receives
you can behavior-switch those
Alex Achinfiev
@aachinfiev
Yes. I understand it better now :)
@Aaronontheweb Btw. Are there any plans to bring Akka.Persistence.Cassandra to work with latest 1.0.2 Akka.Persistence? I saw you update on one of the PRs but that was a while ago.
Aaron Stannard
@Aaronontheweb
yep, we're working on it
have an evil plan underway to get all of the Akka.Persistence implementations running with full integration testing again
which is what we've been waiting on
Alex Achinfiev
@aachinfiev
Is part of that update to change schema to support reverse lookup views by tags?
Aaron Stannard
@Aaronontheweb
yeah should be as part of Akka.Persistence.Query
which that PR supports
Alex Achinfiev
@aachinfiev
Cool
Aaron Stannard
@Aaronontheweb
the damn thing that's taken so long is getting our toolchain to play nice with Docker
spin up a Docker container for whatever database target we're testing against
allows for a bunch of fun stuff like being able to test against multiple versions of the same database simultaneously
Alex Achinfiev
@aachinfiev
Yeah, I have been building a docker stack for our various data stores (cassandra, elasticsearch, orientdb) to spin that up locally for testing. Works great with docker-compose, and then you can destroy the whole thing and start fresh quickly.
Aaron Stannard
@Aaronontheweb
I tried getting DataStax Enterprise to run inside Docker two weeks ago
failed miserably at that
too many issues with file system permissions inside the container
whereas it "just works" on a Ubuntu VM
I felt very un-hip :(
Alex Achinfiev
@aachinfiev
I currently didn't bother mounting the volumes because for local testing I don't want them to live for long. As long as I don't destroy container I can stop/start with the data. But if I do compose down then it starts fresh. Very handy.
Right now trying to figure out how to tweak our coordinator that manages persistent actors to kill them efficiently and without loosing messages. Current implementation keeps taking longer and longer during sustained load when I push thousands of messages through it. If I let coordinator kill the child immediately it keeps constant level of response time but looses in-flight messages.
Alex Achinfiev
@aachinfiev
@Aaronontheweb Have you guys tried to run Akka stack on Docker yet?
Bartosz Sypytkowski
@Horusiath
@aachinfiev Afaik @annymsMthd has a production system working on akka/mono/docker - he even published some docker scripts some time ago
Alex Achinfiev
@aachinfiev
@Horusiath Cool. Good to now. Thanks.
Eric Glanz
@ericgla
I'm new to Akka.Net, and am testing out scenarios where a child actor stops using the OneForOneStrategy I defined. Everything is working as expected, but I never seem to get a Terminated message on the parent when the child actor stops.
Looking at the Actor lifecycle diagram in the docs, I should be seeing a Terminated message at the parent. What am I missing here?
Eric Glanz
@ericgla
and just after posting I answered my own question.... child actors are not watched by default (which was my assumption), and need to be explicitly watched with Context.Watch(childActor)