These are chat archives for akkadotnet/akka.net

29th
Dec 2016
to11mtm
@to11mtm
Dec 29 2016 02:51
@simonpetty Shoot, I'm fairly certain someone here will give it a go. Posting a Question on StackOverflow is also a way to try, contribs and other folks look there, and that way the knowledge is retained in a better format (it's frustrating to go through pages of history to find an old answer in my experience)
oh... scrolling blocked some of that.
to11mtm
@to11mtm
Dec 29 2016 02:56
@Horusiath can probably explain that one better than I.
to11mtm
@to11mtm
Dec 29 2016 03:56

@mclark1129 In our teams experience, it's usually a little of both. Some of our microservices are ATM little more than the old class logic exposed in actors, others we've started to optimize the pipeline and use more actors throughout.

That said, we typically use separate application instances for the microservices; Separate instances make it a bit easier to deploy changes to just that microservice, makes it a little easier to reason about scaling up/out later. Also, you don't have as much communication i/o competing in said service.

The biggest tradeoff we consider in that (whether to bundle parts inside one microservice versus others) is locality; If two actors are in the same local VM, things move much faster than even two different running apps on the same machine. So if there are two microservices that are doing a lot of communication between them, we consider whether it makes sense to bundle them up. We also know that's not the most technically correct, but perhaps most pragmatic.

to11mtm
@to11mtm
Dec 29 2016 04:10

As a general example, We have a service for refreshing data across two different Databases into a single target DB. Must run FAST (Design Goal was to refresh status data for up to 20k inventory units a minute across 1000 customers and provide aggregate data. I'm aware this wasn't the right way to do so much of this, yay brownfield engineering with a shotgun deadline.)

Side A has Actors for: 1.dispatching requests per customer, 2.'internal data collectors', 3. 'external request buffers' for talking to side B, 4. 'Collection Writers', 5. 'Calculators', and 6. 'Result writers'

Side B has 1. 'External Data collector' and 2.'External result buffers' for sending the result back to Side A.
There's a WebAPI on each end of that, there's business/technical/contractual reasons why we won't communicate between sides using Akka instead of HTTP.

One of the really cool things about designing that process was tuning how many of each of those actors were present throughout. Make a more of the actors that have to do the heavier lifting (db Queries). Less of the ones that just do simple things in memory.

Vagif Abilov
@object
Dec 29 2016 10:10
For those familiar with persistence queries, I appreciate an answer to this question: http://stackoverflow.com/questions/41377449/how-to-retrieve-all-journal-events-using-akka-persistence-queries
Arsene T. Gandote
@Tochemey
Dec 29 2016 10:36
Hello Geeks is the Akka.Cluster.Metrics already implemented?
Maxim Cherednik
@maxcherednik
Dec 29 2016 11:49

@Aaronontheweb Hey Aaron. Some time ago, once Akka.Cluster became more stable, I was trying to setup a really tiny cluster. The one I created was really simple - no logic inside, only the clustering check itself: normal node leaving, network issue, hard node restart and so on. The cluster logic seems to be fine, but there was one annoying thing I can stand - wrong or incorrect logging. So when the node was gracefully leaving there was an exception like this:
2016-12-29 11:57:57.950 [20] [(null)] ERROR Akka.Actor.OneForOneStrategy - Shut down address: akka.tcp://riskengine@127.0.0.1:4054
Akka.Remote.ShutDownAssociation: Shut down address: akka.tcp://riskengine@127.0.0.1:4054 ---> Akka.Remote.Transport.InvalidAssociationException: The remote system terminated the association because it is shutting down.
--- End of inner exception stack trace ---
at Akka.Remote.EndpointWriter.PublishAndThrow(Exception reason, LogLevel level)
at Akka.Remote.EndpointWriter.<SupervisorStrategy>b__20_0(Exception ex)
at Akka.Actor.SupervisorStrategy.HandleFailure(ActorCell actorCell, IActorRef child, Exception cause, ChildRestartStats stats, IReadOnlyCollection`1 children)
at Akka.Actor.ActorCell.HandleFailed(Failed f)
at Akka.Actor.ActorCell.SysMsgInvokeAll(EarliestFirstSystemMessageList messages, Int32 currentState)
--- End of stack trace from previous location where exception was thrown ---
at Akka.Actor.ActorCell.HandleFailed(Failed f)
at Akka.Actor.ActorCell.SysMsgInvokeAll(EarliestFirstSystemMessageList messages, Int32 currentState)
That time you advised: eh, just aks your devops to filter this out.
Why would we see an exception on a healthy system? I dug a bit into the sources and this is what I found:

protected override SupervisorStrategy SupervisorStrategy()
        {
            return new OneForOneStrategy(ex =>
            {
                //we're going to throw an exception anyway
                PublishAndThrow(ex, LogLevel.ErrorLevel);
                return Directive.Escalate;
            });
        }

private void PublishAndThrow(Exception reason, LogLevel level)
        {
            reason.Match()
                .With<EndpointDisassociatedException>(endpoint => PublishDisassociated())
                .With<ShutDownAssociation>(shutdown => {}) // don't log an error for planned shutdowns
                .Default(msg => PublishError(reason, level));

            throw reason;
        }

This is in the EndpointWriter class. Why do we need to throw an exception anyway here? Inside PublishAndThrow we can clearly distinguish the ShutDownAssociation exception.

Pavel Knorr
@knorrus
Dec 29 2016 14:29

@question Hi everyone! Akka serialization docs says that I need to use wire for all messages in my actor system

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

http://getakka.net/docs/Serialization

"System.Object" = wire
In the same time I have Akka.Cluster in place
and akka cluster has own serializer for IClusterMessage, will wire override that?
Mike Clark
@mclark1129
Dec 29 2016 18:03
@to11mtm Thanks for the insight!
Michael Dadashyan
@mebymyself
Dec 29 2016 20:02

Hello, I have question about Akka Persistence. I have specified in my config:

akka.persistence{
  journal {
    plugin = "akka.persistence.journal.sql-server"
    sql-server {
        class = "Akka.Persistence.SqlServer.Journal.SqlServerJournal, Akka.Persistence.SqlServer"
        auto-initialize = on
        schema-name = dbo
        connection-string-name = "MyConnection"
        table-name = EventJournal
        metadata-table-name = Metadata
    }

    snapshot-store {
              plugin = "akka.persistence.snapshot-store.sql-server"
                sql-server {
                  class = "Akka.Persistence.SqlServer.Snapshot.SqlServerSnapshotStore, Akka.Persistence.SqlServer"
                  plugin-dispatcher = "akka.actor.default-dispatcher"
                  table-name = SnapshotStore
                  schema-name = dbo
                  auto-initialize = on
                  connection-string-name = "MyConnection"
                }
            }
 }

But the Snapshot table is not being created.
I am not getting errors when saving snapshot tho...
Do I miss anything?

Chris Ochs
@gamemachine
Dec 29 2016 20:33
So I was trying to find out how to manually down a node, where is that info? Or does akka.net not support that?