Java REST的正确心跳/保持活力的技术/层是什么？HTTP？TCP？编码：分块？

Question

设置：

有时London04实际上需要超过10秒（比方说2分钟）才能执行。有时它会不优雅地崩溃。有时会发生其他（网络）问题。有时在这2分钟内，response-xml-data的各个部分被逐渐填充，以至于各个部分之间没有10秒的间隔，因此从来不会超过readTimeout，有时有10多秒的间隔，HttpClient超时...

我们可以尝试增加主端的超时，但这会很容易使侦听器池膨胀/过载（仅仅是常规的通信量，甚至还没有被DDOSed）。我们需要一种方法来区分internal-site-stily-working-on-generating-the-response和它真的崩溃/network_lost/etc的情况。在交流过程中，最好的感觉是心跳（每5秒一次）。

我们以为Keep-Alive可以拯救我们，但它似乎只保护请求之间的空隙（而不是请求期间），而且它似乎在空隙期间不做任何心跳（只是having/waiting_for timeout）。

问题：

如果我们假设keepalive/chunkedencoding不能帮助我们实现keptalive/hearbeat/fastdetectionofdeadbackend，那么：

1）这样的心跳应该在哪一层实现？HTTP？TCP？

• https://en.wikipedia.org/wiki/keepalive
• http://tldp.org/howto/tcp-keepalive-howto/usingkeepalive.html
• 套接字心跳vs keepalive
• WebSockets ping/pong，为什么TCP不保持活动？

但根据这些，我必须设置如下内容：

• tcp_keepalive_time=5
• tcp_keepalive_intvl=1
• tcp_keepalive_probes=3

Answer 1

我的建议是不要用心跳。让面向外部的API返回一个303 See other，其头部指示何时何地可能有所需的响应。

因此您可以调用：

POST https://public.api/my/call

然后回去

303 See Other
Location: "https://public.api/my/call/results"
Retry-After: 10

如果您的服务器能够猜测生成一个响应需要多长时间，那么它应该将此因素考虑到retry-after值中。如果稍后对新位置进行了Get调用，但生成结果尚未完成，则返回一个带有更新的Retry-After值的响应。因此，您可能尝试10，如果不起作用，则告诉客户机再等待一次110，总共需要两分钟。

或者，使用一个被设计成能够长时间打开的协议，比如WebSockets。