J2ME Persistent HttpConnection

Question

抱歉，这是一个文件..

旧设置

我有一个J2ME客户端应用程序，它以3秒的间隔连接到服务器。连接在单独的线程中处理。该线程在while循环中运行，其操作如下：

1. 打开HTTP连接
2. 接收响应＆amp;发送到主UI线程进行处理
3. 睡3秒钟 重复

服务器是Apache，KeepAlive已关闭。来自客户端的HTTP请求的超时时间为10秒。每个循环大约需要4.5秒（总延迟为1.5秒）。

经常（每1或2小时一次），在低覆盖率（差的3G / GPRS信号）下，线程接收IO块并在上面的步骤1挂起。我认为正在发生的事情是线路上某处的连接已经死亡，但应用程序并不知道它并且正在等待响应。我认为网络（在这种情况下是O2）应该受到指责。连接保持活动大约30分钟，最终死亡并返回-1响应长度到应用程序，线程最终继续。为了解决这个相对罕见的问题，如果响应时间超过60秒，我就放弃了线程，并创建了一个新线程。

直到最近，这不是一个主要问题，但我们更改了网络设置如下：

---

新设置

1. 由于带宽限制较低，我们将间隔减慢到5 秒。
2. 我们现在通过SSL隧道将所有连接路由到我们的服务器。
3. 来自客户端的HTTP请求在App *
上的超时时间仍为10秒

循环花费大约7.5秒（总延迟2.5秒）来完成这些更改。延迟增加的原因是每个单个连接需要SSL上的握手（由于KeepAlive关闭）。我们被建议在apache服务器上切换KeepAlive，这意味着一次握手，然后是后续请求的持久http连接。我们这样做了，并且在很大程度上它大大提高了连接速度。循环时间缩短到6.5秒。

因此我们现在可以将其添加到新设置的配置更改中：

1. 服务器上的HTTP KeepAlive已切换为ON（以启用持久性TCP连接）

然而，在较差的3G / GPRS领域，线程阻塞问题更加频繁并且已经成为一个主要问题 - 在真正糟糕的覆盖范围内，它的发生率高达50％。我收到一个Java内存不足异常几次告诉我应用程序无法分叉一个新线程..此外，在良好的3G领域我们也看到这个线程阻塞问题现在没有发生过。

我在这个设置中明显做错了，因为持久的http连接和底层TCP非常可靠

*我们在没有重新编写应用程序的情况下管理了所有这些更改，但是10秒的http超时将需要重新编写应用程序。也许这个超时导致问题？

提前感谢您提供任何帮助。

Answer 1

如果有人有类似的问题，KeepAliveTimeout在这里是关键。它设置为5秒，使KeepAlive无用。

我已将它增加到30秒，这有效地创建了持久连接，而且应用程序现在正在飞行。