Use receiver timeout for underlying API calls to Event Hubs so that connector can retry on failures #492
Conversation
…he connector can retry on failures
There was a problem hiding this comment.
I think the same problem could occur if a user sets both Operation and Receiver timeout values to the same value. Shouldn’t we either
(A) advise the user about the potential of this issue if they set both to the same value? Or
(B) making sure that the receiver timeout is greater than the operation timeout when the user is setting either of those values.
Another situation is when the receive call fails. Since the “receiveOneWithRetry” uses the same receiverTimeout, wouldn’t a failed receive call cause the same problem with retry? Shouldn’t we use a value that is greater than both operation and receiver timeout in the connector to cover all possible situations?
| @@ -51,7 +51,7 @@ private class ClientConnectionPool(val ehConf: EventHubsConf) extends Logging { | |||
| s"No clients left to borrow. EventHub name: ${ehConf.name}, " + | |||
| s"ConsumerGroup name: $consumerGroup. Creating client ${count.incrementAndGet()}") | |||
| val connStr = ConnectionStringBuilder(ehConf.connectionString) | |||
| connStr.setOperationTimeout(ehConf.operationTimeout.getOrElse(DefaultOperationTimeout)) | |||
| connStr.setOperationTimeout(ehConf.receiverTimeout.getOrElse(DefaultOperationTimeout)) | |||
There was a problem hiding this comment.
Shouldn’t we use DefaultReceiverTimeout instead of DefaultOperationTimeout?
Current retry logic doesn't retry on a failure because underlying API calls to the Event Hubs service uses operation timeout which is also used by the connector. So, when timeout error occurs while accessing the event hub service, there will be no remaining timeout for the connector to retry.