Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 20 14:10
    dependabot-preview[bot] synchronize #4337
  • Oct 20 14:10

    dependabot-preview[bot] on nuget

    Bump FSharp.Quotations.Evaluato… (compare)

  • Oct 20 14:10
    dependabot-preview[bot] edited #4337
  • Oct 20 14:09
    dependabot-preview[bot] edited #4337
  • Oct 20 14:08

    dependabot-preview[bot] on dev

    Bump FSharp.Core from 4.7.2 to … (compare)

  • Oct 20 14:08

    dependabot-preview[bot] on nuget

    (compare)

  • Oct 20 14:08
    dependabot-preview[bot] closed #4586
  • Oct 20 14:08
    Aaronontheweb commented #4586
  • Oct 20 14:08
    Aaronontheweb closed #4585
  • Oct 20 14:08
    Aaronontheweb commented #4585
  • Oct 20 06:57
    alexvaut commented #4496
  • Oct 20 05:50

    dependabot-preview[bot] on nuget

    Bump FSharp.Core from 4.7.2 to … (compare)

  • Oct 20 05:50
    dependabot-preview[bot] labeled #4586
  • Oct 20 05:50
    dependabot-preview[bot] opened #4586
  • Oct 20 05:43

    dependabot-preview[bot] on nuget

    (compare)

  • Oct 20 05:43
    dependabot-preview[bot] closed #153
  • Oct 20 05:43
    dependabot-preview[bot] commented #153
  • Oct 20 05:43
    dependabot-preview[bot] labeled #154
  • Oct 20 05:43
    dependabot-preview[bot] opened #154
  • Oct 20 05:43

    dependabot-preview[bot] on nuget

    Bump Mongo2Go from 2.2.12 to 2.… (compare)

Bartosz Sypytkowski
@Horusiath
@maxcherednik this phrase about autodowning is more valid in case if you have alternatives (i.e. on JVM side you can buy subscription with better solutions for that issue ;) )
Maxim Cherednik
@maxcherednik
What about remote death watch? It seems it's also not working when node is unreachable. It needs to be down.
Bartosz Sypytkowski
@Horusiath
but unless you clusters grow big, this can work fairly well
Maxim Cherednik
@maxcherednik
I see.
So it's the way to go until we really face a split brain:-)
Bartosz Sypytkowski
@Horusiath
if I were you I'd just set auto downing (otherwise implement custom split brain resolver, but it's not out of the box)
Maxim Cherednik
@maxcherednik
Ok, thanks. Could you please confirm the remote death watch behavior?
Again my expectation would be: I receive Terminated event in case of network issue.
Is this correct?
Bartosz Sypytkowski
@Horusiath
@maxcherednik I wouldn't count on it (Unreachable is treated as sort of temporal undefined state, so in most of the cases this state change is undecisive to perform any actions), but you can check it easily if you have some cluster already spinning up. /cc @Aaronontheweb
Maxim Cherednik
@maxcherednik
@Horusiath I did actually... but as far as I remember I had it working before.
and I am also reading this: http://getakka.net/docs/remoting/deathwatch
This section: When Will You Receive a Terminated Message?
As far as I remember, I was receiving Terminated message right away...
Maxim Cherednik
@maxcherednik
I start to remember something. It seems I already asked exactly the same question and the answer was: Remote and Cluster watch works slightly different and there is no documentation for this. @Aaronontheweb
Ricky Blankenaufulland
@ZoolWay
@Silv3rcircl3 Hm, that would work. In the Task.ContinueWith handler I can dispose stream and materializer without problem. I will have to manually send my stream completed message there too which Sink.ActorRef() has done for me before. Also, it does not send Akka.Actor.Status.Failure on failures, they are just silently ignored as far as I can see. So that approach does not seem suitable.
There must be some kind of after completion callback for Sinks I guess
Vagif Abilov
@object
Good morning. Question on persistent actors. Persistent actor will alway get RecoveryCompleted message upon the restoration of its state. What if the state restoration is slow and persistent actor receives other messages while its state is being built? Does actor system guarantee that other messages will be played after the actor state is recovered or the actor needs to stash such messages if they expect correct state?
Arjen Smits
@Danthar
By default, a persistent actor is automatically recovered on start and on restart by replaying journaled messages. New messages sent to a persistent actor during recovery do not interfere with replayed messages. They are cached and received by a persistent actor after recovery phase completes.
Vagif Abilov
@object
Thank you @Danthar
Vagif Abilov
@object
I wonder if others experienced problems caused by persistent actors snapshots. We are using MS SQL Server adapter for persistent actors and often see Akka.Persistence.RecoveryTimedOutException with message "Recovery timed out, didn't get snapshot within 30s." They occur no matter if an actor has snapshots. Even if we clean all snapshots for all actors.
We also see Circuit Breaker exceptions from akka.persistence.journal.sql-server ("Circuit Breaker is open; calls are failing fast"). They often come right after the application start.
tstojecki
@tstojecki
@object really nice talk on akka streams at ndc oslo.... did you publish the sample code anywhere?
Vagif Abilov
@object
Thank you @tstojecki, you can grab sample code here: https://dl.dropboxusercontent.com/u/8734289/ReactiveTweets-NDC.zip
tstojecki
@tstojecki
thanks!
Kosta Petan
@kostapetan
Hey guys, anyone can help me with setting up akka remoting under docker?
basically I have a docker-compose file defining an API service , seed node (worker) and regular node (worker), but so far no success in connecting the nodes between each other
Jalal EL-SHAER
@jalchr
@object Yes I tried persistent actors few days ago and experienced the same issues you got.
Kosta Petan
@kostapetan
my remote config looks like this
        remote {
            log-remote-lifecycle-events = INFO
            log-received-messages = on

            dot-netty.tcp {
              transport-class = "Akka.Remote.Transport.DotNetty.TcpTransport, Akka.Remote"
                  applied-adapters = []
                  transport-protocol = tcp
              #will be populated with a dynamic host-name at runtime if left uncommented
              #public-hostname = "127.0.0.1"
              hostname = 0.0.0.0
              port = 4053
              maximum-frame-size = 256000b
            }
        }
