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
- Better handling of unsupported encryption in destinations
- Implement handling of unsupported encryption in router identities
- Banlist forever all RIs with unsupported encryption
- New negative cache of all dests with unsupported encryption
- New methods for destination lookup that will succeed even if
the LS is expired or encryption is unsupported
- Use new dest lookup so client will get the right error code
later, rather than failing with no LS when we really got it
but just couldn't verify it.
- Cleanups and javadocs
OCMOSJ: Detect unsupported encryption on dest and return the correct failure code
through I2CP to streaming to i2ptunnel
Streaming: Re-enable message status override, but treat LS lookup failure
as a soft failure for now.
HTTP Client: Add error page for unsupported encryption
- Windows: x86 and x64 versions self-compiled with VS2010 in
Windows 7. The icon has been changed from Tanuki's default to Itoopie.
- Linux ARMv6: Compiled on a RaspberryPi using gcc 4.6.3-14+rpi1,
Oracle Java 1.7.0+update40 and stripped
- All other binaries are from the "community edition" deltapack offered by
Tanuki.
- This came from the script from Tanuki but it does return useful information
(as far as its use in the script) in my testing. uname -m is better for our
needs. (The problem is only seen on certain CPUs when *all* available wrapper
binaries are present and the script tries to resolve the correct binary to use..
