retrypolicy

-1热度

2回答

我正在使用用C＃编写的客户端应用程序向群集交换服务器发送批量电子邮件。它可以发生，它做到了，客户端应用程序超时（而不是服务器）。由于无法知道服务器是否完成了请求，因此如何处理这种情况下的重试？没有参与IDS，可能是使用，以避免重复。设置长时间超时甚至无限超时并不是一个好策略。我使用重试指数退避算法。在这种情况下，它应该只发送一个副本，因为它将在下次等待更长时间。我认为没有子弹教授解决方

2热度

1回答

错误配置Azure存储帐户并用重试政策

后，这是我的代码配置Azure存储帐户 public CloudTableClient ConfigureStorageAccount() { var storageCred = new StorageCredentials(ConfigurationManager.AppSettings["SASToken"]); CloudTableClient = new Clo

1热度

1回答

CompletionService中的重试策略

我需要配置通过ExecutorCompletionService调用API的重试策略。示例代码： public void func() throws Exception{ ExecutorService executorService = Executors.newFixedThreadPool(5); CompletionService<String> completion

0热度

1回答

为什么我们在重试请求之间应用延迟

当我们有一段代码经常失败并且必须重试时。然后我们使用重试模式。 try { //do request here } catch (Exception e) { //wait for some millisecond and retry retry(); } 我们通常推迟一些毫秒之前重试该请求。我想知道为什么我们需要一些延迟？如果重试请求未等待并再次发送请

0热度

2回答

Cassandra：更改重试尝试次数和重试延迟

我正在使用客户端写入cassandra（api：com.datastax.driver.core）如果在连接完成后关闭cassandra clustures。我的日志中出现以下错误 2015-11-05 12:08:21,667 ERROR [Reconnection-1] com.datastax.driver.core.ControlConnection - [Control connect

1热度

1回答

AWS SQS重试多次

我正在研究一项要求，要求我在成功获取某些数据后调用特定的端点。我们使用发布到SQS队列的SNS主题实现了这一目标，SQS队列又调用端点。 SNS - > SQS - >我的端点（进程Q消息） - >调用外部端点来获取数据。现在，我们发现订单处理后数据不可用，现在需要每隔30秒继续尝试5次。有什么办法可以做到这一点？现在，我做了这样的事情，使得从队列处理消息的我的端点始终返回错误，以便重试消息

0热度

1回答

我可以信任Azure Blob RetryPolicy吗？为什么我无法在提琴手中找到这些重试请求

我试图从一个空的blob容器中下载文件，并按预期得到了404。问题是我在fiddler中看到的这个文件只有1个调用，而不是3个（正如我在RetryPolicy中指定的那样），我也注意到调用在1秒内完成，因此在再次尝试之前它肯定没有等待10秒。 .. 如何知道BlobClient是否真的重试了？ var blobClient = this.storageAccount.CreateCloudBlob

0热度

1回答

是否逻辑的应用程序支持指数退避随机三角洲

逻辑应用程序文档here指示逻辑应用程序支持使用以下"input" "retryPolicy" : { "type": "<type-of-retry-policy>", "interval": <retry-interval>, "count": <number-of-retry-attempts> } 的文档状态重试HTTP操作策略：的重试间

1热度

1回答

如何在Spring中将Retryable和CircuitBreaker结合在一起？

Spring的@Retryable注释将重试三次（默认）并回退到@Recovery方法。然而，@CircuitBreaker会在状态关闭时重试一次并回退。我想结合这两个：当断路器的状态是闭合的，在回退之前会重试三次（处理瞬态错误），如果状态是开放的，会直接回退。任何优雅的方式来做到这一点？一种可能的方法是在函数内部实现重试逻辑，但我觉得这不是最好的解决方案。

0热度

2回答

Service Bus 1.1（On Prem）消息发件人重试策略不起作用

不确定我的Service Bus 1.1的重试策略逻辑有什么问题。我们无法使用Azure服务总线。我尝试了几种不同的配置，但仍然没有运气让它着火。它只会移动到例外。 TokenProvider provider = TokenProvider.CreateSharedAccessSignatureTokenProvider("RootManageSharedAccessKey", "<key go