You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Gregory Steuck <gr...@nest.cx> on 2002/06/05 03:24:57 UTC
Requests, or Tokens, or Tickets, or PreparedLookups?
I really like Berin's suggestion re Requests. The only con, that Leo
already mentioned, is an extra indirection level and growth of the
code that uses such new component managers.
>>>>> "Peter" == Peter Donald <pe...@apache.org> writes:
>> That's a lot of Generator.ROLE + "/fooo"!
Peter> Put the key in a static at top of class (or cache it in
Peter> some other way) and that would be a lil better. Though
Peter> caching all strings would be a much better improvement
Peter> IMHO.
You still pay the price of hashing the string on lookups. I don't
think they keep the hash value in the String once calculated. And
since String is a final class you can't do anything about that.
Peter> Can you give me one solid reason why it needs to be done at
Peter> runtime in 99% of cases? I will grant you that runtime
Peter> assembly may be necessary when components looked up are
Peter> determined by request data but in other cases?
The component in question needs to be:
* expensive to construct
* single threaded
* often used for short periods of time
Can anybody name such a component? Something similar to a database
server will do ;-)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Requests, or Tokens, or Tickets, or Prepared Lookups?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> Peter Donald wrote:
>
> >
> >> > * Component/Service Manager should be more efficient (double
> >> > erk!!!!)
> >>
> >> It really does. Even if it is more efficient to *use* or develop
> >> against.
> >
> >
> > Your right - I will be more than happy to remove release() method
> > anytime now - that will save a whole bunch of people misusing CMs
and
> > then getting concerned that CMs don't match their use case.
>
>
> +1
-1 : Removes too much functionality for not enough gain. If people are
misusing CM, too bad. Even without a release() method you'll have
them do so.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Requests, or Tokens, or Tickets, or Prepared Lookups?
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
>
>> > * Component/Service Manager should be more efficient (double erk!!!!)
>>
>> It really does. Even if it is more efficient to *use* or develop
>> against.
>
>
> Your right - I will be more than happy to remove release() method
> anytime now - that will save a whole bunch of people misusing CMs and
> then getting concerned that CMs don't match their use case.
+1
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Requests, or Tokens, or Tickets, or Prepared Lookups?
Posted by Peter Donald <pe...@apache.org>.
At 09:56 AM 6/5/2002 -0400, you wrote:
> > Due to this we get into discussions such as
> > * Component/Service Manager should do pooling (erk!!!!)
>
>The Container needs to take care of that. Many containers do perform
>pooling (anybody ever here of EJBs, Servlets, DataSources, etc.?).
>We need to make the mechanism invisible to the user though.
Orthogonal concepts. Pooling, activation, passivation etc are all
orthogonal concepts to resource access. You can still do these all the time
without compromising resource access.
Consider JNDI - massively slow in most implementations. However that has
not limited scalability wrt to EJBs or servlets. In fact it has actually
encouraged scalability as the components that need efficient access to
underlying resources (DataSource for JDBC connections or Connector
architecture for other resource connections) all work fine.
> > * Component/Service Manager should be more efficient (double erk!!!!)
>
>It really does. Even if it is more efficient to *use* or develop
>against.
Your right - I will be more than happy to remove release() method anytime
now - that will save a whole bunch of people misusing CMs and then getting
concerned that CMs don't match their use case.
Seriously - go out into other frameworks and try to identify one which
mixes directory service with resource management. There isn't any software
systems that do this that I know off. So why do you think you know better
than the rest of these peeps? :)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Requests, or Tokens, or Tickets, or PreparedLookups?
Posted by Peter Donald <pe...@apache.org>.
At 12:01 PM 6/5/2002 -0700, you wrote:
> >>>>> "Peter" == Peter Donald <pe...@apache.org> writes:
>
> Peter> ie Consider the following example. When connecting to a
> Peter> database and you need to retrieve resources to access
> Peter> database from a service directory (whether that be
> Peter> ServiceManager, ComponentManager or JNDI Context
> Peter> etc).Should you
>
> Peter> a) Store the Connection object in service directory b)
> Peter> Store a DataSource in service directory
>
> Peter> Obviously most people are going to say (b) because it
> Peter> scales well and is simple to do.
>
>Somehow I feel DataSource is similar to Request that Berin proposes.
I don't think so - Request still makes resource management part of
directory service which is just plain wrong in my mind ;)
>Apparently you don't like the idea of embedding such mechanism into
>ComponentManager itself for it may foster sloppier design.
I think it is sloppy design in itself ;) But then again - me and Berin have
been arguing over this for about 2 years so I don't think either of is
going to change our minds right away though I think I have a better case
now than I did back when it started ;)
> Peter> and repeat for all performance sensitive operations. It
> Peter> would make cocoon sooo much faster and it would also mean
> Peter> we wouldn't have to keep making compromises in core parts
> Peter> of Avalon for what I consider to be bad use cases.
>
>I feel that profiling is in order to determine the performance impact
>of switching to Request architecture.
>
>Yesterday I realized that String hashing and comparisons (not
>construction though) may be of little relevance to performance. Don't
>you think synchronization to be a bigger performance drain?
depends on so many factors it is hard to say. Certain JVMs (suns not
hotspot) suck badly at synchronization while others suck at garbage
collection etc. The best way to do it is fire up JProfiler and have a look
at how much GC is occuring vs CPU time (I don't know of any profilers that
measure monitor contention though).
> I still think the change would be a boon if it reduces code as Berin
>demonstrated.
It would double the size of all my component accesses so I tend to not
think of it as good in that way ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Requests, or Tokens, or Tickets, or PreparedLookups?
Posted by Gregory Steuck <gr...@nest.cx>.
>>>>> "Peter" == Peter Donald <pe...@apache.org> writes:
Peter> ie Consider the following example. When connecting to a
Peter> database and you need to retrieve resources to access
Peter> database from a service directory (whether that be
Peter> ServiceManager, ComponentManager or JNDI Context
Peter> etc).Should you
Peter> a) Store the Connection object in service directory b)
Peter> Store a DataSource in service directory
Peter> Obviously most people are going to say (b) because it
Peter> scales well and is simple to do.
Somehow I feel DataSource is similar to Request that Berin proposes.
Apparently you don't like the idea of embedding such mechanism into
ComponentManager itself for it may foster sloppier design.
Peter> and repeat for all performance sensitive operations. It
Peter> would make cocoon sooo much faster and it would also mean
Peter> we wouldn't have to keep making compromises in core parts
Peter> of Avalon for what I consider to be bad use cases.
I feel that profiling is in order to determine the performance impact
of switching to Request architecture.
Yesterday I realized that String hashing and comparisons (not
construction though) may be of little relevance to performance. Don't
you think synchronization to be a bigger performance drain?
Synchronization is pretty much inevitable in a ComponentManager
implementation isn't it?
I still think the change would be a boon if it reduces code as Berin
demonstrated.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Requests, or Tokens, or Tickets, or PreparedLookups?
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> Hi,
>
> On Wed, 5 Jun 2002 11:24, Gregory Steuck wrote:
> > Peter> Can you give me one solid reason why it needs to
> be done at
> > Peter> runtime in 99% of cases? I will grant you that runtime
> > Peter> assembly may be necessary when components looked up are
> > Peter> determined by request data but in other cases?
> >
> > The component in question needs to be:
> >
> > * expensive to construct
> > * single threaded
> > * often used for short periods of time
> >
> > Can anybody name such a component? Something similar to a database
> > server will do ;-)
>
> Sounds like you are not designing with scalability in mind
> ... and thus it
> does'nt scale :)
>
> ie Consider the following example. When connecting to a
> database and you need
> to retrieve resources to access database from a service
> directory (whether
> that be ServiceManager, ComponentManager or JNDI Context
> etc).Should you
>
> a) Store the Connection object in service directory
> b) Store a DataSource in service directory
>
> Obviously most people are going to say (b) because it scales
> well and is
> simple to do. However time and time again I have heard people
> from Cocoon
> advocate an approach like (a) for their components.
I have tried to convince the Cocooners to do something more
along the lines of (b), but it is not an easy proposition
because of the number of people using it.
>
> Due to this we get into discussions such as
> * Component/Service Manager should do pooling (erk!!!!)
The Container needs to take care of that. Many containers do perform
pooling (anybody ever here of EJBs, Servlets, DataSources, etc.?).
We need to make the mechanism invisible to the user though.
> * Component/Service Manager should be more efficient (double erk!!!!)
It really does. Even if it is more efficient to *use* or develop
against. Believe it or not, the indirection I am proposing *saves*
on complexity and helps the new developer comprehend the code more
easily.
Try/Catch/Finally blocks are not friendly to newbies, and you need
a lot of experience to avoid nasty gotchas like catching Exception
before catching ComponentException. Veterans would laugh at the
concept, but I see newbies do it all the time.
> Can't you just create a service like
>
> interface GeneratorFactory
> {
> int getIdFor(String type);
> Generator createGenerator(int id);
> }
>
> and repeat for all performance sensitive operations. It would
> make cocoon sooo
> much faster and it would also mean we wouldn't have to keep making
> compromises in core parts of Avalon for what I consider to be
> bad use cases.
I am trying to accommodate both you and the cocoon people.
my proposal gets rid of the *Selector interface necessity.
However, what you might see more ready for Cocoon is this:
interface Generator
{
XMLSource getSource();
}
with implementations for the different generator types. It is
essentially the same thing, except the GeneratorFactory looks like
it might resolve any type of Generator.
I am trying to get to a place where we can all be happy.
Unfortunately, not everything is like a Phoenix app.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Requests, or Tokens, or Tickets, or PreparedLookups?
Posted by Peter Donald <pe...@apache.org>.
Hi,
On Wed, 5 Jun 2002 11:24, Gregory Steuck wrote:
> Peter> Can you give me one solid reason why it needs to be done at
> Peter> runtime in 99% of cases? I will grant you that runtime
> Peter> assembly may be necessary when components looked up are
> Peter> determined by request data but in other cases?
>
> The component in question needs to be:
>
> * expensive to construct
> * single threaded
> * often used for short periods of time
>
> Can anybody name such a component? Something similar to a database
> server will do ;-)
Sounds like you are not designing with scalability in mind ... and thus it
does'nt scale :)
ie Consider the following example. When connecting to a database and you need
to retrieve resources to access database from a service directory (whether
that be ServiceManager, ComponentManager or JNDI Context etc).Should you
a) Store the Connection object in service directory
b) Store a DataSource in service directory
Obviously most people are going to say (b) because it scales well and is
simple to do. However time and time again I have heard people from Cocoon
advocate an approach like (a) for their components.
Due to this we get into discussions such as
* Component/Service Manager should do pooling (erk!!!!)
* Component/Service Manager should be more efficient (double erk!!!!)
Can't you just create a service like
interface GeneratorFactory
{
int getIdFor(String type);
Generator createGenerator(int id);
}
and repeat for all performance sensitive operations. It would make cocoon sooo
much faster and it would also mean we wouldn't have to keep making
compromises in core parts of Avalon for what I consider to be bad use cases.
--
Cheers,
Peter Donald
*------------------------------------------------*
| The student who is never required to do what |
| he cannot do never does what he can do. |
| - John Stuart Mill |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Requests, or Tokens, or Tickets, or PreparedLookups?
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 05 June 2002 09:42 am, Berin Loritsch wrote:
> > java.lang.String does cache a computer hash value, fyi.
blah. "the computed"
> Did you check the source code?
yes.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Requests, or Tokens, or Tickets, or PreparedLookups?
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Royal [mailto:proyal@apache.org]
> Sent: Tuesday, June 04, 2002 9:30 PM
> To: Avalon Developers List
> Subject: Re: Requests, or Tokens, or Tickets, or PreparedLookups?
>
>
> On Tuesday 04 June 2002 09:24 pm, Gregory Steuck wrote:
> > You still pay the price of hashing the string on lookups. I don't
> > think they keep the hash value in the String once calculated. And
> > since String is a final class you can't do anything about that.
>
> java.lang.String does cache a computer hash value, fyi.
Did you check the source code?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Requests, or Tokens, or Tickets, or PreparedLookups?
Posted by Peter Royal <pr...@apache.org>.
On Tuesday 04 June 2002 09:24 pm, Gregory Steuck wrote:
> You still pay the price of hashing the string on lookups. I don't
> think they keep the hash value in the String once calculated. And
> since String is a final class you can't do anything about that.
java.lang.String does cache a computer hash value, fyi.
> The component in question needs to be:
>
> * expensive to construct
> * single threaded
> * often used for short periods of time
>
> Can anybody name such a component? Something similar to a database
> server will do ;-)
Since Cocoon is our fav. intensive app, all of its pipeline components are
single-threaded :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Requests, or Tokens, or Tickets, or PreparedLookups?
Posted by Berin Loritsch <bl...@apache.org>.
> From: Gregory Steuck [mailto:greg-avalon-dev@nest.cx]
>
>
> I really like Berin's suggestion re Requests. The only con,
> that Leo already mentioned, is an extra indirection level and
> growth of the code that uses such new component managers.
Actually, the code shrinks. We are trading one method call for
a bunch of exception handling code. The tradeoff is in favor of
the indirection!
>
> >>>>> "Peter" == Peter Donald <pe...@apache.org> writes:
>
> >> That's a lot of Generator.ROLE + "/fooo"!
>
> Peter> Put the key in a static at top of class (or cache it in
> Peter> some other way) and that would be a lil better. Though
> Peter> caching all strings would be a much better improvement
> Peter> IMHO.
>
> You still pay the price of hashing the string on lookups. I
> don't think they keep the hash value in the String once
> calculated. And since String is a final class you can't do
> anything about that.
It doesn't. I've looked at the source code. For an object that
isn't supposed to change (String is supposed to represent a static
value), I find that quite amazing.
>
> Peter> Can you give me one solid reason why it needs to be done at
> Peter> runtime in 99% of cases? I will grant you that runtime
> Peter> assembly may be necessary when components looked up are
> Peter> determined by request data but in other cases?
>
> The component in question needs to be:
>
> * expensive to construct
> * single threaded
> * often used for short periods of time
>
> Can anybody name such a component? Something similar to a
> database server will do ;-)
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>