2014-10-30 4 views
0

Поскольку все не работает ни днем, ни другим. Существуют ли какие-либо рекомендации/рекомендации по обработке ошибок при публикации сообщений в Amazon SQS?Обработка ошибок AWS SQS

Я запускаю SDK Amazon .NET и отправляю несколько 1000 сообщений SQS в день. Мне не приходило в голову, что публикация не удалась, но может быть, что любая проблема возникла.

Однако, как я должен обрабатывать ошибку в следующем базовом коде (в значительной степени прямой пример прямого использования из документации SDK):

public static string sendSqs(string data) 
{ 
    IAmazonSQS sqs = AWSClientFactory.CreateAmazonSQSClient(RegionEndpoint.EUWest1); 
    SendMessageRequest sendMessageRequest = new SendMessageRequest(); 
    CreateQueueRequest sqsRequest = new CreateQueueRequest(); 
    sqsRequest.QueueName = "mySqsQueue"; 
    CreateQueueResponse createQueueResponse = sqs.CreateQueue(sqsRequest); 
    sendMessageRequest.QueueUrl = createQueueResponse.QueueUrl; 
    sendMessageRequest.MessageBody = data; 
    SendMessageResponse sendMessageresponse = sqs.SendMessage(sendMessageRequest); 
    return sendMessageresponse.MessageId; 
} 

ответ

1

Вам не нужно вообще выполнять большую часть своей обработки ошибок; AWS SDK для .NET обрабатывает повторы для временных отказов под капотом.

Он будет автоматически повторит любой запрос, который терпит неудачу, если:

  • ваш доступ к сервису AWS в настоящее время задушил
  • времена запроса из
  • соединение HTTP не удается

It использует экспоненциальную стратегию отсрочки для нескольких попыток. При первом сбое он спит в течение 400 мс, затем пытается снова. Если эта попытка не удалась, она снова спит в течение 1600 мс, прежде чем повторять попытку. Если это не удастся, он будет спать за 6400 мс и т. Д., Максимум до 30 секунд.

Когда настроенное максимальное количество попыток достигнуто, SDK будет выбрасывать. Вы можете настроить максимальное количество повторных попыток, как это:

var sqsClient = AWSClientFactory.CreateAmazonSQSClient( 
      new AmazonSQSConfig 
      { 
       MaxErrorRetry = 4 // the default is 4. 
      }); 

Если вызов API заканчивается метанием, это означает, что что-то действительно не так, как SQS понизилось в вашем регионе, или ваш запрос является недействительным ,

Источник: The AWS SDK for .NET Source Code on GitHub.

+0

Если вы звоните в SQS из-за пределов EC2 или даже на EC2, но через NAT или прокси-сервер всегда есть возможность подключения к Интернету, даже если SQS по-прежнему доступен. Это может быть очень сложной проблемой, поскольку этот тип проблемы является основной причиной использования очереди в первую очередь. – JaredHatfield

1

Первый (вроде несвязанный) Я рекомендовал бы отделить клиента от отправить сообщение:

public class QueueStuff{ 
private static IAmazonSQS SQS; 

//Get only one of these 
public QueueStuff(){ 
    SQS = AWSClientFactory.CreateAmazonSQSClient(RegionEndpoint.EUWest1); 
} 
//...use SQS elsewhere... 

Наконец, чтобы ответить на ваш вопрос: проверьте Common Errors и SendMessage (в вашем случае) страниц и поймать соответствующие исключения. То, что вы делаете, будет зависеть от вашего приложения и того, как оно должно обрабатывать потери сообщений. Примером может быть:

public static string sendSqs(string data) 
{ 
    SendMessageRequest sendMessageRequest = new SendMessageRequest(); 
    CreateQueueRequest sqsRequest = new CreateQueueRequest(); 
    sqsRequest.QueueName = "mySqsQueue"; 
    CreateQueueResponse createQueueResponse = sqs.CreateQueue(sqsRequest); 
    sendMessageRequest.QueueUrl = createQueueResponse.QueueUrl; 
    sendMessageRequest.MessageBody = data; 
    try{ 
     SendMessageResponse sendMessageresponse = SQS.SendMessage(sendMessageRequest); 
    catch(InvalidMessageContents ex){ //Catch or bubble the exception up. 
    //I can't do anything about this so toss the message... 
    LOGGER.log("Invalid data in request: "+data, ex); 
    return null; 
    } catch(Throttling ex){ //I can do something about this! 
    //Exponential backoff... 
    } 
    return sendMessageresponse.MessageId; 
} 

Исключения, как Throttling или ServiceUnavailable являются те, обычно забывают, но могут быть обработаны должным образом. Его commonly recommended что для таких вещей вы реализуете экспоненциальный откат. Когда вы дросселируете, вы отступаете до тех пор, пока услуга не будет доступна снова. Пример внедрения и использования в Java: https://gist.github.com/alph486/f123ea139e6ea56e696f.

Смежные вопросы