Skip to main content

HttpServer's socket connection is not closed

3 replies [Last post]
evgeny4
Offline
Joined: 2006-06-28
Points: 0

I stumbled on a problem while trying to to run ME Framework tests in CLDC environment.
Here is some propersties from Script enviroment:
baseConfiguration = [CLDC]
client = [com.sun.cldc.communication.http.HttpClient, http://10.31.10.48:8080/test/, -verboseClient]
server = [com.sun.cldc.communication.http.HttpServer, verbose=true, http.url=http://10.31.10.48:8080/test/, useIPAddress=false]
command.testExecute = [com.sun.tck.cldc.javatest.CldcTCKCommand]
concurrency = [50]
command.jtOnly = [com.sun.javatest.lib.ExecStdTestSameJVMCmd]

CLDC HttpClient reads bytes from InputStream until EOF is reached (i.e. FIN send by HttpServer's socket), but this never happens, so HttpClient hangs at loop:
---
trace("Reading data..");
while((i=is.read())>=0)
baos.write(i);
---

After some review I found out that
---
out.close();
in.close();
conn.close();
conn.close(); // the second close is intentional
---
is executed each time HTTP request (http://.../test/getNextTest/test1.jar) is handled, but there's no FIN request registered by the sniffer.

What did I miss?
Thanks in advance.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vsizikov
Offline
Joined: 2004-11-16
Points: 0

Hi Evgeny,

Weird problem. Do you use emulator or how do you set things up to run in CLDC mode?

As for FIN not being sent, I think that's OK, in case if persistent HTTP connections are used. So, basically, the same TCP connection is being reused for multiple HTTP requests, transparent to the upper level code.

See
http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html
for more details.

evgeny4
Offline
Joined: 2006-06-28
Points: 0

I'm running it with OnRamp (JSR-242) stack, using phoneME revision: 8102. (JVM is ported to Set Top Box, i.e. with custom socket protocol implementation)

AMS is a simple self-made HTTP client for download jar-file from JT side and launch CldcAgent wrapped in Xlet like this:

String[] args = (String[])ctx.getXletProperty(XletContext.ARGS);
try {
CldcAgent baseAgent = new CldcAgent();
baseAgent.execute(args);
} catch (RuntimeException re) {
re.printStackTrace();
}

According to Sniffer (Wireshark) HTTP/1.0 request is sent by Client and HTTP/1.1 response received from JT server. Witch is weired.

Anyway after some tracing I found that com.sun.cldc.communication.http.HttpServer#RequestHandler calls close() every time, so looks like it doesn't support keep-alive http connection.

And no FIN send! Adding conn.finishOutput() to RequestHandler#run() has no effect either. Witch is very very strange.

Message was edited by: evgeny4

vsizikov
Offline
Joined: 2004-11-16
Points: 0

Hi Evgeny,

Strange problem indeed, and almost impossible for me to debug, since I don't have access to the SetTopBox and the custom VM with custom sockets. Most probably, that's where the problem is, there might be just a bug in sockets, for example.

We've been running ME Framework as part of many, many TCKs, and haven't seen such issues for years.

> Anyway after some tracing I found that
> com.sun.cldc.communication.http.HttpServer#RequestHandler calls close()
> every time, so looks like it doesn't support keep-alive http connection.

Actually, the keep-alive connections are totally transparent to client code,
so calling close() is OK.
Even more, for keep-alive to work effectively, the upper-level code should
actually be very careful and use close() extensively for every connection.

The VM/implementation itself would have a pool of connections to use,
but for the client code it's as if every time completely new connection is
created and used.

For some implementations, there are command line switches or properties
to turn that support off and on, but I'm not sure in your case.

Thanks,
--Vladimir