EventProcessorClient - AmqpRetryOptions options not set as expected-CodePudding

Here is our current scenario - Listen to all the partitions on a given event hub and logically process each message based on the content and re-process (until configured no. of times - say 3) the same event if the initial processing fails internally.

Following the recommended guidelines for higher throughput, we are planning to use EventProcessorClient (Azure SDK for consuming the events from Azure Event Hub. Using the EventProcessorClientBuilder, its initialized based on the docs.

 EventProcessorClient eventProcessorClient = new EventProcessorClientBuilder()
     .consumerGroup("consumer-group")
     .checkpointStore(new BlobCheckpointStore(blobContainerAsyncClient))
     .processEvent(eventContext -> {
         // process eventData and throw error if the internal logic fails
      })
     .processError(errorContext -> {
         System.out.printf("Error occurred in partition processor for partition {}, {}",
             errorContext.getPartitionContext().getPartitionId(),
             errorContext.getThrowable());
     })
     .connectionString(connectionString)
     .retry(new AmqpRetryOptions()
        .setMaxRetries(3).setMode(AmqpRetryMode.FIXED).setDelay(Duration.ofSeconds(120)))
     .buildEventProcessorClient();
eventProcessorClient.start();

However, the retry logic doesn't kick in at all, checking the documentation further - I wonder if this is only applicable for the explicit instance for EventHubAsyncClient. Any suggestions or inputs on what is required to achieve this retry capability ? Thanks in advance.

CodePudding user response：

re-process (until configured no. of times - say 3) the same event if the initial processing fails internally.

That is not how retries work with the processor. The AmqpRetryOptions control how many times the client will retry service operations (aka operations that use the AMQP protocol), such as reading from the partition.

Once the processor delivers events, your application owns responsibility for the code that processes them - that includes error handling and retries.

The reason for this is that the EventProcessorClient does not have sufficient understanding of your application code and scenarios to determine the correct action to take in the face of an exception nor to understand whether it is safe to assume that processing has not been corrupted.