Re: [Paperclips-discuss] Http performance

[Nic Ferrier]

>>> "Christopher K. St. John" <address@hidden> 26-Jun-01
6:04:17 AM >>>

   Tsk tsk, response first-line in one packet, headers
   and body in another. But that's legal. What's bad
   is that sure enough, httperf is FIN'ing, but pclips
   isn't FIN'ing back.

Not Paperclips fault, it just sends through the socket's stream.


  - Which brings us to HTTPInStream. timeout() is a
   very scary method. This is where I'm not 100% sure,
   but from the api docs, available() is free to return
   0 even when the stream is closed. And sleeping for
   100ms during a read is just plain evil.
   - If you really gotta time out during a read, then
   the only way to do it is Socket.setSoTimeout(). It's
   guaranteed to work cross-platform, the call has been
   available since 1.1.*, and it's not weird (== people
   will 'get it' when they see the code)

Yes, this should be part of the socket server though. I have been
meaning to do it for some time but never got round to it.

As I recall, Kaffe had some problems with socket timeouts and so I
used the current system instead. I'm fairly sure those problems have
been fixed. Also I think the Socket stream stuff in Kaffe was
asynchronous to the extent I needed it to be.


  - What to do? setSoTimeout probably fits into the 
  current code better than a reaper thread, so put
  that in, take HTTPInStream.timeout() out.
  - Which I did. Well, I didn't put in a setSoTimeout,
  but I commented out timeout() and it worked. Sort
  of. Still random pauses, some quite long, but it
  didn't every (quite) fully hang. Not sure why.

Any ideas about how the timeout should be set in Server.java?


Nic