then, via environment variables, I'm overwriting the ports
Vagif Abilov
@object
@jalchr we've been using persistent actors for quite some time with some of these issues coming and going, but recently we revised our code to create more persistent actors simultaneously, and it looks like such errors occur much more frequently now.
Maxim Cherednik
@maxcherednik
@kostapetan but what exactly doesn't work?
Jalal EL-SHAER
@jalchr

@object

I'm trying to use Akka.Persistence with in-memory snapshot for the AtLeastOnceDeliveryReceiveActor. If everything is left with defaults, it works. The actor "stops" receiving any message, if I use the following serialization in my HOCON:

              serializers {
                wire = "Akka.Serialization.WireSerializer, Akka.Serialization.Wire"
              }
              serialization-bindings {
                "System.Object" = wire
              }

I also tried Hyperion, same issue. If I remove this configuration, it works .
Is this a bug or misconfiguration ?
Okay, I just noticed this #2743

Kosta Petan
@kostapetan
@maxcherednik I have basically two services, an API and a worker which acts as the seed node as well
Maxim Cherednik
@maxcherednik
I did it once some time ago, and was following this article: https://mukis.de/pages/akka-cluster-with-docker-containers/
there was something tricky with the ips
Kosta Petan
@kostapetan
exactly, the seed node IP seems unreachable, even though if I exec inside the container, from there I can successfully "netcat" it
Maxim Cherednik
@maxcherednik
unfortunately that setup is gone. But anyhow the article helped.
Kosta Petan
@kostapetan
yeah, probably I need to play with the network configuration a bit, I've gone through the reference configuration for remoting, couldn't figure out what I'm doing wrong
Vagif Abilov
@object
@jalchr we are using similar serialization settings but our snapshots are in the database. It mostly works but often raises exceptions like I posted above.
Arsene
@Tochemey
Hello geeks, can someone pls show a tutorial on how I can use actors to implement the Sagas pattern because I see it very relevant for the actor model.
Carlos Torrecillas
@CarlosTorrecillas

Hi guys, quick question I'm not sure about. I have a distributed akka cluster up and running and I can see the lighthouse registering all the nodes. I have successfully published messages to all subscribers for a topic however I'm not able to do an Ask with a publish message. Is it possible to achieve that? I can see the mediator has the Ask method available. The code I use to perform the ask is the following:

`var mediator = DistributedPubSub.Get(Context.System).Mediator;

        var publishMessage = new Publish("my-topic, new Message());

        Logger.Debug($"{Context.Self.Path.Name} publishing request");

        var response = await mediator.Ask<MyResponseMessage>(publishMessage);

        Context.Sender.Tell(response, Self);`
Bartosz Sypytkowski
@Horusiath
@object what is your data volume? It may be that sqlserver persistence is serving db requests too slow? In that case batching journal should help (see the code here: akkadotnet/Akka.Persistence.SqlServer#56 )
(unfortunatelly I'm going on vacation and it may be that we hit v1.3 before I finish akka.persistence rework)
Vagif Abilov
@object
Could be, but it sounds strange if it doesn't manage to restore the state within 30 seconds. In the db I am testing it it's 1M+ event journal records and very few snapshots.
Bartosz Sypytkowski
@Horusiath
I guess, that in your case events and snapshots both share the same ADO.NET pool of connections
Vagif Abilov
@object
But we found that we were running latest released NuGet packages (from October 2016!), we changed now to use build from latest sour.ce
Thanks for the reference to batching.
Bartosz Sypytkowski
@Horusiath
if you're building from source, you may as well try to build batching journal ;) It has some extra configuration options, but in terms of persistence format it's drop-in replacement of existing journal (also if you need base class for batching journal, it's here: https://github.com/akkadotnet/akka.net/blob/cd33195b5aad34895f0fb69893bd2074d539201f/src/contrib/persistence/Akka.Persistence.Sql.Common/Journal/BatchingSqlJournal.cs )