当客户端使用readTimeout关闭连接时,服务器上会发生什么

nik*_*iks 8 java sockets tomcat http java-ee

当客户端通过使用readTimeout关闭与API的连接时,服务器上会发生什么.请求的执行将完成,否则一旦发生超时就会中断或执行将完成,响应流被响应服务器阻塞应该发送给用户

use*_*421 7

当客户端使用 readTimeout 关闭与 API 的连接时,服务器会发生什么。

与客户端因任何其他原因关闭时发生的情况相同。服务器将继续执行请求,将成功写入响应的第一部分,并且在写入其余部分时可能会出现“连接重置”错误,如果有休息,取决于时间和响应时间等.

请求的执行是否会完成

是的。

否则它会在超时发生时立即中断

不。

或者执行将完成

是的。

并且响应流被服务器应该发送给用户的响应阻塞

是的,但这最终会导致服务器上的“连接重置”。


Jir*_*sek 5

超时是关闭连接的不整洁方法-当连接的一侧超时时,很有可能您无法告诉另一端您超时并正在关闭连接。就是说,没有通过双方的协调行动正式关闭连接,而只是一侧决定将其视为无效。

解决方法是在连接的两边都有超时-如果一侧超时,另一侧最终也会超时。


至于在服务器端发生的确切情况:由于服务器直到其自己的超时到期才知道连接已死,因此它将认为连接良好,并且通常会处理请求并尝试写入响应。响应中可能会有一些缓冲,因此尝试将响应写入服务器似乎也可以工作。

当服务器尝试将足够的数据写入响应以填充可能的缓冲区时,它将阻塞,然后在发生超时时引发异常,最后让服务器知道连接超时。

如果服务器未使用其响应填充缓冲区,则在尝试关闭连接时会发生相同的事件(阻塞,然后发生异常)(但这可能已经发生在应用程序外部,在应用程序服务器容器代码中)。

如果在超时发生后您最终有机会尝试编写响应,则应立即获得异常。

因此,服务器上发生的具体情况很大程度上取决于您自己的代码:

  • 如果仅在执行所有关联的操作后才写响应,则将执行它们
  • 如果您混合使用业务逻辑和编写响应,则某些逻辑可能会执行,也可能不会执行(取决于已向响应中写入了多少数据以及在什么时间),并且没有很好的方法来估计会发生什么

无论哪种方式,服务器最终都会知道发生了超时,但是我不确定您的应用程序将始终获得此信息。