我们正在使用Storm 1.0.2并且在两个完全不相关的项目中存在错误超时的问题。并且已经在0.10中验证了这些问题......
我们有两种不同的情景：
首先。无论我们将元组超时设置为什么，当该时间过去时，我们会将多个元组恢复为失败状态。但是所有这些都比旧的超时时间少。例如，如果我们将超时设置为15分钟（疯狂的高），拓扑运行正常15分钟，每分钟处理数千个元组，但正好在15分钟，我们突然得到一千或更多的失败。当我们将消息ID追溯回原始发出的元组时，我们发现它们都是在前几分钟内发出的。没有超过15分钟超时的元组。它几乎就像系统在超时时一样，无缘无故地随机冲出飞行中的元组。
二。我们有一个拓扑，它会在同一消息的确认之前返回到spout。所以，事件的顺序：发出元组，在喷口中睡觉x秒。在那个x秒期间，最后一个螺栓击中了元组。鲸鱼喷水从睡眠中醒来。 spout的元组失败，下一次调用spout是同一个元组的ack。在此测试期间，在喷嘴睡眠期间，元组的一些超时确实已经过去，但是螺栓的确认是在超时之前。它好像排队的消息一样排队，因为它在ack之前就失败了，并且它没有机制来提取排队等待的失败消息，因为它只是得到了一个确认。这看起来并不一致。有时我们不会收到失败的消息，但有时我们会这样做。我们无法找出一种模式。
在这两种情况下，解决方案都是没有超时。我们已经测试了一周不同的东西，我们发现没有超时，我们的每一条消息都处理得很好，没有任何遗失。在一次实验中，我们甚至忽略了所有失败，一切都仍在处理中。然而，我们有成千上万的假失败。问题是，我们正在处理的数据被审查为100％完美，系统没有错误。在现实世界中，我们希望无法在几次不同的重试中重新发出元组，然后再到错误日志。但是如果我们不能指望Storm中超时的内置机制正确处理超时，那么我们就不得不在spount中建立自己的超时机制。
还有其他人遇到过这样的超时问题吗？这是＆＃34;已知＆＃34;问题？我们是否可能在我们的拓扑中设置一些不太正确的东西？
由于
... UPDATE 通过反复试验和一个测试拓扑结构，除了有一定数量的具有固定睡眠时间的螺栓之外什么都没做，我相信我可能已经找到了某种模式来确定发生了什么。
问题在于Storm系统没有保证消息（元组）处理顺序。它不仅没有得到它，它似乎有一些随机化信息的元素。这种随机化仅在我们向螺栓中添加并行时才会发生。由于我们的spout挂起设置太高，这令人厌烦。工人的数量似乎并没有影响这种观察，它只是影响事物的螺栓的相互作用。
我还不知道（尚未）消息在系统中被延迟的地方。它是从喷口到第一个螺栓，还是其中一个螺栓（我有3层），或者是真正完成的消息，但不会立即传回喷口。
我的测试拓扑尚未显示的是消息在超时之前是如何超时的。测试清楚地显示了在超时时间之后恢复的消息。在这一点上，我不得不假设消息通过螺栓，但是没有及时回到喷口？我需要建立一种记录每条消息通过系统的方法。
因此，这将我们带到了一块石头和一块坚硬的地方。我们有太多未决的原因是因为我们有一个7层或8层螺栓的拓扑结构。当待处理的数量很少时，我们当然没有超时，但螺栓不会在容量附近运行，而且我们的吞吐量（消息/秒）不是很好。我们尝试对螺栓进行并列化，使得每个螺栓在容量计算中均匀运行。一旦我们达到了容量均衡（没有热点），那么我们就开始调整其他事情了，其中一个调整措施就是增加来自喷口的元组。这个想法是每个螺栓的队列始终有消息;我们不希望一个bolt实例空闲，因为队列中没有它可以执行。
对我们来说，问题不在于消息是乱序的，事实上我们似乎没有任何类型的超时设置。如果我们这样做，我们就会失败回到真正失败的喷口。
有没有人知道为什么我们遇到这些问题？我们能做些什么......好吧......没有体验过它们？除了没有超时。