-
Notifications
You must be signed in to change notification settings - Fork 243
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
need AMQP 1.0 crate for Service Bus #643
Comments
What about Dove? |
There is also https://github.com/ntex-rs/ntex-amqp. Looks like there are contributors who work at Microsoft ntex-rs/ntex-amqp#15. |
I have been working on a tokio and serde based AMQP 1.0 implementation called fe2o3-amqp https://github.com/minghuaw/fe2o3-amqp , and I am planning to start working on the qpid integration test soon. It might be worth a try, and any feedback would be really appreciated. |
How much of the AMQP 1.0 spec is needed for Azure SDK? I have currently implemented most of the core spec (both client and server) as well as the web socket binding (only the client), and I am currently debating which extension spec to implement next. |
I have made two working examples showing how to use
I might start working on implementing the claim based security next. Would love to have some feedback :) |
Here is another quick update. I have added some working examples of sending to and receiving from Azure Event Hubs. The receiver example, however, seems like it's not moving the offset with an |
I think I figured out the offset issue with the filter example https://github.com/minghuaw/fe2o3-amqp/blob/main/examples/event_hubs/src/bin/receiver_with_filter.rs |
I am planning to work on an amqp client for servicebus and event hub. Is there any recommendations? Would mimicking the dotnet sdk be a good starting point? |
Sounds great @minghuaw! Yes, mimicking https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/servicebus/Azure.Messaging.ServiceBus and not the older https://github.com/Azure/azure-sdk-for-net/tree/main/sdk/servicebus/Microsoft.Azure.ServiceBus is the way to go. |
A quick question on getter/setter convention. Is there any preference on the getter/setter naming convention? The rust official naming convention guide (https://rust-lang.github.io/api-guidelines/naming.html#getter-names-follow-rust-convention-c-getter) suggests |
Yes, I believe we want to follow the conventions laid out in that guide. |
Is there any public documentation on how these servicebus-specific message annotations (https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#message-annotations) are encoded in AMQP? |
@cataggar Is there a public spec on how Service Bus session ID should be encoded? It seems like the current dotnet SDK (Azure.Messaging.ServiceBus) impl doesn't really comply with the AMQP 1.0 core spec. The way it is implemented in Azure.Messaging.ServiceBus is like following (Line 681) // even if supplied sessionId is null, we need to add the Session filter if it is a session receiver
if (isSessionReceiver)
{
filters.Add(AmqpClientConstants.SessionFilterName, sessionId);
}
var linkSettings = new AmqpLinkSettings
{
Source = new Source { Address = endpoint.AbsolutePath, FilterSet = filters }, // Line 690
// ... other setting
}; where However, regarding the
and For the rust implementation, this could be worked around by kinda hacking the upstream type definition (relax the value type from |
The discussion about the session ID in Azure/azure-amqp can be found in this issue: Azure/azure-amqp#231 |
The answer regarding session filter is copied from that issue just for reference: <type name="com.microsoft:session-filter" class="restricted" source="string" provides="filter">
<descriptor name="com.microsoft:session-filter" code="0x00000137:000000C"/>
</type> |
@cataggar When is the planned next release date? I just want to see whether I would be able to have something before the next release. I almost have a minimal viable impl for all APIs except for the ones related to processors. I haven't got the time to write enough tests either. |
We work towards a monthly release cadence. |
I have a working partial AMQP 1.0 implementation that currently includes:
What remains to be implemented include (in no particular order):
These implemented APIs cover roughly the same "surface area" provided by the golang SDK (azservicebus). And the implementation should look very similar to that of the dotnet SDK. I have only run some quick live tests with my own service bus namespace, so I definitely need to add more testing. However, this also raises a problem, suppose we need to run the live tests in GitHub Actions, is there a service bus namespace that can be used publicly? Or is there a way to set up the Actions to not leak the testing service bus namespace? Another question is that whether this would be a good point (after adding more tests) to submit a PR and then start working on the remaining of the planned components? Or is it better to implement everything before submitting a PR? Thanks in advance :) |
Hi @minghuaw, thanks for your work on this! I think I may be able to set up a service bus namespace you can use for testing, although it would be temporary. Would that suffice or are you looking for something permanent? |
Thank you @mario-guerra . That would be great. A temporary one would suffice. |
Hi @minghuaw, can you confirm the email address listed in your profile is correct? If so, I will send you a connection string for an instance of Service Bus you can use for testing. |
@mario-guerra Thanks. That one is correct (michael.wu1107@gmail.com) |
@minghuaw thanks for confirming, email with details has been sent. |
Hi @minghuaw, how is the testing going? Is there anything else you need? |
Hi @mario-guerra, thanks for checking out. Sorry I was sick for the past few days. The testing with the basic plan queue went fine, but one problem with the basic plan is that I couldn't test session-enabled queues, which I am still using my own service bus namespace for the testing. I am currently working on the documentation and examples and will soon be ready to submit a PR. |
@minghuaw that's great! Thanks for the update, we look forward to seeing your PR. |
Another quick update, the service still carries a legacy |
I've tagged the maintainer in the repo for comment, thanks for the heads up. |
While waiting for updates on Azure/azure-amqp#232, I will just provide some updates to the current implementation. And I think there are a few design decisions that could be discussed here. BTW, the current impl should be ready for PR (other than a few intra-doc-links that need to be fixed) whether or not they decide to fix that issue, but their decision is needed so that I can decide whether to publish a breaking update to the AMQP 1.0 dependencies Summary of current implementation statusWhat key public APIs have been implemented:
What remains to be implemented:
Some design decisions that could be discussed right now
|
Hi @minghuaw, for the sake of moving this PR forward I believe it's safe for you to assume the service team will not change the legacy behavior you identified any time soon. Given that it would be a breaking change, the odds of it happening are low. |
Thank you @mario-guerra . That sounds reasonable. I will try to get the PR ready later today or tomorrow then. |
@minghuaw that's great! I look forward to reviewing it. |
I have submitted the PR #1185. I will be happy to discuss and provide any explanation or help for your reviews :) |
Great! I see Ryan and Cameron are already tagged as reviewers. I believe they are both out of office for the remainder of the year, so we will review the PR after the new year. Thanks again for your work on this! |
This is kind of a general question regarding CI (more or less in the long run). It looks like the current CI setup doesn't run integration test for |
I feel like the current wasm ecosystem is quite fragmented given the various wasm targets (web, node, wasi, etc.). Is there a general scope of what wasm targets need to be supported? |
See @minghuaw's https://crates.io/crates/azservicebus |
There does not appear to be an AMQP 1.0 spec compliant crate. Crates like https://github.com/amqp-rs/lapin implement 0.9.1, but Service Bus requires 1.0. https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-overview
The text was updated successfully, but these errors were encountered: