我们最近将一个Nexus实例迁移到了AWS，并且在关闭大型文件上传时遇到了问题。我们怀疑这可能是由于这个宝石导致的ELB超时：
“如果HTTP请求未在空闲超时期限内完成，则负载均衡器会关闭连接，即使数据仍在传输中。”
来源：http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/config-idle-timeout.html
如果传输数据，连接如何空闲？为什么这样做？
有些文件是几千兆字节 - 上传可能需要几分钟，如果繁忙，可以说30分钟。我们应该怎么支持这个，将超时设置为1800s真的是推荐的修复？ （最多3,600）
谢谢， 乔尔
答案 0 :(得分：2)
这确实看起来确实是一个有趣的宝石。解释可能在于底层实现实际上有两个定时器，一个用于客户端，一个用于服务器。我推测，但如果没有这些内容，某些拒绝服务攻击可能更容易针对ELB及其背后的机器实施。
答案将在ELB访问日志中。如果你看到时间可疑接近60秒，你就有可能成为罪魁祸首。
增加计时器可能是一种选择。
通常情况下，似乎Web应用程序需要进出，完成并完成，在几毫秒内继续进行下一步。将进程或线程与长时间运行的内容捆绑起来就像上传一样意味着您可能已经能够处理数百或数千个其他请求，如果不是因为上载的资源占用。通过将文件上传到单独的环境或服务（例如S3，它可以接受POST上传，然后将浏览器重定向回您的成功＆＃34;可以更好地处理真正大文件的文件上传。上传完成后的页面）。其他策略可能包括智能客户端逻辑，可以部分地发送上传，也许并行发送，能够重新启动/重试并执行其他聪明的事情，如进度条。
我可能在$ {dayjob}部署了20到30个ELB部署，但这种情况从未出现过，但是我没有任何系统可以处理大型＆＃34;面向用户的文件。 A＆＃34;大＆＃34;我想到的这些系统的上传可能是16MB，所以绝对是一个不同的规模。
答案 1 :(得分：1)
是的，您的ELB超时默认值为60秒。解决方法是将ELB超时增加到足够高的值，以便上传失败（当前最大值：1小时）。该连接看起来很理想，因为请求未在超时期限内完成。