2016-12-19 1 views
0

J'ai créé une file d'attente non-FIFO de base et n'y ai ajouté qu'un seul message. Je récupère le message en utilisant le code suivant:SQS renvoie plus de messages que la taille de la file d'attente

ReceiveMessageRequest request = new ReceiveMessageRequest(); 
request.setQueueUrl(queueUrl); 
request.setMaxNumberOfMessages(10); 
request.withMessageAttributeNames("All"); 
ReceiveMessageResult result = sqsClient.receiveMessage(request); 
List<Message> messages = result.getMessages(); 

messages.size() donne 3

Ils ont:

  • même MessageId
  • corps même et les attributs
  • même MD5OfBody
  • Différente ReceiptHandle

Modification MaxNumberOfMessages de 10 à 1 l'a fixé, mais je veux recevoir par lot de 10 à l'avenir. Est-ce que quelqu'un peut expliquer pourquoi il récupère plus de messages qu'il ne le devrait?

Ci-dessous est ma configuration de file d'attente:

Default visibility timeout = 0 
message retention = 4 days 
max message size = 256kb 
delivery delay = 0 
receive message wait time = 0 
no redrive policy 

Répondre

1

Détails/complément à @ Michael - Commentaire de sqlbot.

La définition du SQS visibility timeout à une petite valeur ne résoudra pas votre problème. Vous allez à nouveau frapper le problème. Utilisez 30 secondes ou plus pour permettre à votre programme de consommer le message. (Pour répondre aux accidents de programme/retard de programme inattendu, vous devez créer une politique de redirection pour atténuer les problèmes.)

AWS a mentionné cela dans At-Least-Once Delivery

Amazon SQS stocke des copies de vos messages sur plusieurs serveurs pour redondance et haute disponibilité. En de rares occasions, l'un des serveurs qui stocke une copie d'un message peut être indisponible lorsque vous recevez ou supprimez un message. Si cela se produit, la copie du message ne sera pas supprimée sur ce serveur indisponible, et vous pourriez recevoir à nouveau cette copie de message lorsque vous recevrez des messages. Vous devez concevoir vos applications comme idempotentes (elles ne doivent pas être affectées négativement lors du traitement du même message plusieurs fois).

0

Changement Default Visibility Timeout de 0 à 1 seconde fixe la question

+4

Ni 1 ni 0 ne sont susceptibles d'être une valeur appropriée pour le délai de visibilité par défaut. C'est presque certainement beaucoup trop court. Le délai d'expiration de la visibilité est la durée pendant laquelle SQS attend que vous supprimiez un message avant de supposer que vous avez planté ou rencontré un bogue, et redistribue le message, peut-être à vous ou à un autre consommateur de la même file d'attente. que vous avez échoué et en quelque sorte perdu le message et aurez besoin de le recevoir (et le traiter) à nouveau. –

+0

@ Michael-sqlbot merci! CA aide –