i2ptunnel:
- Better timeout handling when reading headers in HTTP server (improved fix for ticket #723)
Enforce total header timeout with new readLine()
- Prep for returning specific HTTP errors to client on request timeout and header errors,
instead of just closing socket... further work to be in i2p.i2p.zzz.test2 branch
Streaming:
- Fix read timeout on input stream - was waiting too long, often twice as long as timeout, or more
Enforce total timeout even when notify()ed
- Fix read() returning 0 on read timeout instead of -1 (possible fix for ticket #335)
This prevents passing partial headers to server on timeout
- Fix javadocs for read timeout to match current behavior
- Fix StandardSocket SoTimeout to account for differences with I2PSocket readTimeout
- log tweaks
transparently, to support HTTPS over the same tunnel,
when so configured.
Jetty: Add extensive help to jetty-ssl.xml for setting
up SSL on the same server.
with a Writer or getBytes("UTF-8") for efficiency and to
avoid encoding issues.
Store strings as strings, not bytes.
Catch IOEs to prevent cascading error pages.
Minor cleanups
Big savings is on client side (two less threads per connection)
- Move client pool from static inI2PTunnelClientBase to TCG.
- Use client pool for some server threads
- Run some things inline that were formerly threads
- Client-side I2PTunnelRunner thread used to do nothing but start 2 more
threads; now it runs one inline (like we do for server-side HTTP)
- Javadocs and cleanups
Was originally intended to reduce load for high-traffic servers
but most of the savings for now is on the client side.
Ref: http://zzz.i2p/topics/1741
Todo: Figure out how to run the HTTP client-side gunzipper inline too
Todo: More server-side improvements
---
Client side:
before:
4-5 threads, 1-2 pooled
I2PTunnel Client Runner (BlockingRunner from client pool)
starts I2PTunnelRunner or I2PTunnelHTTPClientRunner and exits
starts StreamForwarder toI2P and waits
starts StreamForwarder fromI2P and waits
starts HTTPResponseOutputStream (HTTP gunzip only) (from client pool)
now:
2-3 threads, 1-2 pooled
I2PTunnel Client Runner (BlockingRunner from client pool)
runs I2PTunnelRunner or I2PTunnelHTTPClientRunner inline
starts StreamForwarder toI2P and waits
runs StreamForwarder fromI2P inline
starts HTTPResponseOutputStream (HTTP gunzip only) (from client pool)
---
Server side:
before:
1-4 threads, 0-1 pooled
Server Handler Pool (Handler from server pool) execpt for standard server, blockingHandle() inline in acceptor
starts I2PTunnelRunner or CompressedRequestor and exits
starts StreamForwarder toI2P and waits (inline for HTTP)
starts StreamForwarder fromI2P and waits (except not for HTTP GET)
now:
1-4 threads, 0-2 pooled
Server Handler Pool (Handler from server pool) execpt for standard server, blockingHandle() inline in acceptor
starts I2PTunnelRunner or CompressedRequestor and exits (using client pool)
starts StreamForwarder toI2P and waits (inline for HTTP)
starts StreamForwarder fromI2P and waits (except not for HTTP GET)
