I'm looking at what it will take to either get the fix for UNDERTOW-413 into our server setup, or to substantially reduce the memory it's leaving allocated. We use Wildfly 8.2.0 and back-of-the envelope math, extrapolating from where we've seen the problem, yields that our larger production servers would want both the minimum usable timeouts (10 minutes) plus an additional 8GB memory to stand a 'fair chance' of not running out of memory.
'Fair chance it'll be OK' is not something I want to be selling to management.
Can this fix be easily pulled into Wildfly 8.2.0-Final? Would it be better for us to apply the patch by hand to the version of undertow in Wildfly 8.2.0? Can we mitigate this in some simple way? Is this fix already in a ready-to-download copy of Wildfly?
I'm looking for a path forward here so that we can have a sound solution for production systems, preferably one that does not include tripling the memory footprint of Wildfly, or depend on Beta or bleeding-edge releases.
The fix to this issue seems straightforward UNDERTOW-413 make sure timeout handles are removed when a conduit is clo... · undertow-io/undertow@050dcf1 · GitHub in terms of patching it, but I would recommend that you ask this question in the undertow-dev list undertow-dev Info Page so that swd847 or someone else can tell you for sure.