J2ME 持久 HttpConnection

发布于 2024-12-25 23:25:00 字数 1335 浏览 2 评论 0原文

抱歉，这是一个要记录的内容。

旧设置

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

打开 HTTP 连接
接收响应并执行以下操作：发送到Main UI Thread进行处理
Sleep 3 秒
重复

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

每隔一段时间（每 1 或 2 小时一次），在低覆盖范围（3G/GPRS 信号差）下，线程会收到 IO 块并在上面的步骤 1 处挂起。我认为发生的情况是沿线某处的连接已断开，但应用程序不知道这一点并正在等待响应。我认为应该归咎于网络（在本例中为 O2）。连接保持活动状态大约 30 分钟，最终终止并向应用程序返回 -1 响应长度，线程最终继续。为了解决这个相对罕见的问题，如果响应时间超过 60 秒，我就会放弃该线程，并创建一个新线程。

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

新设置

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

循环需要大约 7.5 秒（总延迟 2.5 秒）才能完成这些更改。延迟增加的原因是每个连接都需要通过 SSL 进行握手（由于 KeepAlive 关闭）。建议我们在 apache 服务器上将 KeepAlive 打开，这意味着一次握手，然后为后续请求建立持久的 http 连接。我们这样做了，并且在很大程度上它大大提高了连接速度。循环时间缩短至 6.5 秒。

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

HTTP KeepAlive 在服务器上切换为 ON（以启用持久 TCP 连接）

但是，在较差的 3G/GPRS 区域，线程阻塞问题更加频繁并已成为一个主要问题 - 在覆盖范围极差的地区，这种情况发生的概率高达 50%。我曾多次收到 Java 内存不足异常，告诉我应用程序无法分叉新线程。此外，在良好的 3G 区域中，我们现在还看到了此线程阻塞问题，这是以前从未发生过的。

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

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

预先感谢您对此提供的任何帮助。

原文

Sorry, this is along one to document..

OLD SETUP

I have a J2ME client app which connects to a server at 3 second intervals. The connections are handled in a separate thread. The thread runs in a while loop and does as follows:

Open HTTP Connection
Receive Response & send to Main UI Thread for processing
Sleep for 3 seconds
Repeat

Server is Apache and KeepAlive is off. HTTP Requests from the client have a Timeout of 10 seconds. Each loop takes about 4.5 seconds (1.5 seconds total latency).

Every so often (once every 1 or 2 hours), under low coverage (poor 3G/GPRS signal) the thread receives an IO block and hangs at step 1 above. I think what is happening is the connection somewhere along the line has died, but the app does not know it and is waiting for a response. The network (O2 in this case) is to blame I think. The connection stays alive for maybe 30 minutes and eventually dies and returns -1 response length to the app and the thread eventually continues. To combat this relatively rare issue I simply abandoned the thread if the response took longer than 60 seconds, and created a new one.

Up until recently this was not a major issue, however we changed our network setup as follows:

NEW SETUP

Due to lower bandwidth restrictions we slowed down the interval to 5
seconds.
We now route all connections through an SSL Tunnel to our server.
HTTP requests from the client still have a timeout of 10 seconds on App*

The loop was taking about 7.5 seconds (2.5 seconds total latency) to complete with these changes. The reason the latency increased was the handshake over SSL was required for each single connection (due to KeepAlive off). We were advised to switch KeepAlive ON on the apache server which would mean one handshake and then a persistent http connection for subsequent requests. We did this, and for the most part it has considerably improved the connection speed. The loop is down to 6.5 seconds.

So we can now add this to our config changes for the new setup:

HTTP KeepAlive was switched to ON on the server (to enable to the persistent TCP connection)

However, in poor 3G/GPRS areas, the thread blocking issue is much more frequent and has become a major issue - it happens as much as 50% of the time in really poor coverage areas. I have received a Java out of memory exception a few times telling me the app could not fork a new thread.. In addition, in good 3G areas we also see this thread blocking issue now which had not happened before.

I have clearly done something wrong in this setup, as persistent http connections and the underlying TCP is quite reliable

*We managed all these changes without an app re-write, but the http timeout of 10 seconds will require an app re-write. Perhaps this timeout is causing the issue?

Thanks in advance for any assistance in this.

分享到QQ

分享到微博