web-dev-qa-db-fra.com

Pourquoi les messages SqS restent-ils parfois en vol dans la file d'attente

J'utilise les files d'attente Amazon SQS de manière très simple. Habituellement, les messages sont écrits et immédiatement visibles et lus. Parfois, un message est écrit et reste en vol (non visible) dans la file d'attente pendant plusieurs minutes. Je peux le voir depuis la console. Le temps d'attente de réception des messages est de 0 et la visibilité par défaut est de 5 secondes. Cela restera ainsi pendant plusieurs minutes, ou jusqu'à ce qu'un nouveau message soit écrit qui le libère d'une manière ou d'une autre. Un délai de quelques secondes est correct, mais plus de 60 secondes ne le sont pas.

Il y a toujours 8 fils de lecture qui sont longs à scruter, donc ce n'est pas que quelque chose n'essaye pas de le lire, ils le sont.

Edit: Pour être clair, aucune des lectures du consommateur ne renvoie de message du tout et cela se produit, que la console soit ouverte ou non. Dans ce scénario, un seul message est impliqué, et il est juste assis dans la file d'attente invisible pour les consommateurs.

Quelqu'un d'autre a-t-il vu ce comportement et que puis-je faire pour l'améliorer?

Voici le sdk pour Java J'utilise:

<dependency>
  <groupId>com.amazonaws</groupId>
  <artifactId>aws-Java-sdk</artifactId>
  <version>1.5.2</version>
</dependency>

Voici le code qui fait la lecture (max = 10, maxwait = 0 configuration de démarrage):

void read(MessageConsumer consumer) {

  List<Message> messages = read(max, maxWait);

  for (Message message : messages) {
    if (tryConsume(consumer, message)) {
      delete(message.getReceiptHandle());
    }
  }
}

private List<Message> read(int max, int maxWait) {

  AmazonSQS sqs = getClient();
  ReceiveMessageRequest rq = new ReceiveMessageRequest(queueUrl);
  rq.setMaxNumberOfMessages(max);
  rq.setWaitTimeSeconds(maxWait);
  List<Message> messages = sqs.receiveMessage(rq).getMessages();

  if (messages.size() > 0) {
    LOG.info("read {} messages from SQS queue",messages.size());
  }

  return messages;
}

La ligne de journal pour "lire .." n'apparaît jamais lorsque cela se produit, et c'est ce qui me fait entrer dans la console et voir si le message est là ou non, et c'est le cas.

amazon-web-servicesamazon-sqs
40
Jerico Sandhorn

Il semble que vous ayez mal interprété ce que vous voyez.

Les messages "en vol" ne sont pas en attente de livraison, ce sont des messages qui ont déjà été livrés mais qui n'ont pas été traités par le consommateur.

Les messages sont considérés en vol s'ils ont été envoyés à un client mais n'ont pas encore été supprimés ou n'ont pas encore atteint la fin de leur fenêtre de visibilité.

- http://docs.aws.Amazon.com/AmazonCloudWatch/latest/monitoring/sqs-metricscollected.html

Lorsqu'un consommateur reçoit un message, il doit - à un moment donné - soit supprimer le message, soit envoyer une demande à augmenter le délai pour ce message; sinon, le message redevient visible une fois le délai expiré. Si un consommateur ne parvient pas à effectuer l'une de ces opérations, le message redevient automatiquement visible. Le délai d'expiration de la visibilité est le temps dont dispose le consommateur avant qu'une de ces opérations ne soit effectuée.

Les messages ne doivent pas être "en vol" sans que quelque chose les ait déjà reçus - mais ce "quelque chose" peut inclure la console elle-même, comme vous le remarquerez dans la fenêtre contextuelle que vous voyez lorsque vous choisissez "Afficher/Supprimer les messages" dans le console (sauf si vous avez déjà coché la case "Ne plus afficher cela"):

Les messages affichés dans la console ne seront pas disponibles pour d'autres applications jusqu'à ce que la console arrête d'interroger les messages.

Les messages affichés dans la console sont "en vol" pendant que la console observe la file d'attente depuis l'écran "Afficher/Supprimer les messages".

La partie qui n'a pas de sens évident est que les messages soient en vol "pendant plusieurs minutes" si votre délai de visibilité par défaut n'est que de 5 secondes et que rien dans votre code n'augmente ce délai ... cependant ... cela pourrait être expliqué presque parfaitement par vos consommateurs ne disposant pas correctement du message, le faisant expirer et être immédiatement redistribué, donnant l'impression qu'une seule instance du message restait en vol, alors qu'en fait, le message revient brièvement au visible, pour être ensuite réclamé presque immédiatement par un autre consommateur, le ramenant à nouveau en vol.

68
Michael - sqlbot

Cela peut se produire lorsque vous envoyez ou verrouillez un message et en quelques secondes, vous essayez d'obtenir la nouvelle liste de messages. Amazon SQS stocke les données sur plusieurs serveurs et dans plusieurs centres de données http://aws.Amazon.com/sqs/faqs/#How_reliably_is_my_data_stored_in_Amazon_SQS .

Pour vous débarrasser de ces problèmes, vous devez attendre plus longtemps afin que la file d'attente ait plus de temps pour donner des résultats appropriés.

1
Satish Pandey