Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 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
  • Feb 19 20:57
    Aaronontheweb edited #4212
  • Feb 19 20:57
    Aaronontheweb edited #4212
  • Feb 19 20:57
    Aaronontheweb synchronize #4212
  • Feb 19 20:23
    Aaronontheweb edited #4212
  • Feb 19 20:23
    Aaronontheweb synchronize #4212
  • Feb 19 20:18
    Aaronontheweb edited #4212
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)
Yin Zhang
@melcloud
Hi guys, do we have documents on how split brain problem is handled in akka.net? There is a good amounts of articles for akka, not sure if akka.net uses the same mechanism
Arjen Smits
@Danthar
yes it does
generally the jvm akka docs apply to akka.net as well
Bartosz Sypytkowski
@Horusiath
@melcloud I don't remember if custom downing provider are already present in the akka.net version available on nuget, or it's still laying down in dev branch
anyway by default no downing strategy is provided. You can change that to auto-down (which means that every node will automatically mark as downed other nodes it couldn't reach within specified timeout) - but this may lead to split brain situation.
On the akka jvm you have at least 4 more downing providers, but they are part of reactive subscription and are part of Lightbend's proprietary stack
Yin Zhang
@melcloud
@Horusiath ah, got it. Yes, those 4 downing providers are what I am looking for. This means in akka.net, we need to keep monitoring status to manually downing actor?
Matthew Little
@zone117x
Hey guys curious of akka.net is good for my use case. I have an asp.net core server brokering messages between clients on net451 using websockets and msgpack serialization
the net451 client apps are 1) data collector, and 2) remote controller for the data collector and data viewer
Yin Zhang
@melcloud
@zone117x so what would you like to use akka.net for ?
Matthew Little
@zone117x
I'm having to write a lot of code to manage the websocket connection and especially message routing
Yin Zhang
@melcloud
I see. Does the .ne tcore server doing any thing special?
Matthew Little
@zone117x
its using asp.net core mvc for the web interface and some REST apis, and routing for the websocket connections