r1731030 and 1731035 release timeline

[Peter Robbins <pe...@jamfsoftware.com>]

Hi there,

I’ve run into the WebappClassLoader jar scanning memory leak resolved by r1731030 and r1731035 in Tomcat 7 trunk. It appears those changes made it separately into both 8.0.36 and 8.5.3, but are missing from 7.0.69 and 7.0.70. Any idea on the timeline of when those would be released in 7.x?

Thanks,
Peter

Re: r1731030 and 1731035 release timeline

[Peter Robbins <pe...@jamfsoftware.com>]

Thanks, I’ll see if we can just move to 8.5.x. Seems like that’ll be better long-term by a good margin.

Peter

On 6/20/16, 7:35 AM, "Mark Thomas" <ma...@apache.org> wrote:

On 16/06/2016 20:37, Peter Robbins wrote:
> Hi there,
> 
> I’ve run into the WebappClassLoader jar scanning memory leak resolved
> by r1731030 and r1731035 in Tomcat 7 trunk. It appears those changes
> made it separately into both 8.0.36 and 8.5.3, but are missing from
> 7.0.69 and 7.0.70. Any idea on the timeline of when those would be
> released in 7.x?

For the benefit of the archives, this is not a leak. There is increased
memory usage but that usage is a) bounded and b) released when the
application is unloaded.

The current 7.0.x implementation loads the binary content for every
class into memory as part of the scanning process. As classes are
loaded, the binary content is dropped and the newly created class added.

For applications that use most of the classes they ship with, the result
is a rapid step in the memory requirements when the application starts
rather than a gradual rise over time and the end result marginally
increased memory usage.

For applications that use few of the classes they ship with, the result
is also a rapid step in the memory requirements when the application
starts rather than a gradual rise over time but the end result is
significantly increased memory usage.

I've reviewed the code and the changes in r1731030 and r1731035 are
heavily dependent on the WebResources refactoring that took place for
8.0.x and is not present in 7.0.x. This makes implementing a fix for
this issue significantly more difficult in 7.0.x. Given the general
fragility of resource loading in 7.0.x (itself a significant factor in
introducing the WebResources refactoring) I'm currently leaning more
towards recommending workarounds for this issue rather than implementing
code fixes.

Those workarounds boil down to minimising the number of JARs scanned and
are covered in the JAR scanning section of [1].

I plan to spend some more time looking at options for fixing this in the
code, but my recommendation would be to look at an upgrade to 8.5.x or
to minimise the amount of JAR scanning performed if this is an issue for
you.

Mark

[1] http://wiki.apache.org/tomcat/HowTo/FasterStartUp

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: r1731030 and 1731035 release timeline

[Mark Thomas <ma...@apache.org>]

On 16/06/2016 20:37, Peter Robbins wrote:
> Hi there,
> 
> I\u2019ve run into the WebappClassLoader jar scanning memory leak resolved
> by r1731030 and r1731035 in Tomcat 7 trunk. It appears those changes
> made it separately into both 8.0.36 and 8.5.3, but are missing from
> 7.0.69 and 7.0.70. Any idea on the timeline of when those would be
> released in 7.x?

For the benefit of the archives, this is not a leak. There is increased
memory usage but that usage is a) bounded and b) released when the
application is unloaded.

The current 7.0.x implementation loads the binary content for every
class into memory as part of the scanning process. As classes are
loaded, the binary content is dropped and the newly created class added.

For applications that use most of the classes they ship with, the result
is a rapid step in the memory requirements when the application starts
rather than a gradual rise over time and the end result marginally
increased memory usage.

For applications that use few of the classes they ship with, the result
is also a rapid step in the memory requirements when the application
starts rather than a gradual rise over time but the end result is
significantly increased memory usage.

I've reviewed the code and the changes in r1731030 and r1731035 are
heavily dependent on the WebResources refactoring that took place for
8.0.x and is not present in 7.0.x. This makes implementing a fix for
this issue significantly more difficult in 7.0.x. Given the general
fragility of resource loading in 7.0.x (itself a significant factor in
introducing the WebResources refactoring) I'm currently leaning more
towards recommending workarounds for this issue rather than implementing
code fixes.

Those workarounds boil down to minimising the number of JARs scanned and
are covered in the JAR scanning section of [1].

I plan to spend some more time looking at options for fixing this in the
code, but my recommendation would be to look at an upgrade to 8.5.x or
to minimise the amount of JAR scanning performed if this is an issue for
you.

Mark

[1] http://wiki.apache.org/tomcat/HowTo/FasterStartUp

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org