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.
Tunnels: Cleanup, catch more cases of zero-hop configuration
ClientAppConfig: Start i2ptunnel sooner
Since BuildRequestor won't use a zero-hop exploratory as a paired tunnel
for client builds, it's now safe to start client tunnels
before the expl. tunnels are ready. This will save up to 90 seconds.
The webpack* and cloudflare* certificates are for ssl.webpack.de and
cowpuncher.drollette.com, respectively. I'm removing the smartcom.org
certificate because it's unused.
please commit some updates for my reseed servers: Add new ssl-certs:
ieb9oopo.mooo.com2.crt --> certificates/ssl/
link.mx24.eu.crt --> certificates/ssl/
The first one is a new ssl-cert as exchange for the current one.
On http-server side the exchange will take place sometimes next year,
until then the current existing ieb9oopo.mooo.com.crt is still valid.
The second is a new reseed server from me.
Reseeder.java: Please add to DEFAULT_SSL_SEED_URL:
https://link.mx24.eu/
with this comment:
// Only HTTPS and SU3 (v3) support
Also the list can be cleaned up from these other dead servers:
ECDSA default for all new server tunnels
ECDSA default for streamr client tunnels
Fix display of server destination on edit page when not running (privkey file path wasn't absolute)
Fix display of persistent client key b32 on edit page when not running
Fix display of server sig type on edit page when we have a privkey file
Add KeysAndCert.getSigType()
Javadocs
- Fix SU3File support (tested)
- Finish implementation (untested)
- Output metadata as comments in news.xml
- Support signed HTML
- Copy router certs to news
Switch back to QueuedThreadPool (ticket #1395)
In Jetty 5/6, the default QTP was not concurrent, so we switched to
ThreadPoolExecutor with a fixed-size queue, a set maxThreads,
and a RejectedExecutionPolicy of CallerRuns.
Unfortunately, CallerRuns causes lockups in Jetty NIO.
In addition, no flavor of TPE gives us what QTP does:
- TPE direct handoff (which we were using) never queues.
This doesn't provide any burst management when maxThreads is reached.
CallerRuns was an attempt to work around that.
- TPE unbounded queue does not adjust the number of threads.
This doesn't provide automatic resource management.
- TPE bounded queue does not add threads until the queue is full.
This doesn't provide good responsiveness to even small bursts.
QTP adds threads as soon as the queue is non-empty.
QTP as of Jetty 7 uses concurrent.
QTP unbounded queue is the default in Jetty.
So switch back to QTP with a bounded queue, which does what we want,
which is first expand the thread pool, then start queueing, then reject.
ref:
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.htmlhttps://wiki.eclipse.org/Jetty/Howto/High_Load
