5:29 p.m.
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
![http://www.epicor.com/Style%20Library/Images/email/sig_values3.png]<ht...](http://www.epicor.com/Style%20Library/Images/email/sig_values3.png]%3Chttp://solutions.epicor.com/values/%3E){kind=link}
6:56 p.m.
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(a)epicor.com>
To: undertow-dev(a)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(a)epicor.com
This message has been scanned for malware by Websense. www.websense.com
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
1:13 p.m.
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@redhat.com]
Sent: Sunday, May 17, 2015 5:57 PM
To: Eric Peters
Cc: undertow-dev(a)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(a)epicor.com>
To: undertow-dev(a)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(a)epicor.com
This message has been scanned for malware by Websense.
www.websense.com
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
Click
https://www.mailcontrol.com/sr/AB3ppeXhgTbGX2PQPOmvUtXHXnVjuGgHwP!E8ROfG7...
to report this email as spam.
3506
days inactive
3509
days old
2 comments
2 participants
participants (2)
-
Eric Peters -
Stuart Douglas