First, great job getting a fix in for UNDERTOW-413 very promptly.
I saw that release 1.1.4-Final was finally cut, and pulled it off Maven into our dev
system last night... and I'm still seeing the leak.
Verified my test setup, it is on undertow-1.1.4-Final - jars for 1.1.0-Final were
deleted.
It may be a week before I can definitively say if it's improved at all or not, but it
is definitely still leaking. I've not yet identified a trigger for the leak, so I
don't have a good view on how serious it still is (that's my next task here).
As the fix in undertow-1.1.4-Final didn't solve this, I fear you may need an example I
don't have to provide. I'm going to need a fix soon.
Ultimately I'm thinking of taking
io.undertow.conduits.ReadTimeoutStreamSourceConduit.timeoutCommand, making it a named
static inner class with a phantom reference to the conduit, which triggers handle.remove()
when the conduit is GCd. I'm not fond of using the GC as part of a queue cleanup
mechanic, but I don't know the undertow package well enough to try anything more
sophisticated.
Before I get to trying that, I'm open to suggestions/advice.
Eric Peters
Software Engineer
www.epicor.com<http://epicor.com/>
Tel.: (303) 323-8250
Fax: (512) 356-0833
E-Mail: EPeters@epicor.com<mailto:EPeters@epicor.com>
[Description: Description:
http://www.epicor.com/Style%20Library/Images/email/Epicoremail.gif]
[Description: Description:
http://www.epicor.com/Style%20Library/Images/email/sig_values3.png]<ht...
This message has been scanned for malware by Websense.
www.websense.com