You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Paulo Gaspar <pa...@krankikom.de> on 2001/09/10 06:09:26 UTC
RE: performance questions - faster Introspector
Attached is a little modification to Attila's great work on the
Introspector.
I just gave it a little twist by keeping everything keyed by Class
instead of by class name. To do it was necessary to add an extra
map, but this one only gets to be used when there is a new class or
when a Class Loader got dumped.
This should keep things FASTER, especially after the introspection
cache is filled.
I am attaching the whole file, but there are not that many changes
from Attila's version. Please make a diff to see them.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Sunday, September 09, 2001 8:21 PM
> To: velocity-dev@jakarta.apache.org
> Subject: Re: performance questions
>
>
> On 9/9/01 3:24 AM, "Attila Szegedi" <sz...@freemail.hu> wrote:
>
> > (I've redirected this to velocity-dev, hope you don't mind)
> >
> > Here's my stab at having Introspector detect class reloads and
> discard no
> > longer relevant ClassMaps. Right now it might seem a bit compex, as it
> > discards ClassMaps at class loader granularity. However if it
> is not granted
> > the required "getClassLoader" RuntimePermission, then it falls back
> > gracefully and simply clears the whole cache when it detects
> what seems like
> > a class reload.
>
>
> This is great - this is the same strategy that I took (which was
> really what
> you described in the first place), but didn't separate by classloader. I
> just dumped the entire pile when something changed.
>
> I made some small changes to introspector for the separate runtime that I
> will check in today, so I will dump my classloader-change changes
> and put in
> yours after that and provisionally checkin so people can see if it solves
> the problem (it should...)
>
> I am still wary about two things, the general performance and the
> complexity
> of dumping all in a classloader, as we are assuming a lot there.
> Of course,
> dumping all is pretty inefficient, so dumping by classloader is smarter.
> However... :)
>
> >
> > I'm including both the diffs and the complete modified files (as
> > Introspector underwent a major rewamp, I feel it's better comprehensible
> > from complete source than from the diff.)
> >
> > I've run it against the test suite and it fails on single test,
> but I assume
> > it has nothing to do with these changes:
> >
> > [java] There was 1 failure:
> > [java] 1)
> > EncodingTestCase(org.apache.velocity.test.EncodingTestCase)junit.
> > framework.AssertionFailedError: Output 2 incorrect.
> > [java] at
> > org.apache.velocity.test.EncodingTestCase.runTest(EncodingTes
> > tCase.java:170)
> > [java]
> > [java] FAILURES!!!
> > [java] Tests run: 1, Failures: 1, Errors: 0
> > [java]
>
> That's weird... Did it work before the change? I wonder if it's output
> line terminator related. I will toss in a small fix to see if
> that changes
> it for you.
>
> > In meanwhile, I'm thinking of making a test case specifically for this
> > functionality.
>
> geir
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> Developing for the web? See http://jakarta.apache.org/velocity/
> If you look up, there are no limits - Japanese Proverb
>
Multiple-ClassLoader safe Introspector
Posted by Paulo Gaspar <pa...@krankikom.de>.
There is a simple way of having a Multiple-ClassLoader safe Introspector:
LRU cache.
There are a couple of LRU Maps/caches in Jakarta. The simplest one I am
aware of is the LRUMap at the commons-collections project (I have a
lighter/faster version of this one in tests.)
If one finds an appropriate strategy to evict unused introspection data
from the cache, everything will end up being GCed "sometime" (albeit
possibly quite a bit after the respective CL is invalidated).
Possible strategies to trigger eviction:
- When free memory gets lower than X (that is how Cocoon 2's
MRUMemoryStore triggers eviction of cached objects);
- Time interval.
Possible strategies to find out how many objects to evict:
- Until free memory goes back to acceptable levels (again, as in
Cocoon 2's MRUMemoryStore);
- Introspected data not used for more than Y minutes.
It would also be nice to have an API call just to evict all cached
introspection data for a given ClassLoader.
Disadvantages:
* Added configuration complexity of the Introspection Cache;
* Maybe it would be slightly slower (just the time of moving updating
the LRU list for each use).
Advantages:
* It is possible to use a single cache for multiple class loaders and
even for multiple "legal" versions of the same class.
I do not talk about complexity because a simplistic Cache based on a
LRUMap with a time based eviction strategy would be even simpler than
the new cache.
Again, it would be nice to change Introspection Cache implementations
at will. Maybe an idea for version 2... or 3...
Have fun,
Paulo Gaspar
RE: performance questions - faster Introspector
Posted by Paulo Gaspar <pa...@krankikom.de>.
Thanks!
But it just an easy bit after you did all the really hard work.
=:o)
Have fun,
Paulo
> -----Original Message-----
> From: Attila Szegedi [mailto:szegedia@freemail.hu]
> Sent: Monday, September 10, 2001 10:36 AM
>
> Nice idea. Realy good.
> Attila.
>
> ----- Original Message -----
> From: "Paulo Gaspar" <pa...@krankikom.de>
> To: <ve...@jakarta.apache.org>
> Sent: 2001. szeptember 10. 6:09
> Subject: RE: performance questions - faster Introspector
>
>
> > Attached is a little modification to Attila's great work on the
> > Introspector.
> >
> > I just gave it a little twist by keeping everything keyed by Class
> > instead of by class name. To do it was necessary to add an extra
> > map, but this one only gets to be used when there is a new class or
> > when a Class Loader got dumped.
> >
> > This should keep things FASTER, especially after the introspection
> > cache is filled.
> >
> > I am attaching the whole file, but there are not that many changes
> > from Attila's version. Please make a diff to see them.
> >
> >
> > Have fun,
> > Paulo Gaspar
> >
>
>
Re: performance questions - faster Introspector
Posted by Attila Szegedi <sz...@freemail.hu>.
Nice idea. Realy good.
Attila.
----- Original Message -----
From: "Paulo Gaspar" <pa...@krankikom.de>
To: <ve...@jakarta.apache.org>
Sent: 2001. szeptember 10. 6:09
Subject: RE: performance questions - faster Introspector
> Attached is a little modification to Attila's great work on the
> Introspector.
>
> I just gave it a little twist by keeping everything keyed by Class
> instead of by class name. To do it was necessary to add an extra
> map, but this one only gets to be used when there is a new class or
> when a Class Loader got dumped.
>
> This should keep things FASTER, especially after the introspection
> cache is filled.
>
> I am attaching the whole file, but there are not that many changes
> from Attila's version. Please make a diff to see them.
>
>
> Have fun,
> Paulo Gaspar
>
Re: performance questions - faster Introspector
Posted by Bojan Smojver <bo...@binarix.com>.
Attila Szegedi wrote:
>
> ----- Original Message -----
> From: "Bojan Smojver" <bo...@binarix.com>
> To: <ve...@jakarta.apache.org>
> Sent: 2001. szeptember 10. 10:01
> Subject: Re: performance questions - faster Introspector
>
> >
> > One other idea might be to not have static fields in the Introspector,
> > but rather make them regular private class fields and then keep the
> > logic simple since it would already be per classloader. But that would
> > probably increase the overall memory usage of the cache since there
> > could be duplicates of classes/methods in multiple instances of
> > Introspector cache. I'm not really sure what I'm talking about here but
> > what the heck...
> >
>
> Umm. From this point of view, it really makes no difference if the cache is
> accessed through a static field, or through instance field of a singleton
> (which is itself probably also referred by a static field). What REALLY
> helps here is to have Velocity classes loaded through the same disposable
> class loader used to load your classes - that is, have them in WEB-INF/lib
> or WEB-INF/classes.
>
> Attila.
Just thinking out loud...
My understanding is that RuntimeInstance creates an Introspector object
and VelocityEngine creates a RuntimeInstance. So, there is a 1 to 1
relationship between a VelocityEngine instance and an Introspector
instance.
Currently, if Velocity jar is in Tomcat's lib/apps, that would mean that
cache is one for all apps since the classloader for lib/apps keeps one
copy of static fields for all Introspector objects. If Velocity jar was
in WEB-INF/lib then each Introspector object would share the same static
fields within that app.
If fields that are holding the maps in the Introspector were not static,
that would mean that there would be one copy of them in each
Introspector, ie. one per VelocityEngine. I'm not sure if that's good,
bad or ugly, but you're correct, it wouldn't be per classloader, it
would be per instance of VelocityEngine, so it would be even more
granular then classloader. Aieee!
OK, I'm going to take a nap now, my head hurts...
Bojan
Re: performance questions - faster Introspector
Posted by Attila Szegedi <sz...@freemail.hu>.
----- Original Message -----
From: "Bojan Smojver" <bo...@binarix.com>
To: <ve...@jakarta.apache.org>
Sent: 2001. szeptember 10. 10:01
Subject: Re: performance questions - faster Introspector
>
> One other idea might be to not have static fields in the Introspector,
> but rather make them regular private class fields and then keep the
> logic simple since it would already be per classloader. But that would
> probably increase the overall memory usage of the cache since there
> could be duplicates of classes/methods in multiple instances of
> Introspector cache. I'm not really sure what I'm talking about here but
> what the heck...
>
Umm. From this point of view, it really makes no difference if the cache is
accessed through a static field, or through instance field of a singleton
(which is itself probably also referred by a static field). What REALLY
helps here is to have Velocity classes loaded through the same disposable
class loader used to load your classes - that is, have them in WEB-INF/lib
or WEB-INF/classes.
Attila.
Re: performance questions - faster Introspector
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/10/01 1:01 AM, "Bojan Smojver" <bo...@binarix.com> wrote:
> One other idea might be to not have static fields in the Introspector,
> but rather make them regular private class fields and then keep the
> logic simple since it would already be per classloader. But that would
> probably increase the overall memory usage of the cache since there
> could be duplicates of classes/methods in multiple instances of
> Introspector cache. I'm not really sure what I'm talking about here but
> what the heck...
+1
That sounds like the best and easiest solution to me.
-jon
Re: performance questions - faster Introspector
Posted by Bojan Smojver <bo...@binarix.com>.
Attila Szegedi wrote:
>
> Hmm. So, if I'm right you'd be happier with per-classloader dumping of
> cache? (I have this already coded, but have phased it out in agreement with
> Geir in spirit of the KISS principle).
>
> Attila.
Honestly, I'm just a happy Velocity user. Even if I had to stop/start
Tomcat every week to prevent memory leaks it'd be fine by me. Well,
almost, anyway.
However, this is like with one of those Linux kernel locking issues - do
we make things more granular and more complex or less granular and less
complex (not that I'd be able to program any)? I guess it depends on
what you want to achieve - on a single CPU system the first approach is
an overkill, on a 64 CPU machine it's a necessity. You know, the Irix
syndrome.
To get back to Velocity, since non-singleton model was introduced, I
guess it makes sense to have Velocity jar in lib/apps. And on a big
server running a lot of Velocity apps, especially if some of them are
experimental (ie. you let people poke around, deploy their own
templates, beans etc.), dumping of the whole lot would hurt other apps
(potentially other customers). So, yes I'd be inclined to vote for
complexity here.
One other idea might be to not have static fields in the Introspector,
but rather make them regular private class fields and then keep the
logic simple since it would already be per classloader. But that would
probably increase the overall memory usage of the cache since there
could be duplicates of classes/methods in multiple instances of
Introspector cache. I'm not really sure what I'm talking about here but
what the heck...
Either way, I'm OK. Slightly more OK with a complex solution though (I
actually rather liked the Weak* thingies but someone pointed out the
performance penalty).
Bojan
Re: performance questions - faster Introspector
Posted by Bojan Smojver <bo...@binarix.com>.
Attila Szegedi wrote:
> Incorporate copy tasks in your Ant script that will dispatch the latest
> velocity.jar everywhere from a central position. Ant is ideal for lazy
> people. After all, we're using it since we're lazy to manually invoke the
> compiler, jar classes, copy them, test them, generate javadocs etc. every
> time.
I used to have a symlink in WEB-INF/lib to a central Velocity jar (when
I used signleton model) and then I'd do something like:
----------------------------
for i in customer1 customer2 ...;
do cd $i; ant test-deploy prod-deploy; cd ..;
done
----------------------------
and all sites would be updated. I might go back to that...
Bojan
Re: performance questions - faster Introspector
Posted by Attila Szegedi <sz...@freemail.hu>.
----- Original Message -----
From: "Bojan Smojver" <bo...@binarix.com>
To: <ve...@jakarta.apache.org>
Sent: 2001. szeptember 10. 11:30
Subject: Re: performance questions - faster Introspector
>
> You know what they say - people do things because they're lazy. So do I.
> With number of virtual hosts/apps growing, I have to make sure everyone
> gets the updated Velocity jar. And being a lazy bastard I am... One
> solution is to symlink the thing, works well. Ant (my site build tool)
> doesn't like those much though when it copies files around, so I had to
> use platform specific hacks and that's ugly. I used to have multiple
> copies of Velocity around before, I just wanted to clean up the mess.
Incorporate copy tasks in your Ant script that will dispatch the latest
velocity.jar everywhere from a central position. Ant is ideal for lazy
people. After all, we're using it since we're lazy to manually invoke the
compiler, jar classes, copy them, test them, generate javadocs etc. every
time.
Attila.
Re: performance questions - faster Introspector
Posted by Bojan Smojver <bo...@binarix.com>.
"Geir Magnusson Jr." wrote:
>
> On 9/9/01 11:30 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
>
> > "Geir Magnusson Jr." wrote:
> >>
> >> Two points on this :
> >>
> >> 1) If you have a big installation, and you share one instance of Velocity
> >> across all of your webapps via Tomcat's lib, you are asking for trouble, I
> >> think. I can't see much benefit to that other than desire to avoid multiple
> >> copies of the jar. If that is the case, and you want to keep your webapps
> >> partitioned, then use the separate instance runtime (which I think you are
> >> doing, Bojan). If *that* is the case, then I think you are safe, as nothing
> >> is a singleton in the separate instance, your servlet holds the reference to
> >> it, and when your servlet is recycled on the classloader change, then you
> >> let go of the refrerence to the vel runtime, and get a new one. All is
> >> well.
> >
> > You know what they say - people do things because they're lazy. So do I.
> > With number of virtual hosts/apps growing, I have to make sure everyone
> > gets the updated Velocity jar. And being a lazy bastard I am... One
> > solution is to symlink the thing, works well. Ant (my site build tool)
> > doesn't like those much though when it copies files around, so I had to
> > use platform specific hacks and that's ugly. I used to have multiple
> > copies of Velocity around before, I just wanted to clean up the mess.
>
> I think you misunderstood me
Could be. Sorry about that.
> - I think that it is a valid reason to have one
> on top to avoid duplication. (You may have troubles when one app wants a new
> version, but I guess you can drop into the webapp itself then.)
> I tend to keep them separate, as I don't have a large number, and I want the
> ability for each webapp to have different versions.
Since I really started using Velocity from version 1.0, not much has
changed (which can only be good) in the way templates work. I only have
one servlet, so when I move forward, I move forward in all apps (except
for the legacy JSP stuff).
> But since you are using separate runtimes for each servlet... (read below..)
>
> > Not to worry, I can go either way, I just wanted to use Velocity as one
> > of the 'standard' Tomcat app libraries, without the need to do anything
> > special within each app.
>
> Since you are using the separate runtime instance model in your servlet
> (VelocityEngine), then I think there is no problem if you keep it in
> tomcat/lib because each servlet has it's own instance of the engine.
Cool :-)
> Before the fixes I committed earlier today, even the separate instance
> runtime would have problems with the introspector collecting junk, as the
> Introspector was left as a singleton (my fault... It's fixed now).
>
> Now, by using the separate instance in your servlet, when your CL gets
> dumped, the servlet gets dumped, so the VelocityEngine will eventually get
> GC'd, and since the Introspector is no longer a Singleton, it will get GC'd
> as well.
>
> Unless I am missing something (quite possibly, as I am on vacation and
> rather muddy headed...), all should be well for you.
>
> We still should add the change, I think. (I am merging the current state,
> Attila's patch, and Paulo's improvement...)
I've seen the comitted patch and it uses private class variables, so I
guess it will there will be 1 to 1 relationship between VelocityEngine,
RuntimeInstance and Introspector, which means there will ba quite a few
Introspectors around once all those VelocityEngines kick in. I'll
download and give it a try.
Bojan
Re: performance questions - faster Introspector (committed...)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ok - I put together the minimalist version of Attila's reengineering and the
clever patch from Paulo into one version that is up to date with CVS head.
I believe I have it right, although some will attest that I have been a
dunderhead of late, so I might have screwed this up too. I love this
vacation, but I am now ready to get back to things (which explains why I am
up late doing this...)
Anyhow, I really like this - it's very simple, very clean, keeps Class as
the key, and the cache dumping is simple.
While this is 'provisional' because of 1.2 coming up, the whole thing is
simple enough that I believe that it poses little risk, and would think that
if all is well, we can beat on it a few days and then let it roll into 1.2.
It's simple to back out of because the changes are so localized, so there is
little risk to 1.2 if something is wrong.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
If you look up, there are no limits - Japanese Proverb
RE: performance questions - faster Introspector
Posted by Paulo Gaspar <pa...@krankikom.de>.
> Since you are using the separate runtime instance model in your servlet
> (VelocityEngine), then I think there is no problem if you keep it in
> tomcat/lib because each servlet has it's own instance of the engine.
Now, the tricky bit is that the singleton components are still available.
If someone (more than one) uses it, it will be a mess again.
But it will be a mess on many other levels besides the introspector.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Monday, September 10, 2001 11:42 AM
>
>
> On 9/9/01 11:30 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
>
> > "Geir Magnusson Jr." wrote:
> >>
> >> Two points on this :
> >>
> >> 1) If you have a big installation, and you share one instance
> of Velocity
> >> across all of your webapps via Tomcat's lib, you are asking
> for trouble, I
> >> think. I can't see much benefit to that other than desire to
> avoid multiple
> >> copies of the jar. If that is the case, and you want to keep
> your webapps
> >> partitioned, then use the separate instance runtime (which I
> think you are
> >> doing, Bojan). If *that* is the case, then I think you are
> safe, as nothing
> >> is a singleton in the separate instance, your servlet holds
> the reference to
> >> it, and when your servlet is recycled on the classloader
> change, then you
> >> let go of the refrerence to the vel runtime, and get a new one. All is
> >> well.
> >
> > You know what they say - people do things because they're lazy. So do I.
> > With number of virtual hosts/apps growing, I have to make sure everyone
> > gets the updated Velocity jar. And being a lazy bastard I am... One
> > solution is to symlink the thing, works well. Ant (my site build tool)
> > doesn't like those much though when it copies files around, so I had to
> > use platform specific hacks and that's ugly. I used to have multiple
> > copies of Velocity around before, I just wanted to clean up the mess.
>
> I think you misunderstood me - I think that it is a valid reason
> to have one
> on top to avoid duplication. (You may have troubles when one app
> wants a new
> version, but I guess you can drop into the webapp itself then.)
>
> I tend to keep them separate, as I don't have a large number, and
> I want the
> ability for each webapp to have different versions.
>
> But since you are using separate runtimes for each servlet...
> (read below..)
>
> > Not to worry, I can go either way, I just wanted to use Velocity as one
> > of the 'standard' Tomcat app libraries, without the need to do anything
> > special within each app.
>
> Since you are using the separate runtime instance model in your servlet
> (VelocityEngine), then I think there is no problem if you keep it in
> tomcat/lib because each servlet has it's own instance of the engine.
>
> Before the fixes I committed earlier today, even the separate instance
> runtime would have problems with the introspector collecting junk, as the
> Introspector was left as a singleton (my fault... It's fixed now).
>
> Now, by using the separate instance in your servlet, when your CL gets
> dumped, the servlet gets dumped, so the VelocityEngine will eventually get
> GC'd, and since the Introspector is no longer a Singleton, it
> will get GC'd
> as well.
>
> Unless I am missing something (quite possibly, as I am on vacation and
> rather muddy headed...), all should be well for you.
>
> We still should add the change, I think. (I am merging the current state,
> Attila's patch, and Paulo's improvement...)
>
> geir
>
>
> >> 2) I still think we are adding unnecessary complexityh re the
> >> per-classloader dumping. KISS.
> >
> > No worries.
> >
> > Bojan
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> Developing for the web? See http://jakarta.apache.org/velocity/
> If you look up, there are no limits - Japanese Proverb
>
Re: performance questions - faster Introspector
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 9/9/01 11:30 PM, "Bojan Smojver" <bo...@binarix.com> wrote:
> "Geir Magnusson Jr." wrote:
>>
>> Two points on this :
>>
>> 1) If you have a big installation, and you share one instance of Velocity
>> across all of your webapps via Tomcat's lib, you are asking for trouble, I
>> think. I can't see much benefit to that other than desire to avoid multiple
>> copies of the jar. If that is the case, and you want to keep your webapps
>> partitioned, then use the separate instance runtime (which I think you are
>> doing, Bojan). If *that* is the case, then I think you are safe, as nothing
>> is a singleton in the separate instance, your servlet holds the reference to
>> it, and when your servlet is recycled on the classloader change, then you
>> let go of the refrerence to the vel runtime, and get a new one. All is
>> well.
>
> You know what they say - people do things because they're lazy. So do I.
> With number of virtual hosts/apps growing, I have to make sure everyone
> gets the updated Velocity jar. And being a lazy bastard I am... One
> solution is to symlink the thing, works well. Ant (my site build tool)
> doesn't like those much though when it copies files around, so I had to
> use platform specific hacks and that's ugly. I used to have multiple
> copies of Velocity around before, I just wanted to clean up the mess.
I think you misunderstood me - I think that it is a valid reason to have one
on top to avoid duplication. (You may have troubles when one app wants a new
version, but I guess you can drop into the webapp itself then.)
I tend to keep them separate, as I don't have a large number, and I want the
ability for each webapp to have different versions.
But since you are using separate runtimes for each servlet... (read below..)
> Not to worry, I can go either way, I just wanted to use Velocity as one
> of the 'standard' Tomcat app libraries, without the need to do anything
> special within each app.
Since you are using the separate runtime instance model in your servlet
(VelocityEngine), then I think there is no problem if you keep it in
tomcat/lib because each servlet has it's own instance of the engine.
Before the fixes I committed earlier today, even the separate instance
runtime would have problems with the introspector collecting junk, as the
Introspector was left as a singleton (my fault... It's fixed now).
Now, by using the separate instance in your servlet, when your CL gets
dumped, the servlet gets dumped, so the VelocityEngine will eventually get
GC'd, and since the Introspector is no longer a Singleton, it will get GC'd
as well.
Unless I am missing something (quite possibly, as I am on vacation and
rather muddy headed...), all should be well for you.
We still should add the change, I think. (I am merging the current state,
Attila's patch, and Paulo's improvement...)
geir
>> 2) I still think we are adding unnecessary complexityh re the
>> per-classloader dumping. KISS.
>
> No worries.
>
> Bojan
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
If you look up, there are no limits - Japanese Proverb
Re: performance questions - faster Introspector
Posted by Bojan Smojver <bo...@binarix.com>.
"Geir Magnusson Jr." wrote:
>
> Two points on this :
>
> 1) If you have a big installation, and you share one instance of Velocity
> across all of your webapps via Tomcat's lib, you are asking for trouble, I
> think. I can't see much benefit to that other than desire to avoid multiple
> copies of the jar. If that is the case, and you want to keep your webapps
> partitioned, then use the separate instance runtime (which I think you are
> doing, Bojan). If *that* is the case, then I think you are safe, as nothing
> is a singleton in the separate instance, your servlet holds the reference to
> it, and when your servlet is recycled on the classloader change, then you
> let go of the refrerence to the vel runtime, and get a new one. All is
> well.
You know what they say - people do things because they're lazy. So do I.
With number of virtual hosts/apps growing, I have to make sure everyone
gets the updated Velocity jar. And being a lazy bastard I am... One
solution is to symlink the thing, works well. Ant (my site build tool)
doesn't like those much though when it copies files around, so I had to
use platform specific hacks and that's ugly. I used to have multiple
copies of Velocity around before, I just wanted to clean up the mess.
Not to worry, I can go either way, I just wanted to use Velocity as one
of the 'standard' Tomcat app libraries, without the need to do anything
special within each app.
> 2) I still think we are adding unnecessary complexityh re the
> per-classloader dumping. KISS.
No worries.
Bojan
Re: performance questions - faster Introspector
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Two points on this :
1) If you have a big installation, and you share one instance of Velocity
across all of your webapps via Tomcat's lib, you are asking for trouble, I
think. I can't see much benefit to that other than desire to avoid multiple
copies of the jar. If that is the case, and you want to keep your webapps
partitioned, then use the separate instance runtime (which I think you are
doing, Bojan). If *that* is the case, then I think you are safe, as nothing
is a singleton in the separate instance, your servlet holds the reference to
it, and when your servlet is recycled on the classloader change, then you
let go of the refrerence to the vel runtime, and get a new one. All is
well.
2) I still think we are adding unnecessary complexityh re the
per-classloader dumping. KISS.
geir
On 9/9/01 9:29 PM, "Attila Szegedi" <sz...@freemail.hu> wrote:
> Hmm. So, if I'm right you'd be happier with per-classloader dumping of
> cache? (I have this already coded, but have phased it out in agreement with
> Geir in spirit of the KISS principle).
>
> Attila.
>
> ----- Original Message -----
> From: "Bojan Smojver" <bo...@binarix.com>
> To: <ve...@jakarta.apache.org>
> Sent: 2001. szeptember 10. 8:32
> Subject: Re: performance questions - faster Introspector
>
>
>> "Geir Magnusson Jr." wrote:
>>>
>>> On 9/9/01 6:09 PM, "Paulo Gaspar" <pa...@krankikom.de> wrote:
>>>
>>>> Attached is a little modification to Attila's great work on the
>>>> Introspector.
>>>>
>>>> I just gave it a little twist by keeping everything keyed by Class
>>>> instead of by class name. To do it was necessary to add an extra
>>>> map, but this one only gets to be used when there is a new class or
>>>> when a Class Loader got dumped.
>>>
>>> Note, for simplicity, we are going to knock out the 'by classloader'
> stuff
>>> and just dump the whole pile.
>>
>> If Tomcat lib/apps installation of Velocity is used, then the
>> Introspector cache for all apps would be cleaned out since there would
>> be only one of those caches hanging around. In other words, if there are
>> many applications within one Tomcat, one has to be careful about
>> deployment of new classes as that might cause jerks on heavily loaded
>> servers.
>>
>> Hmm, OK, promise to deploy only during the graveyard shift :-)
>>
>> Bojan
>>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
If you look up, there are no limits - Japanese Proverb
Re: performance questions - faster Introspector
Posted by Attila Szegedi <sz...@freemail.hu>.
Hmm. So, if I'm right you'd be happier with per-classloader dumping of
cache? (I have this already coded, but have phased it out in agreement with
Geir in spirit of the KISS principle).
Attila.
----- Original Message -----
From: "Bojan Smojver" <bo...@binarix.com>
To: <ve...@jakarta.apache.org>
Sent: 2001. szeptember 10. 8:32
Subject: Re: performance questions - faster Introspector
> "Geir Magnusson Jr." wrote:
> >
> > On 9/9/01 6:09 PM, "Paulo Gaspar" <pa...@krankikom.de> wrote:
> >
> > > Attached is a little modification to Attila's great work on the
> > > Introspector.
> > >
> > > I just gave it a little twist by keeping everything keyed by Class
> > > instead of by class name. To do it was necessary to add an extra
> > > map, but this one only gets to be used when there is a new class or
> > > when a Class Loader got dumped.
> >
> > Note, for simplicity, we are going to knock out the 'by classloader'
stuff
> > and just dump the whole pile.
>
> If Tomcat lib/apps installation of Velocity is used, then the
> Introspector cache for all apps would be cleaned out since there would
> be only one of those caches hanging around. In other words, if there are
> many applications within one Tomcat, one has to be careful about
> deployment of new classes as that might cause jerks on heavily loaded
> servers.
>
> Hmm, OK, promise to deploy only during the graveyard shift :-)
>
> Bojan
>
Re: performance questions - faster Introspector
Posted by Bojan Smojver <bo...@binarix.com>.
"Geir Magnusson Jr." wrote:
>
> On 9/9/01 6:09 PM, "Paulo Gaspar" <pa...@krankikom.de> wrote:
>
> > Attached is a little modification to Attila's great work on the
> > Introspector.
> >
> > I just gave it a little twist by keeping everything keyed by Class
> > instead of by class name. To do it was necessary to add an extra
> > map, but this one only gets to be used when there is a new class or
> > when a Class Loader got dumped.
>
> Note, for simplicity, we are going to knock out the 'by classloader' stuff
> and just dump the whole pile.
If Tomcat lib/apps installation of Velocity is used, then the
Introspector cache for all apps would be cleaned out since there would
be only one of those caches hanging around. In other words, if there are
many applications within one Tomcat, one has to be careful about
deployment of new classes as that might cause jerks on heavily loaded
servers.
Hmm, OK, promise to deploy only during the graveyard shift :-)
Bojan
Re: performance questions - faster Introspector
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 9/9/01 6:09 PM, "Paulo Gaspar" <pa...@krankikom.de> wrote:
> Attached is a little modification to Attila's great work on the
> Introspector.
>
> I just gave it a little twist by keeping everything keyed by Class
> instead of by class name. To do it was necessary to add an extra
> map, but this one only gets to be used when there is a new class or
> when a Class Loader got dumped.
Note, for simplicity, we are going to knock out the 'by classloader' stuff
and just dump the whole pile.
> This should keep things FASTER, especially after the introspection
> cache is filled.
I think of a classloader getting dumped as a momentous occurrence, so
keeping the code simple and free of assumptions at the cost of a little
one-time overhead is a fair trade, I think.
> I am attaching the whole file, but there are not that many changes
> from Attila's version. Please make a diff to see them.
>
I will take a look and integrate all later tonight.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
If you look up, there are no limits - Japanese Proverb