blocks|key|1607990|text|尽管螺栓的执行延迟小于1秒，但Spout+1的完全延迟是49秒。这告诉我你在某个地方有积压。如果您的超时足够低，您将有消息超时，并且失败地返回重新提交它们的突发事件，从而使待办事项变得更糟。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1607991|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Complete latency for Spout 1 is 49 seconds even though the execute latency for the bolts is less than a second. That tells me that you've got a backlog somewhere. If your timeout is low enough you'll have messages timing out and failing back to the spout which resubmits them making the backlog worse.

blocks|key|985723|text|你试过打开/关闭系统数据吗？这也包括或不包括附加的滴答元组。这样，除了滴答元组之外，您还可以得到实际的元组数。此外，您还可以尝试增加元组的超时，以避免多次发送。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|985724|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Have you tried turning on/off system stats ? That also includes or excludes tick tuples acked. That way you can get actual tuples number apart from tick tuples. Also you can try increasing the timeout for tuples in order to avoid sending them multiple times.

blocks|key|985749|text|元组只有两种可能失败的方式。或者，OutputCollector.fail(...)方法是由Bolt或tuple超时中的用户代码调用的。为Spout显示的“完全延迟”值是平均值值。因此，这是绝对有道理的，大多数元组显示为失败，运行到一个超时，因为只有3个元组被用户代码失败。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|BOLD|entityRanges|data|985750|关于已发出和加标的元组计数:+UI中报告的计数并不总是精确的。即使Storm在内部正确计数，UI也不会显示精确的值，因为计数器是一个接一个地收集的。因此，在收集阶段，计数器之间会发生变化，UI不会得到计数值的总体一致快照。|985751|参数topology.max.spout.pending可能是相关的。减少它应该会降低元组陷入超时的可能性。增加超时值本身可能于事无补(因为你声称它已经“相当高”了--不管这意味着什么)。|985752|很难说，是否存在网络问题。如果日志中没有错误消息，网络应该是安全的。|985753|entityMap^0|H|P|2D|3|0|0|2|Q|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|D]]|E|@]|F|$]]|$1|G|3|H|5|6|7|T|8|@]|E|@]|F|$]]|$1|I|3|J|5|6|7|U|8|@$9|V|A|W|B|C]]|E|@]|F|$]]|$1|K|3|L|5|6|7|X|8|@]|E|@]|F|$]]|$1|M|3|-4|5|6|7|Y|8|@]|E|@]|F|$]]]|N|$]]

There are only two ways a tuple can fail. Either, the method <code>OutputCollector.fail(...)</code> is called by the user code within a Bolt or a tuple times out. The value "Complete Latency" that is shown for the Spout is an average value. So it makes absolutely sense, that most tuples shown as failed ran into a timeout, as only 3 tuples got failed by the user code.

About emitted and acked tuple counts: The reported counts in the UI are not always precise. Even if Storm does count correctly internally, the UI does not show precise values because the counters are collected one by one. Thus, during the collection phase, the counters change in between and the UI does not get an overall consistent snapshot of the count values.

The parameter <code>topology.max.spout.pending</code> might be related. Reducing it should lower the chance that a tuple runs into a timeout. Increasing the timeout value itself might not help (as you claim that it is already "pretty high" -- whatever that means).

It is hard to say, if there is a network problem or not though. If there are not error messages in your log, the network should be fine.

blocks|key|1608075|text|您的元组确实是超时。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|1608076|看看你的平均完全延迟49秒。这意味着，平均每个元组在拓扑内花费了48秒，没有被任何螺栓处理(如果你把螺栓的平均执行时间之和小于1秒.和49-1=48)。|1608077|在您的情况下，解决方案是在拓扑中同时更改元组的数量。因此，您应该将topology.max.spout.pending更改为低于5000的值。您应该尝试几个值，但我认为1000可以做到这一点。|CODE|1608078|在你问之前，增加元组超时并不是解决办法。|1608079|关于第一螺栓上丢失的元组。您确定每个传入的元组都会产生另一个元组吗？|1608080|您唯一声明的是，您将失败元组，您总是为每个元组生成一个元组，每个元组接收到|1608081|entityMap^0|7|2|0|0|C|3|X|Q|0|0|0|F|M|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|J]]|D|@]|E|$]]|$1|K|3|L|5|6|7|11|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|12|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|13|8|@$9|14|A|15|B|C]]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|R|$]]

Your tuples are indeed timing out. 

Look at your average complete latency 49 seconds. Which means that in average each tuple spent 48 seconds inside the topology not being processed by any bolt (if you sum the average execution time by the bolts is less than 1 second... and 49-1=48). 

The solution in your case is to change the number of tuples at the same time inside the topology. Therefore you should change the <code>topology.max.spout.pending</code> to a value lower than 5000. You should try several values, but i think 1000 might do the trick.

<h2>And before you ask, increase the tuple timeout is not solution.</h2>

Regarding the missing tuples on bolt one. Are you sure that for each incoming tuple another tuple will be produced? 

The only thing you state is that you will ack of fail the tuple, do you always produce one tuple for each tuple that you receive?

Please find below the stats for the Storm topology.

<a href="https://i.stack.imgur.com/hl8kb.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/hl8kb.png" alt="Topology Status"></a>

Relevant info: 

<ul>
<li>spout1 emits all the tuples to bolt1</li>
<li>bolt1 executes additional tick tuple (that's why it doesn't match the no of tuple emitted from spout1)</li>
</ul>

Below are my questions:

<ol>
<li>There are 1059 failures in the spout, whereas there are only 3 failures in one of the downstream bolt</li>
<li>The no of tuples emitted from spout1 does not match the no of tuple acked back by bolt1 (I have checked the code, every tuple acks or fails that enters bolt1)</li>
</ol>

Could anyone help me understand what could be wrong here. My initial guesses are:

<ul>
<li>The topology.max.spout.pending is set to 20,000. Could this be causing some kind of buffer overflow. (But if such a overflow occurs, would bolt not report failure?)</li>
<li>Could there be any network issue that could be causing the tuple to not reach the bolt.</li>
</ul>

Failures in spout with no failures in bolts

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

请在下面找到暴风拓扑的统计数据。​​相关信息：spout1将所有的元组发布到bolt1bolt1执行附加的滴答元组(这就是为什么它不匹配从spout1发出的元组的编号)以下是我的问题：喷口有1059处故障，而下游螺栓中只有3处发生故障。从spout1发出的元组的no与bolt1返回的元组不匹配(我已经检查了代码、每个进...

问喷口失效而螺栓无故障
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问喷口失效而螺栓无故障EN