Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement full async channel #982

Closed
wants to merge 1 commit into from
Closed

Conversation

bollhals
Copy link
Contributor

@bollhals bollhals commented Dec 5, 2020

Proposed Changes

Implements the proposal (#970) except the wait for confirmation part (will be done later to keep this PR "smaller") and some smaller modification / renamings along the way.

Types of Changes

  • Bug fix (non-breaking change which fixes issue #NNNN)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause an observable behavior change in existing systems)
  • Documentation improvements (corrections, new content, etc)
  • Cosmetic change (whitespace, formatting, etc)

Checklist

  • I have read the CONTRIBUTING.md document
  • I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
  • All tests pass locally with my changes
  • I have added tests that prove my fix is effective or that my feature works
  • I have added necessary documentation (if appropriate)
  • Any dependent changes have been merged and published in related repositories

Further Comments

  • I've added xml documentation to all public API's
  • I've made the Channel classes as well as the interface public. The interface is returned in methods but it can be casted if users want to be able to.
  • I've extracted all channel 0 specific methods into the ConnectionChannel class, so the actual Channel is less crowded.
  • The implementation itself isn't fully async yet, but this is more about the API itself, so we can modify the things below next.

Open questions

  • Where should these types be saved in the source? (Current stored in "client/impl/channel")
  • What namespace should these types have?

@@ -121,6 +121,12 @@ private void ParseHeaderFrame(in InboundFrame frame)
throw new UnexpectedFrameException(frame.Type);
}

if (totalBodyBytes == 0)
Copy link
Contributor Author

@bollhals bollhals Dec 5, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was an exception thrown when ConsumerWorkService if the array was null (which was not caught due to an empty catch in the ConsumerWorkService, see other comment)

{
// ignored
_channelBase.OnUnhandledExceptionOccurred(e, "ConsumerWorkService");
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the empty catch I patched up


namespace RabbitMQ.Util
{
internal class SetQueue<T>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was not used at all

@@ -34,7 +34,7 @@
using System.IO;
using System.Reflection;

namespace RabbitMQ.Util
namespace Unit
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was only used in tests, so I moved it there

{
if (waitForConfirmation)
{
// TODO 8.0 - Call ModelRpc
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left various TODO 8.0 - in the code, this needs fixing in futher PRs

@bollhals
Copy link
Contributor Author

bollhals commented Dec 5, 2020

Mind taking a look at this? @stebet @bording @michaelklishin
(You were commenting on #970 )

@bollhals
Copy link
Contributor Author

I can't yet request formal reviews, but I would like to start having a discussion about these changes as they should mark the direction of 8.0.
@michaelklishin @stebet @danielmarbach @lukebakken

@stebet
Copy link
Contributor

stebet commented Dec 10, 2020

I can't yet request formal reviews, but I would like to start having a discussion about these changes as they should mark the direction of 8.0.
@michaelklishin @stebet @danielmarbach @lukebakken

I'll take a look at this tomorrow :)

Copy link
Collaborator

@danielmarbach danielmarbach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry wasn't able to finish the whole thing. I have limited time at my hands before christmas. Here are a few thoughts

/// for use in acknowledging received messages, for instance.
/// </summary>
public IModel Model { get; set; }
public IChannel Channel { get; set; }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love how channel is better aligned with the purpose

_disposed = true;
}

void IDisposable.Dispose()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see much value in implementing both IDisposable as well as IAsyncDisposable. Especially not because the first one requires us to do evil sync over async. Let's embrace async properly in v8

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can think about dropping IDisposable, but there might be some drawbacks with it (e.g. DI container might not fully support it or 🤷‍♂️ )
I do not know what's the best way forward for this.

@bollhals
Copy link
Contributor Author

Sorry wasn't able to finish the whole thing. I have limited time at my hands before christmas. Here are a few thoughts

Well it's a big change and any feedback is very much appreciated!

Regarding the questions about async in Consumer / Connection, as the PR was already quite huge, so I've tried to limit changes outside of the IModel/IChannel for a future PR. I think it's simple to do changes to full async all the way stepwise. But yes all of it should be modified!

@michaelklishin michaelklishin changed the base branch from master to main June 24, 2021 14:35
@lukebakken lukebakken added this to the 7.0.0 milestone Mar 8, 2022
@lukebakken lukebakken changed the title 8.0 - implement full async channel Implement full async channel Mar 8, 2022
@michaelklishin
Copy link
Member

Sorry to drag you into resolving some non-trivial conflicts @bollhals. We decided to go ahead
and merge #1202 as it felt like the
right thing to do since we require net6.0 now for 7.0. This obviously affects all pull requests in flight.

@lukebakken lukebakken mentioned this pull request May 13, 2022
@lukebakken
Copy link
Contributor

I will hopefully be able to bring this PR up-to-date once #1199 is merged.

@lukebakken lukebakken self-assigned this May 13, 2022
@michaelklishin
Copy link
Member

I reverted #1202 because it makes back and forward-porting impossible unless all maintained branches adopt file-scoped namespaces.

@lukebakken
Copy link
Contributor

@bollhals now that I've merged #1264 would you like to rebase this on main? I can give it a try as well.

@bollhals
Copy link
Contributor Author

bollhals commented Mar 1, 2023

I'm swamped with other stuff right now, so I do not have a lot of time to invest in this. So if you/someone can take over, that would be great.

@stebet
Copy link
Contributor

stebet commented Mar 2, 2023

Would it make sense to make several small PRs, starting simply with ConnectAsync and then gradually going through the operations?

I'll take a quick look to see how much work this is to merge and go through before suggesting we take an approach like splitting it up into smaller PRs

@lukebakken
Copy link
Contributor

Thanks @stebet

@lukebakken
Copy link
Contributor

@stebet I'm starting on porting these changes to main, beginning with the IModel -> IChannel and related renames.

lukebakken added a commit that referenced this pull request Mar 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants