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

[Service Bus] Update to use core-amqp #5324

Merged
merged 24 commits into from
Jan 2, 2020

Conversation

ramya0820
Copy link
Member

Makes Service Bus build fine with latest Track 2 core dependencies.
This would be precursor step to start making changes for Service Bus Track 2.

Copy link
Contributor

@ramya-rao-a ramya-rao-a left a comment

Choose a reason for hiding this comment

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

One of the big changes in core-amqp was that the retry logic for $management operations (in managementClient.ts file) was moved out of the RequestResponseLink class.

By not including those changes in this PR, we are effectively removing all retries for $management operations. We cannot have the feature branch in this state of no retries

@@ -65,7 +65,8 @@
},
"sideEffects": false,
"dependencies": {
"@azure/core-amqp": "1.0.0-preview.1",
"@azure/core-amqp": "1.0.0-preview.3",
"@azure/core-http": "1.0.0-preview.3",
Copy link
Contributor

Choose a reason for hiding this comment

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

Why the dependency on core-http?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oops, might have been a merge error - fixed

@@ -106,6 +107,8 @@ export class Receiver {
renewMessageLock(lockTokenOrMessage: string | ServiceBusMessage): Promise<Date>;
}

export { RetryOptions }
Copy link
Contributor

Choose a reason for hiding this comment

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

I see RetryOptions being exported from the Service Bus library here, but it is not clear which of the APIs is now allowing the use of RetryOptions by the user

Copy link
Member Author

Choose a reason for hiding this comment

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

This hsould be clear once #4376 is picked up

connectionHost: this._context.namespace.config.host,
delayInSeconds: 15
retryOptions: {
maxRetries: Constants.defaultMaxRetries,
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't this be Constants.defaultMaxRetriesForConnection?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes - updated

times: Constants.defaultConnectionRetryAttempts,
connectionHost: this._context.namespace.config.host,
delayInSeconds: 15
retryOptions: { maxRetries: Constants.defaultMaxRetries, retryDelayInMs: 15000 },
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this be Constants.defaultMaxRetriesForConnection?

@ramya0820
Copy link
Member Author

ramya0820 commented Oct 1, 2019

One of the big changes in core-amqp was that the retry logic for $management operations (in managementClient.ts file) was moved out of the RequestResponseLink class.

Yes, I'm aware of this, since this is retrofitting core-amqp - looking to scope down to it and add retries in a different PR, and could be combined with #4376 since that's about updating the retries.

We cannot have the feature branch in this state of no retries

Is there a reason why?
@AlexGhiondea we specifically discussed about not checking in WIP code on master, can you help with scoping of PR changes here? This should allow for us to run tests on the code written, and would otherwise slow down dev work.

@ramya-rao-a
Copy link
Contributor

While moving this work to #4376 decreases the scope in this PR, it increases the scope of #4376.

My hope was to maintain status quo as far as the feature set is concerned while we make the move to use core-amqp, therefore, didnt want the branch to lose the retry features.

But, its fine if we want to use the approach of adding retries later.

@ramya0820 ramya0820 merged commit 0c584b5 into Azure:feature/service-bus-track-2 Jan 2, 2020
HarshaNalluru added a commit that referenced this pull request Feb 12, 2020
* Pin core-amqp version to preview.1

* Update lock file

* Fix merge conflicts

* [Service Bus] Update to use core-amqp (#5324)

* Use core-amqp in atom management client, comment tests that use token provider

* [Service Bus] Update to use latest core-amqp (#6861)

* [Service Bus] Update constructors to add overloads and use Azure Identity (#5436)

* sync-versions: rhea-promise and @azure/core-amqp for service-bus

* resolve merge conflicts appropriately

* API Report File for "@Azure/service-bus"

* Address feedback

* SERVICEBUS_CONNECTION_STRING_BROWSER remove from karma.conf

* update pnpm-lock file

* update API Report File for "@Azure/service-bus"

* remove rhea and rhea-promise dependencies

* add "rhea-promise" back

Co-authored-by: Ramya Rao <ramya.rao.a@outlook.com>
Co-authored-by: ramya0820 <45977823+ramya0820@users.noreply.github.com>
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.

2 participants