You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Shinobu Kawai Yoshida <sh...@gmail.com> on 2005/01/23 18:24:55 UTC
Pooling Tools
Hi Claude,
> I take profit of this mail to let us speak a bit about tools (more for
> devs).
Then let's take it to the dev list. :)
> We spoke before about tools pooling (especially Nathan iirc): how can it
> be implemented? Using a Reusable interface with a reinit(initdata)
> method?
Made me wonder, how many people actually needs this feature? On what
occasions would they use it?
> And a suggestion on the same subject:
>
> Maybe we could have the syntax of the scope element be:
> application | session | request | <url regexp>
> in toolbox.xml to refine scopes at a thiner level than the request
> scope.
Sorry, but I'm not quite getting it. How would one use it? The <url
regexp>, I mean.
Best regards,
-- Shinobu
--
Shinobu "Kawai" Yoshida <sh...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Pooling Tools
Posted by Ilkka Priha <im...@surfeu.fi>.
Hello,
E.g. the Turbine project has applied pooled Velocity tools for years, but the
benefits are not so clear. Creating a new simple object in Java is much faster
than getting one from the pool because of the synchronized tests required by the
pooling mechanism to find the correct object, to handle empty pools, etc. If the
initialization of the tool requires a lot of time, then pooling could be faster.
On the other hand, you typically need to re-initialize the tool for the current
context when you got it from the pool, too.
One advantage is to have better controlled memory management with less GC as you
can design your pool sizes based on actual requirements of your application.
However, the GC mechanism in 1.4 is also quite efficient as it runs in backgound
without synchronizing with other threads. Also the shared memory feature in 1.4
can be applied to statically share memory between tool instances requiring large
memory blocks.
Anyway, Commons Pool implements a generic pool mechanism which should be
applicable also to Velocity tools if needed.
-- Ilkka
Claude Brisson wrote:
> On Mon, 2005-01-24 at 02:24 +0900, Shinobu Kawai Yoshida wrote:
>
>>Hi Claude,
>>
>>
>>>I take profit of this mail to let us speak a bit about tools (more for
>>>devs).
>>
>>Then let's take it to the dev list. :)
>>
>>
>>>We spoke before about tools pooling (especially Nathan iirc): how can it
>>>be implemented? Using a Reusable interface with a reinit(initdata)
>>>method?
>>
>>Made me wonder, how many people actually needs this feature? On what
>>occasions would they use it?
>
>
> It's more an optimisation than a new feature. So all people having high
> traffic sites could benefit of it.
>
> For instance, you could have a pool of, let's say, twenty instances of
> the ParameterParser tool -with a reinit() method- instead of recreating
> one at each request.
>
> In most cases (whenever it makes sense), it is far faster to only
> re-initialize an object than to have to instanciate it from scratch.
>
>
>>>And a suggestion on the same subject:
>>>
>>>Maybe we could have the syntax of the scope element be:
>>>application | session | request | <url regexp>
>>>in toolbox.xml to refine scopes at a thiner level than the request
>>>scope.
>>
>>Sorry, but I'm not quite getting it. How would one use it? The <url
>>regexp>, I mean.
>
>
> This is also meant at providing some optimization. Tools with such a
> scope would be request tools that are instanciated if and only if the
> url of the request matches the regexp provided in the toolbox.xml. It
> seems to me that this approach is far better MVC than the
> $toolLoader.loadTool("thetool") approach.
>
> For instance, a SearchTool can be put in the context only if the url is
> like /search/*.vm
>
> In fact I am more or less ready to code those suggestions, but I wanted
> to somehow discuss the specs here so it get more chances to get commited
> as is.
>
> Claude
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Pooling Tools
Posted by Shinobu Kawai Yoshida <sh...@gmail.com>.
Hi Claude,
> It's more an optimisation than a new feature. So all people having high
> traffic sites could benefit of it.
>
> For instance, you could have a pool of, let's say, twenty instances of
> the ParameterParser tool -with a reinit() method- instead of recreating
> one at each request.
>
> In most cases (whenever it makes sense), it is far faster to only
> re-initialize an object than to have to instanciate it from scratch.
I guess I just don't have any experience with object instantiation as
a performance issue. (DB processing and the request/response across
the network were far more significant in the total when measured.)
> > Sorry, but I'm not quite getting it. How would one use it? The <url
> > regexp>, I mean.
>
> This is also meant at providing some optimization. Tools with such a
> scope would be request tools that are instanciated if and only if the
> url of the request matches the regexp provided in the toolbox.xml. It
> seems to me that this approach is far better MVC than the
> $toolLoader.loadTool("thetool") approach.
>
> For instance, a SearchTool can be put in the context only if the url is
> like /search/*.vm
Oh, I get it now. It's a condition to determine whether to put the
tool in the Context or not, right?.
> In fact I am more or less ready to code those suggestions, but I wanted
> to somehow discuss the specs here so it get more chances to get commited
> as is.
Hey, that's great!
Best regards,
-- Shinobu
--
Shinobu "Kawai" Yoshida <sh...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Pooling Tools
Posted by Nathan Bubna <nb...@gmail.com>.
On Mon, 24 Jan 2005 02:27:59 +0100, Claude Brisson <cl...@renegat.net> wrote:
> On Mon, 2005-01-24 at 02:24 +0900, Shinobu Kawai Yoshida wrote:
> > Hi Claude,
...
> > > And a suggestion on the same subject:
> > >
> > > Maybe we could have the syntax of the scope element be:
> > > application | session | request | <url regexp>
> > > in toolbox.xml to refine scopes at a thiner level than the request
> > > scope.
> >
> > Sorry, but I'm not quite getting it. How would one use it? The <url
> > regexp>, I mean.
>
> This is also meant at providing some optimization. Tools with such a
> scope would be request tools that are instanciated if and only if the
> url of the request matches the regexp provided in the toolbox.xml. It
> seems to me that this approach is far better MVC than the
> $toolLoader.loadTool("thetool") approach.
>
> For instance, a SearchTool can be put in the context only if the url is
> like /search/*.vm
gotcha. and yeah, this has potential to be quite cool. i could see
possible use for perfomance tweaking or for security.
> In fact I am more or less ready to code those suggestions, but I wanted
> to somehow discuss the specs here so it get more chances to get commited
> as is.
well, the first question is, "how do we do the pattern/path
matching/restricting efficiently?" if we use regular expressions, i
wonder if it would become a more expensive operation to do the
matching than to just create the tool. i'm no expert and have run no
tests, but i have the impression that regular expressions can be heavy
lifting, especially compared to the init cost for a simple tool.
my second question would be, "how/where do you see us specifying these
restrictions in the toolbox definition?"
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Pooling Tools
Posted by Claude Brisson <cl...@renegat.net>.
On Mon, 2005-01-24 at 02:24 +0900, Shinobu Kawai Yoshida wrote:
> Hi Claude,
>
> > I take profit of this mail to let us speak a bit about tools (more for
> > devs).
>
> Then let's take it to the dev list. :)
>
> > We spoke before about tools pooling (especially Nathan iirc): how can it
> > be implemented? Using a Reusable interface with a reinit(initdata)
> > method?
>
> Made me wonder, how many people actually needs this feature? On what
> occasions would they use it?
It's more an optimisation than a new feature. So all people having high
traffic sites could benefit of it.
For instance, you could have a pool of, let's say, twenty instances of
the ParameterParser tool -with a reinit() method- instead of recreating
one at each request.
In most cases (whenever it makes sense), it is far faster to only
re-initialize an object than to have to instanciate it from scratch.
> > And a suggestion on the same subject:
> >
> > Maybe we could have the syntax of the scope element be:
> > application | session | request | <url regexp>
> > in toolbox.xml to refine scopes at a thiner level than the request
> > scope.
>
> Sorry, but I'm not quite getting it. How would one use it? The <url
> regexp>, I mean.
This is also meant at providing some optimization. Tools with such a
scope would be request tools that are instanciated if and only if the
url of the request matches the regexp provided in the toolbox.xml. It
seems to me that this approach is far better MVC than the
$toolLoader.loadTool("thetool") approach.
For instance, a SearchTool can be put in the context only if the url is
like /search/*.vm
In fact I am more or less ready to code those suggestions, but I wanted
to somehow discuss the specs here so it get more chances to get commited
as is.
Claude
--
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Pooling Tools
Posted by Shinobu Kawai Yoshida <sh...@gmail.com>.
Hi Nathan,
> so here's a few related questions...
>
> anyone thinking we should put a 1.2 out soon?
Well, now that Struts 1.2 is released, and Velocity 1.5 seems to be
coming soon, I think it would be nice to see the next release. :)
> what bugs should we
> squish for that?
There seems to be only 6 bugs in buzilla right now.
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=__open__&product=Velocity&content=&component=Tools
## But there maybe more just not categorized correctly. There were
some in Documentation, as we don't have a "doc for tools". Should
they be in "Tools" or "Documentation"?
> are there any recent contributions many people would
> like to see get in before 1.2 is released?
Being the contributor, I'd like to push the following, in the order of interest:
ArrayTool and EscapeTool:
http://wiki.apache.org/jakarta-velocity/ArrayTool
http://wiki.apache.org/jakarta-velocity/EscapeTool
These two I've been actually using, so they must be usefull. :)
## And are probably the only two I REALLY want in the library.
The null stuff:
http://wiki.apache.org/jakarta-velocity/NullTool
http://wiki.apache.org/jakarta-velocity/ViewNullTool
http://wiki.apache.org/jakarta-velocity/IfNullDirective
http://wiki.apache.org/jakarta-velocity/IfNotNullDirective
I think you said you wanted to discuss these. Well, I guess it's a
good time. :)
At least we need to discuss the difference between "no reference" and
"a reference to null". Likewise, "removing a reference" and "setting
a reference to null". (How to handle each.)
cf. http://issues.apache.org/bugzilla/show_bug.cgi?id=27741#c5
## I'm not sure if we REALLY need/want the directives.
PublicFieldUberspect:
http://wiki.apache.org/jakarta-velocity/PublicFieldUberspect
I hear about this on the user list occasionally. I'm not sure if it
belongs to the VelocityTools subproject, but since the
o.a.v.t.generic.log package is here, I thought I might as well put it
here.
MonostateVelocityEngine:
http://wiki.apache.org/jakarta-velocity/MonostateVelocityEngine
This was more or less a joke. I think it's comfortable staying on the wiki.
If any of them are going to make it, I'll try to make xdocs for them.
> is VelocityStruts up to
> date with Struts 1.2.x? i've been pretty out of touch with that part
> of the code lately.
I'm curious about that, too. Some more questions:
- Are the tools compatible with both Struts 1.1 and 1.2?
- Or do we need to have a separate set of tools for 1.1 and 1.2?
- Or should we just forget about 1.1?
> is anyone else interested in tool pooling? yes/no/why/why-not?
Not me, because I haven't a found a need for it (yet?). (YAGNI)
> would anyone else want to work on a 2.0 branch? i have a bunch of
> experimental stuff i was playing with locally a few months ago
> (pooling, pluggable toolbox loader, moving basic tool management to
> generic level, etc). it's a bit out of date, but i might be up for
> the work if i had some assurance of interest and assistance.
Sounds fun, but I don't think I can get enough time right now. :(
Best regards,
-- Shinobu
--
Shinobu "Kawai" Yoshida <sh...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Pooling Tools
Posted by Nathan Bubna <nb...@gmail.com>.
On Mon, 24 Jan 2005 02:24:55 +0900, Shinobu Kawai Yoshida
<sh...@gmail.com> wrote:
> Hi Claude,
>
> > I take profit of this mail to let us speak a bit about tools (more for
> > devs).
:)
> Then let's take it to the dev list. :)
>
> > We spoke before about tools pooling (especially Nathan iirc): how can it
> > be implemented? Using a Reusable interface with a reinit(initdata)
> > method?
i actually have a very lightly tested implementation of this (i named
the interface Poolable). there are a few hang ups though. (see
below)
> Made me wonder, how many people actually needs this feature? On what
> occasions would they use it?
i'm really not sure how many people would use and/or want this
feature. but the use case would probably be session or request scoped
tools with sizable instantiation costs. granted, there are ways to
deal with that now, but i don't think it would hurt to have more
options. :) however, as i said, there are a few hang ups...
1) the current structure and placement of classes in the
generic/view/struts categories prevents this (and Configurable) from
being available to generic tools. the necessary reorganization is
enough to make the effort for backwards compatibility undesirable. so
the local branch of mine with all these changes would probably require
a major version number jump and a new branch in SVN. we may be ready
to go there, we may not, i dunno, something to talk about, i guess.
2) this experimental pooling code is a bit out of date. i did all
this before the switch to Subversion and it's lack recent updates made
to the main branch. it'd take some work to bring it up to date. and
3) i really would need a number of full days spent on veltools to be
able to get a release of our current code base out and/or get all this
stuff ready and tested better myself. 4) part of me would rather
spend time working on current bugs or trying out/considering recent
contributions sitting in the wiki than do the above
so here's a few related questions...
anyone thinking we should put a 1.2 out soon? what bugs should we
squish for that? are there any recent contributions many people would
like to see get in before 1.2 is released? is VelocityStruts up to
date with Struts 1.2.x? i've been pretty out of touch with that part
of the code lately.
is anyone else interested in tool pooling? yes/no/why/why-not?
would anyone else want to work on a 2.0 branch? i have a bunch of
experimental stuff i was playing with locally a few months ago
(pooling, pluggable toolbox loader, moving basic tool management to
generic level, etc). it's a bit out of date, but i might be up for
the work if i had some assurance of interest and assistance.
i'm just trying to get a feel for where people are at here.
> > And a suggestion on the same subject:
> >
> > Maybe we could have the syntax of the scope element be:
> > application | session | request | <url regexp>
> > in toolbox.xml to refine scopes at a thiner level than the request
> > scope.
>
> Sorry, but I'm not quite getting it. How would one use it? The <url
> regexp>, I mean.
yeah, i'm not sure on this either. i don't see how you could have or
would want a small scope than "request" when working with servlets.
if anything, i think it could be interesting to have a scope larger
than request and smaller than a session. that could be some sort of
keyed thing where tools would be shared amongst a group of requests
bearing the same key. in between the requests the tools could sit in
the session under the given key(s). i've half-toyed with the idea
before, but personally had no real use case for this.
nathan
> Best regards,
> -- Shinobu
>
> --
> Shinobu "Kawai" Yoshida <sh...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org