Ah well, I would try, but using nuget from within visual studio to downgrade was apparently a bad idea, everything is wonderfully jacked now. :)
well, got some answers from the DotNetty crew that make some sense
due to some issues with .NET Core, it's possible that the byte buffer pools DotNetty uses can be released early
by the socket itself
especially true on Linux
we use the default byte buffer allocator in our DotNetty transport, which uses pooling
this normally helps performance big time, because it eliminates allocations and keeps GC pressure down
guess I could expose some sort of setting to change the pooling strategy within Akka.Remote's DotNetty transport ("none" being an option)
but anyway, that issue is fixed in DotNetty v0.5.0 and they have one last PR they're trying to sort out before moving ahead with that
@Aaronontheweb thanks for the help that did it. now onto the next problem.
If I have 2+ nodes (cluster sharding) running, and I start sending messages, none are getting processed, once I drop down to 1, processing starts on that node, then I can later add additional nodes and they will sometimes pick up the load.. Is this by design?