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
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
From: Stuart Douglas [mailto:firstname.lastname@example.org]
Sent: Sunday, May 17, 2015 5:57 PM
To: Eric Peters
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?
----- Original Message -----
From: "Eric Peters" <epeters(a)epicor.com>
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
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.
Tel.: (303) 323-8250
Fax: (512) 356-0833
This message has been scanned for malware by Websense.
undertow-dev mailing list
to report this email as spam.