Meine Topologie verwendet den Standard KafkaSpout Implementierung. Bei einigen sehr kontrollierten Tests bemerkte ich, dass der Tülle Tupel fehlschlug, obwohl keiner meiner Tubes irgendwelche Tupel versagte und ich sicher war, dass alle Nachrichten innerhalb meines konfigurierten Timeouts vollständig verarbeitet wurden.
Ich bemerkte auch, dass (aufgrund einer Unterklassenstruktur mit meinen Bolzen) einer meiner Bolzen zweimal Tupel quittierte. Als ich das reparierte, hörte die Tülle auf, Tupel zu verwerfen.
Entschuldigung, dass dies mehr als eine Plausibilitätsprüfung isteine Frage, aber macht das Sinn? Ich sehe nicht, warum die gleiche Tupelinstanz zweimal quittiert wird, damit der Spout Zeitüberschreitungen registriert, aber es scheint, dass es in meinem Fall war.
Antworten:
5 für die Antwort № 1Es macht Sinn.
Storm verfolgt alle Acks (direkt undindirekt) für ein Tupel, das von einer Tülle in einer ungeraden, aber effektiven Weise abgegeben wird. Ich bin mir des exakten Algorithmus nicht sicher, aber es bringt wiederholt das XOR-Verknüpfen der ursprünglich ausgegebenen Tupel-ID mit den IDs der nachfolgenden verankerten Tupel-IDs mit sich. Jede dieser nachfolgenden IDs wird zweimal XOR-verknüpft - einmal wenn das Tupel verankert ist und einmal wenn das Tupel angekreuzt ist. Wenn die Ergebnisse eines XORs alle Nullen sind, dann ist die Annahme, dass jeder Anker durch ein Ack-Ergebnis abgeglichen wurde, und das ursprüngliche Tüll, das ausgegeben wurde, hat die Verarbeitung beendet.
Indem Sie einige Tupel mehr als einmal anzeigten, ließen Sie es so aussehen, als wären einige der von Tüllen emittierten Tupel nicht vollständig abgeschlossen (weil eine ungerade Anzahl von XORs niemals null wird).