Aaronontheweb

pbm cluster tail | foreach{ Write-Output "[$(Get-Date)] $_" } > cluster-tail.txt

Aaronontheweb

void Main()
{
	/*
		Input: [0], Output: [A] (length=1)
Input: [1], Output: [B] (length=1)
Input: [18446744073709551615], Output: [~~~~~~~~~~P] (length=11)
Input: [0], Output: [A] (length=1)
Input: [34343], Output: [nYI] (length=3)
	*/
	

Aaronontheweb

public static class Program
{
	public static void Main()
	{
		/*
		* Experimenting with manual Uri parsing in C# for fun and performance
		* Akka.NET custom Address parsing
		*
		* ex: akka.tcp://CustomerSys@localhost:9110/user/foo/bar/baz
		*

Aaronontheweb

/// <summary>
/// INTERNAL API.
///
/// <see cref="Span{T}"/> polyfills that should be deleted once we drop .NET Standard 2.0 support.
/// </summary>
internal static class SpanHacks
{
    public static bool IsNumeric(char x)
    {
        return (x >= '0' && x <= '9');

Aaronontheweb

.ConfigureHostConfiguration(configHost =>
{
    configHost.SetBasePath(Directory.GetCurrentDirectory())
        .AddJsonFile("appsettings.json")
        .AddEnvironmentVariables();
})

Aaronontheweb

Larger (more than 15 nodes booting up at once) deployments create a large number of quarantines / pod reboots that should be unnecessary in a clean deployment environment that isn't experiencing extremely high CPU utilization or bandwidth saturation.

So what could be causing this?

1. Default /system messages into Akka.Remote / Akka.Cluster are getting dropped during the joining process;
2. The failure-detector settings in Akka.Cluster too sensitive, this creates a large number of false positive unreachable events, which in turns breaks TCP connectivity, which creates quarantines;
3. Bug in the failure-detector implementation itself that only becomes exposed once the node count greately exceeds the nr-monitored-by values;
4. Could be problems with K8s pod readiness / liveness probes that prematurely cut out service-level DNS support for starting pods; and
5. Bug in the Akka.Cluster code that appears to trigger quarantines - as far as I know, there shouldn't be any /system messages sent at startup using van

Aaronontheweb

using System;
using System.Linq;
using System.Threading.Tasks;
using Akka.Actor;
using Akka.Streams.Dsl;

namespace Akka.Streams.Recipies
{
    class Program
    {

Aaronontheweb

Background and Motivation

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

open-telemetry/opentelemetry-dotnet#684 (comment)

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