Move some data structures away from ByteArray; offsets were always zero
- New BuildRequestRecord constructors
- BuildRequestRecord field becomes final byte[222]
- IV becomes byte[16]
- Build record becomes EncryptedBuildRecord
Remove extra copy in BuildRequestRecord.encryptRecord()
Remove unused BuildRequestRecord.readOurIdentityMatches()
- Fix bug that left server acceptor thread running after close
- Add destroy() methods to release all resources when closing a tunnel for good,
particularly the streaming timer threads
- Use COWAL to prevent concurrency problems
- Javadocs
Streaming:
- Don't return null from accept() any more; actually throw
ConnectException as the javadocs have always specified
- Throw ConnectException from accept() if interrupted; previously caught and ignored
- Throw exceptions from ConnectionHandler.accept(), not higher up
- Close ServerSocket when ConnectionManager is shut down
- Synchronize setActive(), clear queue when starting to accept,
better handling of calls that don't change state
- Javadocs
ConfigClientsHelper: Call isPluginRunning() less often
PluginStarter: Simplify detection of active threads
Above changes mostly in support of zzzot plugin implementing ClientApp
and being able to shut down completely so there are no threads
in its thread group, so /configclients will all show status as stopped.
Previously, the I2PTunnelServer acceptor thread and
one or more streaming timer threads would remain.
Full acks were included in the bitfield portion, which
ran over and appeared to be fragments.
Also clean up setting bytes with initial data, for clarity.
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
