我们使用的是Storm1.0.2，在两个完全不相关的不同项目中存在错误超时的问题。并在0.10中验证了这些问题。。。
我们有两种不同的情况：
第一。不管我们将tuple timeout设置为什么，当这个时间过去时，我们都会得到一些失败的tuple。但它们都不到超时时间。例如，如果我们将超时设置为15分钟（疯狂的高），拓扑在15分钟内运行良好，每分钟处理数千个元组，但恰好在15分钟时，我们突然得到1000个或更多的失败。当我们将消息ID追溯到最初发出的元组时，我们发现它们都是在前几分钟发出的。没有超过15分钟超时的元组。几乎就好像系统在超时时，只是毫无理由地随机刷新飞行中的元组。
第二。我们有一个拓扑结构，它在同一条消息确认之前将故障返回到喷口。所以，事件的顺序是：发射元组，在喷口中睡眠x秒。在这x秒期间，最后一个螺栓会确认元组。壶嘴从睡梦中醒来。喷口得到元组的fail，下一个对喷口的调用是同一元组的ack。在这个测试期间，在喷口睡眠期间，元组确实经历了一些超时，但是来自螺栓的ack在超时之前。这就好像到喷口的消息在acks之前排队失败一样，它没有任何机制来提取排队等待的失败消息，因为它刚刚得到了一个ack。这似乎并不一致。有时我们得不到失败的信息，但有时我们得到了。我们找不出一个模式。
在这两种情况下，解决方案都是不超时。我们已经测试了一个星期了，我们发现没有超时，我们的每一条消息都处理得很好，没有任何东西丢失。在一次实验中，我们甚至忽略了所有的失败，所有的事情都被处理了。然而，我们有成千上万的错误失败。问题是，我们正在处理的数据经过审查是100%完美的，系统是无错误的。在现实世界中，我们希望失败的重新发出元组进行几次不同的重试，然后发送到错误日志。但是，如果我们不能指望风暴中的内置超时机制来正确处理超时，那么我们就不得不自己在喷口中建立自己的超时机制。
有没有其他人遇到过这样的超时问题？这是“已知”问题吗？我们是否在拓扑中设置了一些不太正确的东西？
谢谢
更新。。。通过反复试验，以及一个只有固定睡眠时间的大量插销的测试拓扑结构，我相信我可能已经找到了某种模式来描述正在发生的事情。
问题在于storm系统不遵循消息（元组）处理顺序。它不仅没有高伦蒂它，它似乎有一些随机化的信息元素。这种随机化只发生在我们把平行性加到螺栓上时。这是由我们的喷口等待设置过高的事实加剧。工人的数量似乎并不影响这一观察，只是螺栓的平行性影响了事情。
我还不知道系统中的消息在哪里被延迟了。是从喷口到第一个螺栓，还是中间的一个螺栓（我有3层），还是消息真的完成了，但没有立即传回喷口。
我的测试拓扑结构还没有显示消息在超时之前是如何超时的。测试清楚地显示了在超时时间后返回的消息。在这一点上，我不得不假设消息通过螺栓，但只是没有得到确认的方式回到喷口的时间？我需要设置一种方法来记录每条消息在系统中的传递。
所以这把我们带到了一块石头和一个坚硬的地方。我们有这么多悬而未决的原因，是因为我们有一个7或8层螺栓拓扑结构。当挂起的数量很低时，我们当然没有超时，但是螺栓没有在任何接近容量的地方运行，并且我们的吞吐量（消息/秒）不是很好。我们试着使螺栓平行，以便在容量计算中每个螺栓都相等。一旦我们达到了容量均衡（没有热点），我们就开始调整其他事情，其中一个调整措施就是增加tuple pending from the spout。其思想是，队列中的每一个螺栓总是得到消息；我们不希望bolt示例闲置，因为队列中没有它要做的事情。
对我们来说，问题不在于信息的顺序不对，而是事实上我们似乎没有任何形式的超时设置。如果我们这样做了，我们会把失败带回真正失败的地方。
有人知道为什么我们会遇到这些问题吗？我们能做些什么。。。好。。。没有经历过吗？除了没有超时。