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

[azservicebus] Final API changes for beta.3 #16110

Merged
merged 27 commits into from
Nov 10, 2021

Conversation

richardpark-msft
Copy link
Member

Lots of renames and changes based on the API reviews:

Admin API:

  • All Response structs have been broken down into Response+Result
  • QueueName, TopicName, SubscriptionName are no longer present in the Properties structs as that doesn't reflect the API itself.
  • Exists functions have been removed
  • Missing fields have been added (UserMetadata, etc..)

Sender and Receiver API:

Missing:

  • AuthorizationRules, SubscriptionRules (coming in a future PR but requires a bit more thought)

@richardpark-msft
Copy link
Member Author

/azp run go - azservicebus

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@richardpark-msft richardpark-msft marked this pull request as draft November 7, 2021 20:32
…e drain any messages that have arrived as we drain a link (this was a small, if possibly non-existent window, but it's good bulletproofing)

- Adding in PropertiesToModify options for DeferMessage, and AbandonMessage, allowing users to have properties modified service-side when the message is moved/returned.
- Adding in another short-lived stress test - send 10000ish messages, and receive them all. Need some more work, but we're just creating some skeletons.
- Adding in missing properties for entities that are present like UserMetadata, AutoDeleteOnIdle, etc... Still missing: AuthorizationRules, and TopicRules.
- Many many renames based on API feedback.
  - Eliminating $skip parameter, treating $top as "max page size"
  - Simple consistency renames when you specify the name for an entity (ie, topic => topicName, etc..)
  - Responses from Admin clients now conform to standard - Responses embed a Result which embeds the natural return value (ie: QueueProperties).
- Lots of future proofing *options parameters, where we think we might eventually have some options.
- ReceivedMessage.Body is now a function, rather than a field. This protects against a situation where, if a message was crafted directly using an AMQP stack, it could encode the Body into a format we couldn't represent. This will not return an error. When we add in low level AMQP support these messages will be readable through there.
@richardpark-msft
Copy link
Member Author

/azp run go - azservicebus

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@richardpark-msft
Copy link
Member Author

/azp run go - azservicebus

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@richardpark-msft richardpark-msft marked this pull request as ready for review November 8, 2021 19:36
@richardpark-msft
Copy link
Member Author

/azp run go - azservicebus

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@richardpark-msft
Copy link
Member Author

/azp run go - azservicebus

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

…a pointer.

- adding in some unit tests for the pagers.
sdk/messaging/azservicebus/admin/admin_client.go Outdated Show resolved Hide resolved
sdk/messaging/azservicebus/admin/main_test.go Show resolved Hide resolved
sdk/messaging/azservicebus/client.go Show resolved Hide resolved
sdk/messaging/azservicebus/message.go Show resolved Hide resolved
sdk/messaging/azservicebus/messageBatch.go Outdated Show resolved Hide resolved
@richardpark-msft
Copy link
Member Author

/azp run go - azservicebus

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@richardpark-msft
Copy link
Member Author

/azp run go - azservicebus

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@richardpark-msft
Copy link
Member Author

/azp run go - azservicebus

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@richardpark-msft
Copy link
Member Author

/azp run go - azservicebus

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@richardpark-msft
Copy link
Member Author

/azp run go - azservicebus

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Richard Park added 2 commits November 9, 2021 16:31
… page is < max page size that's the last page, don't do further requests after that.

Also, unified all the pagers under one function instead of separate little pager functions.
@richardpark-msft
Copy link
Member Author

/azp run go - azservicebus

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@richardpark-msft richardpark-msft merged commit ae68cfe into Azure:main Nov 10, 2021
@richardpark-msft richardpark-msft deleted the jeffr-api-changes branch November 10, 2021 18:11
func (ac *AdminClient) ListSubscriptions(topicName string, options *ListSubscriptionsOptions) SubscriptionPropertiesPager {
var pageSize int
var skip int
func (ac *Client) ListSubscriptions(topicName string, options *ListSubscriptionsOptions) SubscriptionPropertiesPager {
Copy link
Member

Choose a reason for hiding this comment

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

Don't return an interface here.

}

// Body returns the body for this received message.
// If the body not compatible with ReceivedMessage this function will return an error.
Copy link
Member

Choose a reason for hiding this comment

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

When would be the body not be compatible (what does that even mean)? Is the error in this case useful or can we just return a nil slice?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll clarify it when I actually add in AMQP support which I'm doing now. I didn't want to add too much info here until then.

What I will eventually write is:

The body (in an AMQP message) can be in three separate spots - in the Value section, the Data section or in a Sequence section. Each section has a possible value that will not cleanly encode to a single []byte array.

Data -> can contain multiple byte arrays
Value -> can contain AMQP primitives, etc..
Sequence -> can be a sequence that's not bytes


ContentType string
CorrelationID string
// Body corresponds to the first []byte array in the Data section of an AMQP message.
Copy link
Member

Choose a reason for hiding this comment

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

Can this comment be removed?

@@ -53,18 +45,18 @@ func (s *Sender) NewMessageBatch(ctx context.Context, options *MessageBatchOptio
return nil, err
}

maxBytes := int(sender.MaxMessageSize())
maxBytes := int32(sender.MaxMessageSize())
Copy link
Member

Choose a reason for hiding this comment

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

Seems weird we have to down-cast here. Makes me think we should change this in go-amqp to a uint32, although you'd still have to cast here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Let me check what the actual native type is. It might be that I need to go the other way, even if, in reality, the domain doesn't support a crazy large max message size.

Copy link
Member Author

Choose a reason for hiding this comment

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

So this is an AMQP field (straight from the attach frame) and it's typed to be a ulong, not a long.

So we should probably follow suit there, but int32 is definitely wrong.

sdk/messaging/azservicebus/sender.go Outdated Show resolved Hide resolved
jhendrixMSFT pushed a commit to jhendrixMSFT/azure-sdk-for-go that referenced this pull request Jan 12, 2022
Lots of renames and changes based on the API reviews:

Admin API:
- All `Response` structs have been broken down into `Response+Result`
- QueueName, TopicName, SubscriptionName are no longer present in the Properties structs as that doesn't reflect the API itself.
- <Entity>Exists functions have been removed
- Missing fields have been added (UserMetadata, etc..)

Sender and Receiver API:
- SendMessages removed in favor of making SendMessageBatch more intuitive (by simplfying the .AddMessage API)
- Several renames suggested in review
- ReceiveMessages has been tuned to match the .NET limits (which has worked well in practice). This is partly addressing Azure#15963, as our default limit was far higher than needed.

Coming in near term PRs:
- AuthorizationRules, SubscriptionRules (coming in a future PR but requires a bit more thought)
-
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