net.i2p.router.tunnel.pool
Class BuildExecutor
java.lang.Object
net.i2p.router.tunnel.pool.BuildExecutor
- All Implemented Interfaces:
- Runnable
class BuildExecutor
- extends Object
- implements Runnable
Single threaded controller of the tunnel creation process, spanning all tunnel pools.
Essentially, this loops across the pools, sees which want to build tunnels, and fires
off the necessary activities if the load allows. If nothing wants to build any tunnels,
it waits for a short period before looping again (or until it is told that something
changed, such as a tunnel failed, new client started up, or tunnel creation was aborted).
Note that 10 minute tunnel expiration is hardcoded in here.
Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
BuildExecutor
public BuildExecutor(RouterContext ctx,
TunnelPoolManager mgr)
run
public void run()
- Specified by:
run
in interface Runnable
isRunning
public boolean isRunning()
buildTunnel
void buildTunnel(TunnelPool pool,
PooledTunnelCreatorConfig cfg)
buildComplete
public void buildComplete(PooledTunnelCreatorConfig cfg,
TunnelPool pool)
wasRecentlyBuilding
public boolean wasRecentlyBuilding(long replyId)
buildSuccessful
public void buildSuccessful(PooledTunnelCreatorConfig cfg)
repoll
public void repoll()
removeFromBuilding
PooledTunnelCreatorConfig removeFromBuilding(long id)
- This returns the PTCC up to a minute after it 'expired', thus allowing us to
still use a tunnel if it was accepted, and to update peer stats.
This means that manager.buildComplete() could be called more than once, and
a build can be failed or successful after it was timed out,
which will affect the stats and profiles.
But that's ok. A peer that rejects slowly gets penalized twice, for example.
- Returns:
- ptcc or null
- Since:
- 0.7.12
getInboundBuildQueueSize
public int getInboundBuildQueueSize()