对不起，这是沿着一个记录..J2ME持久性的HttpConnection
OLD SETUP
我有以3秒的间隔连接到服务器J2ME客户机应用程序。连接在一个单独的线程中处理。线程在while循环运行，可执行如下：
- 打开HTTP连接
- 接收响应&发送到主UI线程用于处理
- 睡眠3秒
重复
服务器是Apache并且KeepAlive关闭。来自客户端的HTTP请求具有10秒的超时。每个循环需要大约4.5秒（总共1.5秒的延迟）。
每隔一段时间（每1或2小时一次），在低覆盖率（较差的3G/GPRS信号）下，线程收到一个IO块并在上面的第1步中挂起。我认为正在发生的事情是线路某处的连接已经死亡，但该应用程序不知道它并正在等待响应。网络（在这种情况下O2）是我想的责任。连接保持活动状态大概30分钟，最终死亡，并返回-1响应长度的应用程序和线程最终继续。为了解决这个相对罕见的问题，我简单地放弃了线程，如果响应时间超过60秒，并创建一个新的。
直到最近，这不是一个大问题，但是我们改变了我们的网络设置如下：
新格局
- 由于较低带宽的限制，我们放慢了间隔到5 秒。
- 我们现在通过SSL隧道将所有连接路由到我们的服务器。从客户端
- HTTP请求仍然具有10秒的超时在App *
回路正在采取约7.5秒（2.5秒总等待时间）这些变化来完成。延迟增加的原因是每次连接都需要SSL握手（由于KeepAlive关闭）。我们被建议在apache服务器上开启KeepAlive ON，这意味着一次握手，然后持续的http连接以供后续请求使用。我们这样做了，而且大部分它已经大大提高了连接速度。循环下降到6.5秒。
所以我们现在可以将它添加到我们的配置修改为新设置：
- HTTP保持活动被切换到服务器上（以便能够持久TCP连接）
然而在3G/GPRS较差的地区，线程阻塞问题更为频繁，已成为一个主要问题 - 在真正差的覆盖范围内，发生多达50％的时间。我几次收到一个Java内存异常，告诉我该应用程序无法分叉一个新线程。另外，在良好的3G领域，我们也看到了现在这种线程阻塞问题，这在以前没有发生过。
我已经清楚地做错了这种设置，为持续性HTTP连接和基本TCP是相当可靠的
*我们管理的所有这些改变没有一个应用程序重新编写，但10秒的HTTP超时会需要重新编写应用程序。也许这个超时正在导致这个问题？
预先感谢在此的任何援助。