it's hard to parse the difference going into WinSock calls
yeah, it generates less garbage and has less synchronizations in code path
I'll have to check it out then - haven't really profiled that area as thoroughly since I made a bunch of structural changes to it for Helios 1.3
most of the performance improvements came from redoing the Executor and the EventLoop
This is a pretty slick lil UI. Hey fellas.
@Aaronontheweb hey, how do you actually plan to support TLS? the only serious implementation of TLS on .NET is SslStream and its API seems incompatible with netty's ChannelHandler.
also, I see messages being lost in client when receiving. here's gist for both client and the server: https://gist.github.com/nayato/d7d9b82d9adbc8272f3c . Problem seems worse on slower machines, e.g. on my desktop I see occasional loss of up to 500 messages, while on Medium VM in Azure it's 65k out of 100k messages. Probably I'm doing something wrong here.
I've had three folks approach me about message loss issues with Helios in the past 24 hours, too many to bea coincidence
so clearly there's an issue in the way we do some of the reactive socket stuff
here's what I'm going to commit to doing - I have to wrap up some work on the Akka.NET V1 release
but as soon as that's finished, moving forward on my plans for Helios 2.0
it's going to be a major change designed to introduce a better API, but most importantly much stronger concurrency and consistency guarantees around the socket
because right now I don't think it would be easy to patch the current model as-is
BTW, running the same pair of client and server I posted I get NRE:
Unhandled Exception: Helios.HeliosException: Unhandled exception on a connection with no error handler ---> System.NullReferenceException: Object reference not set to an instance of an object. at Helios.Net.Connections.TcpConnection.SendInternal(Byte buffer, Int32 index, Int32 length, INode destination) --- End of inner exception stack trace --- at Helios.Net.Connections.UnstreamedConnectionBase.InvokeErrorIfNotNull(Exception ex) at Helios.Net.Connections.TcpConnection.SendInternal(Byte buffer, Int32 index, Int32 length, INode destination) at Helios.Net.Connections.UnstreamedConnectionBase.Run() at Helios.Ops.Executors.BasicExecutor.Execute(Action op) at Helios.Concurrency.Impl.DedicatedThreadPoolFiber.<SpawnThreads>b_1(Object ) at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart(Object obj)
I can repro that (inconsistently but quite often) only on Azure Medium VM
@nayato same here, had this happen a lot during multi-node tests
as soon as we get Akka.NET V1.0 to code complete this will have my full attention