You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Mark Lybarger <Ma...@CBC-Companies.com> on 2004/07/28 19:59:02 UTC
RE: velocity leaking memory... was: AW: AW: How to export tdk applications to struts?
Could you expand a bit on the "Velocity is leaking memory like a sieve" comment? Ya got my ears all tuned in now.
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Tuesday, July 27, 2004 3:25 AM
> To: turbine-user@jakarta.apache.org
> Subject: Re: AW: AW: How to export tdk applications to struts?
>
>
> "tobias rademacher" <to...@innowake.de> writes:
>
> >> You can use velocity with struts. See the velocity-tools project,
> >> particularly VelocityStruts.
> >>
> >> http://jakarta.apache.org/velocity/tools/struts/
> >>
> >> Robert
>
> >Cool to hear that.
> >Velocity seems to be interegrated in a large amount of MVC
> Framworks.... :-)
>
> Because it is the best of the ugly. =:-O
>
> Basically, Velocity is leaking memory like a sieve, its application
> side configuration is obscure (take a look at VelocityService), its
> logging non existant and actively hampered by insisting on
> re-inventing commons-logging and the Template Language is
> "non-consistent" at best. And try to include and parse templates in a
> loop. I've never seen again a gigabyte of memory gobbled up so
> fast.
>
> However, it's the best free product around, it is well accepted as
> part of the ASF world and (best!) it is not jealously guarded by
> obnoxious developers who prefer to flame their users instead of
> helping them.
>
> That's why it is our default view engine and we're damn proud of
> it. :-)
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development --
> hero for hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> "Fighting for one's political stand is an honorable action, but re-
> fusing to acknowledge that there might be weaknesses in one's
> position - in order to identify them so that they can be remedied -
> is a large enough problem with the Open Source movement that it
> deserves to be on this list of the top five problems."
> -- Michelle Levesque, "Fundamental Issues with
> Open Source Software Development"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: velocity leaking memory... was: AW: AW: How to export tdk applications to struts?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Mark Lybarger" <Ma...@CBC-Companies.com> writes:
Depending on the version of Velocity. 1.3.1 seems to be quite stable to
me. From the release notes of 1.4, you will find:
--- cut ---
Enhanced the implementation of ResourceCacheImpl using Jakarta Commons
Collections LRUMap class. The previous greedy implementation did not
set an upper bound for the cache size, meaning that cached resources
were never relinquished (a possible memory leak). You can continue to
use that behavior by setting the resource.manager.cache.size for your
cache to less than 1. (dlr)
--- cut ---
Which is one behaviour that I have observed. Another way is running the
Torque SQL data export task on a large database because of this:
If you look at
http://jakarta.apache.org/velocity/developer-guide.html, you will find
the "Other context issues" paragraph. It hints at "you might want to
turn caching on". Velocity introspects the same thing over and over
again, slowly accumulating memory.
This might be expected behaviour from the developers but from an users
point of view, it is indistinguishable from a memory leak.
In the end (which is important for us, as we are Velocity _users_),
this boils down to:
- For the "regular case" (parsing a template, evaluating a few objects and
loops), Velocity is fine.
- If you do complex things like #parse(""), you should be sure that Velocity
template caching is activate (caching _saves_ memory in this case. ;-) )
If you do
#foreach ($i in $reallyLargeArray)
#foreach ($j in $anotherReallyLargeArray)
#parse("MyFunnyTemplate.vm")
#end
#end
you should be really, really, really sure that caching is on.
- If you do really complex things (like e.g. generating 27 MByte XML files
from Velocity for FOP rendering...), you might want to build your own
context which you have under direct control.
One of the "configuring is obscure" issue that I have with Velocity
is, that it is not really integrating into an application. You have no
control over its caches, you can't get information from Velocity about
memory usage, you can't "flush" its caches and so on. In the end, you
init() it and throw templates to render at it and hope for the best.
So far, it hasn't really disappointed me yet. Just some "D-oh!"
situations.
As I said, I tend to consider 1.4 much less stable than 1.3.1.
I was not able to run maven torque:data-sql on a moderately large
(1.5 million datasets in ~80 tables) database. 2 Gig memory were not
enough. This works fine with 1.3.1 (takes about 25 Meg...). torque:data-sql
has the double loop with parse described above at its core...
Regards
Henning
>Could you expand a bit on the "Velocity is leaking memory like a sieve" comment? Ya got my ears all tuned in now.
>> -----Original Message-----
>> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
>> Sent: Tuesday, July 27, 2004 3:25 AM
>> To: turbine-user@jakarta.apache.org
>> Subject: Re: AW: AW: How to export tdk applications to struts?
>>
>>
>> "tobias rademacher" <to...@innowake.de> writes:
>>
>> >> You can use velocity with struts. See the velocity-tools project,
>> >> particularly VelocityStruts.
>> >>
>> >> http://jakarta.apache.org/velocity/tools/struts/
>> >>
>> >> Robert
>>
>> >Cool to hear that.
>> >Velocity seems to be interegrated in a large amount of MVC
>> Framworks.... :-)
>>
>> Because it is the best of the ugly. =:-O
>>
>> Basically, Velocity is leaking memory like a sieve, its application
>> side configuration is obscure (take a look at VelocityService), its
>> logging non existant and actively hampered by insisting on
>> re-inventing commons-logging and the Template Language is
>> "non-consistent" at best. And try to include and parse templates in a
>> loop. I've never seen again a gigabyte of memory gobbled up so
>> fast.
>>
>> However, it's the best free product around, it is well accepted as
>> part of the ASF world and (best!) it is not jealously guarded by
>> obnoxious developers who prefer to flame their users instead of
>> helping them.
>>
>> That's why it is our default view engine and we're damn proud of
>> it. :-)
>>
>> Regards
>> Henning
>>
>> --
>> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
>> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>>
>> RedHat Certified Engineer -- Jakarta Turbine Development --
>> hero for hire
>> Linux, Java, perl, Solaris -- Consulting, Training, Development
>>
>> "Fighting for one's political stand is an honorable action, but re-
>> fusing to acknowledge that there might be weaknesses in one's
>> position - in order to identify them so that they can be remedied -
>> is a large enough problem with the Open Source movement that it
>> deserves to be on this list of the top five problems."
>> -- Michelle Levesque, "Fundamental Issues with
>> Open Source Software Development"
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>>
>>
>>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org