The ConnectorTimerProxy is used to lazily initialize a Timer object. There once was an issue where usage of this proxy caused the proxied timer thread to be bound to the WebApp's ClassLoader, thus preventing it from being discarded when undeploying the application (see
Unfortunately, there is another way to create a memory leak: ConnectorTimerProxy extends java.util.Timer and thus it has a TimerThread of its own that's never used since all methods delegate to the proxy timer.
BUT this means that the very first call to getProxy() will create a TimerThread that inherits the calling thread's context class loader and it seems I just came across this case.
Since the ConnectorTimerProxy's own TimerThread is not used at all, I'd suggest to add a call to super.cancel() in the constructor.