[undertow-dev] Buffers still leaking via lingering timeouts

[Eric Peters]

We use EJBs and servlets.

The buffers for leaked connections show bits of both Ajax and Faces, but I've so far been unable to chase them back to a source (I need to go looking for a URL...). The buffers are fairly empty of helpful content - mostly tables with generated IDs I don't recognize, causing me to think they don't come from the Ajax pages that I help maintain.

I'm not aware of us using any native code for JBoss,
We do have a mix of modules, but not all of them are actively maintained.  A quick search didn't turn up the native keyword.  

For Async IO, I'm familiar with it as a concept, but I also see it's a discrete module.  As a concept I've never seen where we applied it to transactions, but it's at least possible it sees use.  As for Async IO the module, the same answer applies.  I have never seen it used, but can't vouch that we don't use it.

If it helps, we migrated up from JBoss 7 with minimal changes to our configuration, primarily looking to get some of the benefits from Undertow / nio.  The module I'm most concerned about would have been written largely on JBoss 7, and will likely have limited interaction with a database inside JBoss.  This module makes heavy use of Servlets. 
//EricP

-----Original Message-----
From: Stuart Douglas [mailto:sdouglas at redhat.com] 
Sent: Sunday, May 17, 2015 5:57 PM
To: Eric Peters
Cc: undertow-dev at lists.jboss.org
Subject: Re: [undertow-dev] Buffers still leaking via lingering timeouts

Can you provide some more details about what your app is doing? In particular are you using Servlet, or the native API, and are you using async IO?

Stuart

----- Original Message -----
> From: "Eric Peters" <epeters at epicor.com>
> To: undertow-dev at lists.jboss.org
> Sent: Saturday, 16 May, 2015 8:29:12 AM
> Subject: [undertow-dev] Buffers still leaking via lingering timeouts
> 
> 
> 
> 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
> Tel.: (303) 323-8250
> Fax: (512) 356-0833
> E-Mail: EPeters at epicor.com
> 
> 
> 
> 
> 
> 
> 
> 
> This message has been scanned for malware by Websense. 
> www.websense.com
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


Click https://www.mailcontrol.com/sr/AB3ppeXhgTbGX2PQPOmvUtXHXnVjuGgHwP!E8ROfG7PiKsRj+ko0fwGeKVAi1nvVqIuoMyLSsnSGoJj9+I0bOg==  to report this email as spam.