Bonjour
Nouveau retour avec une analyse plus précise, la queue update semble contenir 26 millions de messages, il continue de l’alimenter mais apparemment côté amazon (c’est du sqs) il y aurait trop de message d’où les lenteurs. Ce qui est étrange c’est que en théorie je supprime les messages une fois le traitement ok. Donc soit j’ai un bug dans mon code (je l’ai relu et je vois rien qui pourrait l’expliquer), soit ya trop d’utilisateur qui ont mis en place Ajax avec une mauvaise URL externe et c’est donc ces messages qui s’empile (si l’envoi a jeedom est pas validé le message reste), soit Ajax ne m’a pas donné les droits en suppression…
Je vais leur demander de vérifier le dernier point et regarder les 2 autres points d’ici la fin de la semaine (je suis en vacances aujourd’hui donc pas sur d’avoir le temps).
En gros si tu configure ton jeedom avec le plugin ajax ca envoi aussi ton url externe pour que tu puisses avoir les mises à jour. Si elle n’est pas bonne ou change alors l’envoi de notre coté tombe en erreur, je ne supprime donc pas le message de queue car je n’ai pas reussi a le transmettre a ton jeedom.
Je suis de loin le sujet, juste une idée sur ce genre de cas (qui m’arrivent régulièrement sur des projets pro)
je pense qu’il faut se permettre de supprimer le message après 2 ou 3 essais max, pareil si le message est plus vieux que 10-15 minutes, on supprime; même si pas transmis
ca ne sert quasi plus à rien d’envoyer une info dépassée de plus de 30min
typiquement dans la gestion de milliers/millions de webhooks comme ca, on ne peut pas se permettre d’impacter tout le monde en faisant grossir la queue parce que certains destinataires ne répondent pas ou pas assez vite
=> je ne sais pas si tu as le contrôle sur la queue mais généralement le principe est de sortir le message de la queue principale dans tous les cas et de le mettre dans un queue de retry, au moins on n’impacte pas les nouveaux messages qui arrivent
et sur le process de retry, lorsqu’on traite le message, si trop vieux on le remet pas dedans
après faut jouer avec les délais / timeout etc en fonction du process
Si tu ne contrôles pas les queues, p-e en faire une autre dans votre infra et toujours supprimer dans celle d’ajax?
bref, je me doute que tu avais déjà réfléchi à tout ca mais avoir des idées externes aident à cogiter sur une solution (si elle existe), en tout cas c’est mon cas
Bonjour
Non j’ai aucun contrôle sur la queue et je pense d’ailleurs mon soucis vient de la j’ai essayé de la purger mais pas les droits, je suis pas sur d’avoir tout les droits en delete d’où le soucis. Pour supprimer les messages après retry c’est compliqué j’ai pas de données sur le nombre de retry ni sur la date d’émission du message…
la seule solution que j’ai trouvé dans ces cas c’est d’avoir une queue retry-1, retry-2, retry-3 …
1er tentative, tu deletes de la queue principale et insert dans la retry-1 si nécessaire
plus tard tentative depuis retry-1 et insert dans retry-2;
ainsi de suite …
quand t’arrives au bout tu drops et c’est fini (ou tu gardes dans une queue poubelle quelques temps pour monitorer éventuellement)
mais ca veut dire monter des instances de queue dans votre infra pour gérer ca et surtout ca ne fonctionnera que si le delete dans la queue chez ajax fonctionne, donc effectivement première étape chez à confirmer par eux.
même si on peut pas l’effacer la queue, elle peut être purgée sur aws/sqs. il y a une commande à cet effet via le CLI (purge-queue).
de plus : 26 millions c’est pas possible que ce soit nous :
MessageRetentionPeriod – The length of time, in seconds, for which Amazon SQS retains a message. Valid values: An integer representing seconds, from 60 (1 minute) to 1,209,600 (14 days). Default: 345,600 (4 days). When you change a queue’s attributes, the change can take up to 60 seconds for most of the attributes to propagate throughout the Amazon SQS system. Changes made to the MessageRetentionPeriod attribute can take up to 15 minutes and will impact existing messages in the queue potentially causing them to be expired and deleted if the MessageRetentionPeriod is reduced below the age of existing messages.
Bonjour
Pour la purge oui j’ai vu et j’ai essayé mais je n’ai pas droits de la lancer.
Par contre effectivement si au maximum c’est 14 jours le message 26 millions c’est bizarre j ça fait vraiment beaucoup. Faudrait je trouve un moyen de compter les messages moi pour valider (j’ai fais un changement dans mon code peut être que la non supression venait de la). J’attends aussi un retour d’Ajax sur les droits que j’ai car la supprime les messages en mode batch mais c’est un droit spécifique que je n’ai peut être pas.
c’est clair c’est étrange le nombre me semble énorme, en fait a partir du nombre de plugin installés si on divise ça donne le nombre moyen de requêtes par plugin . en meme si on est 5000, on obtient un résultat absurde même si on compte 50 device en moyenne, sachant que ça se purge seul au bout de 14 jours, sauf si de notre côté on génère une requête sur non réponse toutes les x secondes.
donc à suivre d’ici 10 jours si la corrections est la cause de l’accumulation, on va le savoir de toute façon même s on peut pas purger tu peux sans doute faire un get pour avoir la taille, c’est un bon indicateur à monitorer
Bonjour
J’ai essayé d’avoir la taille de la queue en demandant des priorités mais j’ai pas le droits et je peux pas savoir avec des get la taille de la queue.
Ok, je comprends, et forcément si il te donnent pas l’info depuis quand le message traine sur la queue c’est un peu complexe pour toi de faire le tri et dégager ce qui est périmé ou pas.
Mouaarfff. Evidemment prendre la décision de jeter les message qu’on sait pas dispatcher c’est un peu hard … après, la solution proposée plus haut de dépiler le message et d’avoir queue retry1,2,3 c’est pas con, mais c’est un peu plus lourd niveau implé.
Mais 26 millions de messages, je comprends que ça rame.
T’en penses quoi de la solution avec plusieurs queues de retry ?
Que c’est un gros boulot a implémenter surtout que je suis en train de revoir la manière dont le cloud envoi des infos a vos jeedoms en passant par du mqtt. En mettant ça en persistant j’aurais plus de soucis de retry.
)
de toute façon même s on peut pas purger tu peux sans doute faire un get pour avoir la taille, c’est un bon indicateur à monitorer