Skip to content

Conversation

@YijunXieMS
Copy link
Contributor

Add ServiceBusSessionReceiverAsyncClient and ServiceBusSessionReceiverClient to accept a specific session or a next available session.

Closes #15330

@YijunXieMS YijunXieMS added Service Bus Client This issue points to a problem in the data-plane of the library. labels Oct 22, 2020
@YijunXieMS YijunXieMS added this to the [2020] November milestone Oct 22, 2020
@YijunXieMS YijunXieMS self-assigned this Oct 22, 2020
@YijunXieMS YijunXieMS marked this pull request as ready for review October 22, 2020 18:07
@YijunXieMS YijunXieMS requested a review from yvgopal as a code owner October 22, 2020 18:07

@Override
public void close() {
this.onClientClose.run();
Copy link
Member

Choose a reason for hiding this comment

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

Is this idempotent? If we call close multiple times, what happens.

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 calls the ServiceBusClientBuilder's close() method.

@check-enforcer
Copy link

This pull request is protected by Check Enforcer.

What is Check Enforcer?

Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass.

Why am I getting this message?

You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged.

What should I do now?

If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows:
/check-enforcer evaluate
Typically evaulation only takes a few seconds. If you know that your pull request is not covered by a pipeline and this is expected you can override Check Enforcer using the following command:
/check-enforcer override
Note that using the override command triggers alerts so that follow-up investigations can occur (PRs still need to be approved as normal).

What if I am onboarding a new service?

Often, new services do not have validation pipelines associated with them, in order to bootstrap pipelines for a new service, you can issue the following command as a pull request comment:
/azp run prepare-pipelines
This will run a pipeline that analyzes the source tree and creates the pipelines necessary to build and validate your pull request. Once the pipeline has been created you can trigger the pipeline using the following comment:
/azp run java - [service] - ci

* @return A {@link ServiceBusReceiverClient} that is tied to the available session.
* @throws IllegalStateException if the operation times out.
*/
public ServiceBusReceiverClient acceptNextSession(Duration timeout) {
Copy link
Member

Choose a reason for hiding this comment

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

What happens if timeout is Duration.ZERO? Also, if the timeout is larger than the retry timeout what happens? I don't think any code change is required but we just need to document both these cases.

Comment on lines 825 to 852
maxAutoLockRenewDuration, enableAutoComplete, sessionId, isRollingSessionReceiver(),
maxConcurrentSessions);

final ServiceBusSessionManager sessionManager = new ServiceBusSessionManager(entityPath, entityType,
connectionProcessor, tracerProvider, messageSerializer, receiverOptions);

return new ServiceBusReceiverAsyncClient(connectionProcessor.getFullyQualifiedNamespace(), entityPath,
entityType, receiverOptions, connectionProcessor, ServiceBusConstants.OPERATION_TIMEOUT,
tracerProvider, messageSerializer, ServiceBusClientBuilder.this::onClientClose, sessionManager);
}

/**
* This is a rolling session receiver only if maxConcurrentSessions is > 0 AND sessionId is null or empty. If
* there is a sessionId, this is going to be a single, named session receiver.
*
* @return {@code true} if this is an unnamed rolling session receiver; {@code false} otherwise.
*/
private boolean isRollingSessionReceiver() {
if (maxConcurrentSessions == null) {
return false;
}

if (maxConcurrentSessions < 1) {
throw logger.logExceptionAsError(
new IllegalArgumentException("Maximum number of concurrent sessions must be positive."));
}
maxAutoLockRenewDuration, enableAutoComplete, null, null);

return CoreUtils.isNullOrEmpty(sessionId);
Copy link
Member

Choose a reason for hiding this comment

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

All of this will be required for the session processor. Keep this code and make this available only for the processor.

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 added maxConcurrentSessions back at package level but keep isRollingSessionReceiver deleted from the builder because ReceiverOptions.isRollingSessionReceiver() can be inferred from it's own properties.

Comment on lines +787 to 789
ServiceBusReceiverClient buildClientForProcessor() {
return new ServiceBusReceiverClient(buildAsyncClientForProcessor(false), retryOptions.getTryTimeout());
}
Copy link
Member

Choose a reason for hiding this comment

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

Processor will never build a sync client. So, this method can be removed.

}

private ServiceBusReceiverAsyncClient buildAsyncClient(boolean isAutoCompleteAllowed) {
private ServiceBusReceiverAsyncClient buildAsyncClientForProcessor(boolean isAutoCompleteAllowed) {
Copy link
Member

Choose a reason for hiding this comment

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

Since the async client built for processor will always have autoComplete enabled, the boolean param is redundant and can be removed.

return false;
public ServiceBusSessionReceiverClient buildClient() {
return new ServiceBusSessionReceiverClient(buildAsyncClient(false),
retryOptions.getTryTimeout());
Copy link
Member

Choose a reason for hiding this comment

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

This timeout is for a single attempt, right? If the user has set retry policy to 3 attempts, will this not wait for the 2nd attempt after the first attempt fails due to timeout?

@YijunXieMS YijunXieMS merged commit 3b5d04c into Azure:master Oct 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Client This issue points to a problem in the data-plane of the library. Service Bus

Projects

None yet

Development

Successfully merging this pull request may close these issues.

sb : acceptSession API for session scenario

4 participants