Handle System.InvalidOperationException in case of big body buffer send

[Gsantomaggio]

Fixes #220 and part of #145

How to reproduce the issue:

See #221 (comment)
Important:

• Server has to be remote
• the body needs to be bigger than 3k

Main changes:

• Make the WriteCommand Async:
  

  rabbitmq-stream-dotnet-client/RabbitMQ.Stream.Client/Connection.cs

  Lines 99 to 114 in 5c695ef

  	private async Task WriteCommand<T>(T command) where T : struct, ICommand
  	{
  	// Only one thread should be able to write to the output pipeline at a time.
  	await writeLock.WaitAsync();
  	{
  	var size = command.SizeNeeded;
  	var mem = new byte[4 + size]; // + 4 to write the size
  	WireFormatting.WriteUInt32(mem, (uint)size);
  	var written = command.Write(mem.AsSpan()[4..]);
  	await writer.WriteAsync(new ReadOnlyMemory<byte>(mem));
  	Debug.Assert(size == written);
  	await writer.FlushAsync();
  	}
  	writeLock.Release();
  	}

Remove sync Waits (because of https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca2012) :

rabbitmq-stream-dotnet-client/RabbitMQ.Stream.Client/Connection.cs

Lines 89 to 97 in 5c695ef

	public async ValueTask<bool> Write<T>(T command) where T : struct, ICommand
	{
	await WriteCommand(command);
	// we return true to indicate that the command was written
	// In this PR https://github.com/rabbitmq/rabbitmq-stream-dotnet-client/pull/220
	// we made all WriteCommand async so await is enough to indicate that the command was written
	// We decided to keep the return value to avoid a breaking change
	return true;
	}

• Make the Async Blocking:
  

  rabbitmq-stream-dotnet-client/RabbitMQ.Stream.Client/RawProducer.cs

  Lines 161 to 164 in 5c695ef

  	private async Task SemaphoreAwaitAsync()
  	{
  	await _semaphore.WaitAsync();
  	}

  
  It caused a lot of timeout operations but without any action to handle the problem.

• Move the semaphore scope on the Producer Class:
  

  rabbitmq-stream-dotnet-client/RabbitMQ.Stream.Client/Reliable/Producer.cs

  Line 207 in 5c695ef

  await SemaphoreSlim.WaitAsync();

It caused Client timeout Error in case of multi-threads publish

Signed-off-by: Gabriele Santomaggio [email protected]

[codecov]

Codecov Report

Base: 92.33% // Head: 92.33% // No change to project coverage 👍

Coverage data is based on head (b5bfe4c) compared to base (b5bfe4c).
Patch has no changes to coverable lines.

❗ Current head b5bfe4c differs from pull request most recent head f22f814. Consider uploading reports for the commit f22f814 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #220   +/-   ##
=======================================
  Coverage   92.33%   92.33%           
=======================================
  Files          94       94           
  Lines        8262     8262           
  Branches      651      651           
=======================================
  Hits         7629     7629           
  Misses        494      494           
  Partials      139      139           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[Zerpet]

Some early feedback, I understand the PR is still a WIP 🙂

[Gsantomaggio]

For more info about this change, see:
https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca2012

[Gsantomaggio]

This is the main change.
It makes WriteCommand async using WriteAsync Add FlushAsync instead of sync wait the task

[Gsantomaggio]

Remove this Async Await. In some case, it raises semaphorefullexception
after:

_logger.LogWarning("Semaphore Wait timeout during publishing.");

the code continue to work failing the scope of the lock

[Gsantomaggio]

Now everything is async with the await we return true; to leave the API compatibility

[Gsantomaggio]

Changed due of https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca2012

[lukebakken]

As far as I know, since this is a general-purpose library, every await should have ConfigureAwait(false) - https://devblogs.microsoft.com/dotnet/configureawait-faq/#when-should-i-use-configureawaitfalse