[Uber work item] Prefetch Reliability

[conniey]

No description provided.

[anuchandy]

This is the uber work item, which depends on the following -

Migration plan

#34298

Amqp-Core (must-have)

#33700
#33701
#33682

ServiceBus (must-have)

#30930
#33704
#33705
#33706
#33707

ServiceBus (nice-to-have)

#33710 (extension of 33707)

Work-item dependencies

[Note: Originally this ticket was titled "Deprecate service bus legacy SDK (a.k.a track1)", but given the common goal of individual work items is to make the prefetch more reliable, the title has been updated to Prefetch Reliability"]

[anuchandy]

All work items except 33706 are implemented in the PR #34854 . The wok-item 33706 (Session feature) is not planned for include in this PR and is treated as a work of its own.

[anuchandy]

All work items except 33706 are implemented in the PR #34854 . The wok-item 33706 (Session feature) is not planned for include in this PR and is treated as a work of its own.

Change of plan: We are addressing the session issue (33706) as well as part of #34854

[anuchandy]

These work items are being rolled out as incremental updates. The new underlying framework with improvements is called V2-Stack. The latest beta (beta.5) version of Service Bus (and its Core AMQP dependency) includes V2-Stack with these work items incorporated.

To use the beta.5 version, add the following dependency.

<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-messaging-servicebus</artifactId>
    <version>7.15.0-beta.5</version>
</dependency>

The beta.5 composes both the previous generation of stack (The stack GA versions are using) and the new V2-Stack. Some of the features by default use V2-Stack, while other features require V2-Stack opt-in. The opt-in or opt-out of a specific Stack (V2 vs previous generation) for a feature is accomplished by providing com.azure.core.util.Configuration object at the time of building the Client object.

For example, V2-Stack based Session Receive with ProcessorClient requires opt-in as shown below –

ServiceBusProcessorClient sessionProcessor = new ServiceBusClientBuilder()
        .connectionString(Config.CONNECTION_STRING)
        .configuration(new com.azure.core.util.ConfigurationBuilder()
          .putProperty("com.azure.messaging.servicebus.session.processor.asyncReceive.v2", "true") // 'false' by default, opt-in if enabling V2 is desired.
          .build())
        .sessionProcessor()
        .....

The following table lists the client types, corresponding configuration names and indicate if Client is enabled by default in V2-Stack or not. For a client that is not on V2-Stack by default, the example shown above can followed to opt-in.

Client Type	Configuration-Name	Is on V2-Stack By default?
Sender and management Client.	com.azure.messaging.servicebus.sendAndManageRules.v2	YES
Non-Session Processor and Reactor Receiver Client.	com.azure.messaging.servicebus.nonSession.asyncReceive.v2	YES
Non-Session Synchronous Receiver Client.	com.azure.messaging.servicebus.nonSession.syncReceive.v2	NO
Session Processor Receiver Client.	com.azure.messaging.servicebus.session.processor.asyncReceive.v2	NO
Session Reactor Receiver Client.	com.azure.messaging.servicebus.session.reactor.asyncReceive.v2	NO
Session Synchronous Receiver Client.	com.azure.messaging.servicebus.session.syncReceive.v2	NO

[anuchandy]

All SB client types have v2 support implemented, closing.