Aaronontheweb

Background and Motivation

I cross-posted some of my motivation for this proposal here in the OpenTelemetry repository:

https://github.com/open-telemetry/opentelemetry-dotnet/issues/684#issuecomment-634376910

Motiviation: not all application context can be propagated or consumed the same way. In the world of capturing this through OpenTracing we had the ability to create custom IScopeManager and IScope objects - this allowed applications like mine (actor-based) to manage scope using actor-static variables, rather than AsyncLocal which wouldn't work in our case.

Proposed API

I'd suggest adding something akin to an IScopeManager from OpenTracing to help resolve this - call it the IActivityScope and IActivityScopeManager. I'd pair the IScopeManager with a specific ActivitySource so it doesn't change the scope of all created Activity objects globally.

Aaronontheweb

HOCON 3.0 Specification

In the previous releases of HOCON, we let the OSS project do its own thing without any plan for integrating it into Akka.NET and replacing the stand-alone HOCON engine built into the Akka.Configuration.Config class. This was a mistake and led to us having to drop stand-alone HOCON integration as part of the Akka.NET v1.4.1 milestone.

Motivation for Moving to Stand-alone HOCON

Why bother moving from Akka.Configuration.Config? Isn't it good enough as is? Why support an entire configuration library?

The motivations for separating HOCON from Akka.NET are the following:

1. Akka.NET is a massive library with 5,000+ tests that have to be run on at least 3 runtimes whenever a change is made to the core Akka package, which is where Akka.Configuration.Config is housed. If we want to innovate around configuration, it's very expensive for us to do this without separating the libraries into their own projects.
2. There has been a lot of innovation around configuration since the rel

Aaronontheweb

Building Your First Whiskey Collection

I got really into Scotch when I turned 30 years old and took a father-son trip through England and Scotland. Since then it's been one of my favorite hobbies and I've built a great collection over the past few years that I enjoy sharing with my friends and family.

A lot of the people in my circle have expressed interest in learning whiskey and how to build their own collection - so I put this together as a short guide to help explain how to build a tasty, diverse, and affordable "Starter Whiskey Collection." Enjoy!

A Beginner's Palette

Tasting whiskey or any hard liquor can be a challenge at first, because the alcohol flavor overwhelms the sugars, esters, and other residues from the fermentation and aging process. We want to be able to taste the stuff in the latter category without being perturbed by the former.

This guide is designed to help steer readers towards whiskeys that are easy to drink: ones with a naturally sweet or slightly berry flavor. As you start

Aaronontheweb

akka {
          loggers = ["Akka.Logger.Serilog.SerilogLogger, Akka.Logger.Serilog"]
          stdout-loglevel = DEBUG
          loglevel = DEBUG
          log-config-on-start = off
          suppress-json-serializer-warning = on
          
          actor {
            #serialize-messages = on
            provider = "Akka.Cluster.ClusterActorRefProvider,Akka.Cluster" # turns Akka.Cluster on

Aaronontheweb

Original ActorPath Benchmark Values

BenchmarkDotNet=v0.12.0, OS=Windows 10.0.18362
Intel Core i7-3630QM CPU 2.40GHz (Ivy Bridge), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=3.0.100
  [Host]     : .NET Core 2.1.13 (CoreCLR 4.6.28008.01, CoreFX 4.6.28008.01), X64 RyuJIT
  DefaultJob : .NET Core 2.1.13 (CoreCLR 4.6.28008.01, CoreFX 4.6.28008.01), X64 RyuJIT

Aaronontheweb

public class AkkaMongoReader
{
    public ActorSystem Sys { get; }
    private readonly Akka.Serialization.Serialization _serialization;

    public AkkaMongoReader(ActorSystem sys)
    {
        Sys = sys;
        _serialization = Sys.Serialization;
    }

Aaronontheweb

Akka.NET QA Proposed Changes and Updates

Goals

1. Radically reduce the per-pull request build time

   1. Eliminate agent "spin up" time
   2. Don't waste resources executing tests for things that don't need testing, such as documentation updates and README fixes.
   3. Don't compile the entire project for each step in the build process.
   4. If possible, only execute dependent tests - not all tests (incremental testing.)

2. Reduce unit test flakiness

Aaronontheweb

using System;
using System.IO;
using System.Collections.Generic;
using System.Linq;
using Akka.Actor;
using Akka.Event;
using Akka.Routing;

namespace AkkaTest
{

Aaronontheweb

Avoiding Microservice Pains with Distributed Actors and Akka.NET

Microservices promised development teams a brand new world when it comes to developing, deploying, and distributing software. We could code services in any language, deploy them independently, enjoy partial failure instead of total, and straight-forwardly partition our teams along the same boundaries as some of our services.

But with these benefits came more expense and unanticipated costs. We now need multiple layers of routing and load-balancing. API gateways. Service discovery. Message brokers. Kafka. Laser manifolds. gRPC++ MQTT quantum tunneling. And so on.

In this talk we present a more refined, standardized, and simplified approach to building highly available, responsive, and distributed systems: distributed actors via Akka.NET. With this approach, we can eliminate most of the third party infrastructure needed to build effective applications, improve response times, and decrease human costs associated with building highly available s

Aaronontheweb

docker run --rm -it -v ${PWD}:/data -e DOTNET_FRAMEWORKS="net452,netcoreapp1.0" akkadotnet/mono-base /bin/bash