Fix that TlsHandler don't run well on Mono
Update Microsoft.NET.Test.Sdk from 15.0.0 to 15.6.1, it may fix that unable to run/debug an single test in vs for the 2nd time sometimes.
It's strange that The ci test always failed(but not failed in local) yesterday after this commit and later DisableParallelization.
DotNetty.Common.Tests.Utilities.HashedWheelTimerTest.* failed as it seems to be run in parallel with DotNetty.Common.Tests.Internal.Logging.InternalLoggerFactoryTest.TestMockReturned.
But the same commit always success today. Feel free to revert it if that happened again.
@nayato unsafe unaligned is good on netcore 2.1 preview. Eventually Span is a better choice once we move to 2.1.
@nayato If this will not be merged, should I pick up some commit not reated to Mono from this to another PR? Or more than one PR? I'm busy recently so may not do that soon.
5370c02 override all methods in LoggingHandler
9fa5825 Speed up test for TlsHandler(An string up to 1.5MB(17K303) can be alloc here)
e85a443 Remove space from filename. UnsafeByteBufferUtil .cs (seems LOST after rebase in this PR) and IByteBufferAllocatorMetric .cs(And IHttpData .cs in 0.4.8)
https://github.com/Azure/DotNetty/pull/374/commits/7515ab7e530be34e98b5fac975e1feed1c847dd1#diff-f5a1f6ab4f491acf78cbaeafeebc6dd1L252 Only ByteToMessageDecoder, see the todo left here before DiscardSomeReadBytes is ported.
a4be38b Failed to start debug for test in VS when after the first running.
9b52f6d An random test failed with parallel.(Not sure if it really works.)
And some thing in TlsHandler(Not sure)
https://github.com/Azure/DotNetty/blob/0.4.8/src/DotNetty.Handlers/Tls/TlsHandler.cs
L721 this->self
L756 BeginRead never call callback when finished Sync
L820 BeginWrite never check if callback is null when finished Sync
@yyjdelete that would be great. Feel free to bundle.
Hi, I've been having a few problems with tls, using dotnetty via a 3rd party, to connect from Xamarin.Forms, running into issues on both iOS and Android. I was speaking to the creator of the 3rd party package and he pointed me here.
The changes in the PR to TlsHandler.cs address this issue, I understand this may be a Mono problem underneath, but I was wondering what the state of this was and if it was to be merged?
The original problem by the way was a hang on IChannelHandlerContext.WriteAndFlush, eventually giving a ClosedChannelException
Thanks in advance, Paul.
Tested on net5.0-preview4+win10x64 without NETSTANDARD1_3 defined.
See another similar problem on net5.0+win10x64(also known as netcoreapp5.0) , and this patch(only ResetSource and ownBuffer part is required, Flush part is still only needed in (maybe only old versions of) mono) also works. Don't know what is changed in net5.0, but MediationStream.ResetSource() can be called before all buffer is consumed now.
Not test on net5.0+linux.
I will rebase this PR on the top of dev latter, in case of someone still need this.
For 331ea1e, view with ?w=1 to ignore white space changes
https://github.com/Azure/DotNetty/pull/374/commits/331ea1e54696d58a0d2ce548988c03a62ba21b8f?w=1