You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Fernando Padilla <fe...@interdimensions.com> on 2004/01/02 15:59:33 UTC
BlockThread
Is there any reason why a new Thread is created and then kept around doing
and endless sleep loop ( sleeping for measely 300 millisec ), for every
block instanciation?
Could we have the sleep loop be longer ( 10 sec ), and use interrupt to
wake it up out of sleep if need be?
Could we create a thread for assembly, then another for disassembly?
(if we have the same classloader, this should work right?)
just asking :) One possible way to design my application is that all
"plugins" are blocks ( make sense ), but that doesn't make since if I'm
having many,many "plugins" ( like 1000s, but even 100s of threads is not
a good idea!! )
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: BlockThread
Posted by Berin Loritsch <bl...@apache.org>.
Fernando Padilla wrote:
> Is there any reason why a new Thread is created and then kept around doing
> and endless sleep loop ( sleeping for measely 300 millisec ), for every
> block instanciation?
>
> Could we have the sleep loop be longer ( 10 sec ), and use interrupt to
> wake it up out of sleep if need be?
>
> Could we create a thread for assembly, then another for disassembly?
> (if we have the same classloader, this should work right?)
>
>
> just asking :) One possible way to design my application is that all
> "plugins" are blocks ( make sense ), but that doesn't make since if I'm
> having many,many "plugins" ( like 1000s, but even 100s of threads is not
> a good idea!! )
Hmm. That is not a good idea for sure. The solution used by Fortress to
handle management issues like this is to use the CommandManager from the
Excalibur Event package. Essentially, you can have many many commands and
a managed number of threads to do all the work. I use a repeating command
to give the illusion of a thread locked for each item needing attention,
but it only is executed after a configurable time.
Perhaps we need to adopt that for plugin management as well....
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: BlockThread
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 03 January 2004 07:36, Stephen McConnell wrote:
> Niclas Hedhman wrote:
> > This is _NOT GOOD_, I know that, and I think Steve knows it by now, and I
> > will change it later for sure,
> I'm buried deep in model listeners and notifiers and I'm unlikely to
> even thing about the thread stuff any time soon so if you want to jump
> in do something on this - go for it. I've already tagged CVS against
> the 3.2.3 release so applying any changes to HEAD is not problem.
Ok, I will try to dive into it today and tomorrow.
I will do my own "First Suggestion" with the Thread's ContextClassLoader
untouched and undefined.
Debate will clarify this later.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: BlockThread
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
> On Friday 02 January 2004 22:59, Fernando Padilla wrote:
>
>>Is there any reason why a new Thread is created and then kept around doing
>>and endless sleep loop ( sleeping for measely 300 millisec ), for every
>>block instanciation?
>
>
> This is _NOT GOOD_, I know that, and I think Steve knows it by now, and I will
> change it later for sure, if he doesn't do it before me, but I/we didn't want
> to hold up the release this way around for that.
Niclas:
I'm buried deep in model listeners and notifiers and I'm unlikely to
even thing about the thread stuff any time soon so if you want to jump
in do something on this - go for it. I've already tagged CVS against
the 3.2.3 release so applying any changes to HEAD is not problem.
Cheers, Steve.
> The rationale/intention behind this design is a bit flawed, but centers around
> assigning the Block Classloader to the Thread's ContextClassloader, but the
> intention is not fulfilled...
>
> I can promise that by 3.3 this will have get rectified. :o)
>
>
> Niclas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: BlockThread
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 03 January 2004 14:39, Niclas Hedhman wrote:
> On Saturday 03 January 2004 13:49, Niclas Hedhman wrote:
> > Argument in favour of doing 2.
> > ==============================
> > So far I have only heard "people normally does;"
>
> It seems that a fair number of avalon-excalibur and avalon-components
> components are using the Thread.currentThread().getContextClassLoader(),
> and I think in many instances this usage is outright incorrect, for
> instance;
To get the right perspective, there are MORE components doing what they are
supposed to do in our repositories. Too numerous to look at details in all
the cases...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: BlockThread
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 03 January 2004 13:49, Niclas Hedhman wrote:
> Argument in favour of doing 2.
> ==============================
> So far I have only heard "people normally does;"
It seems that a fair number of avalon-excalibur and avalon-components
components are using the Thread.currentThread().getContextClassLoader(), and
I think in many instances this usage is outright incorrect, for instance;
in org.apache.avalon.cornerstone.blocks.datasources.DefaultDataSourceSelector
we find the following snippet in initialize();
final Configuration dataSourceConf = dataSourceConfs[ i ];
final String name = dataSourceConf.getAttribute( "name" );
final String clazz = dataSourceConf.getAttribute( "class" );
final String driver = dataSourceConf.getChild( "driver", true
).getValue( "" );
final ClassLoader classLoader =
Thread.currentThread().getContextClassLoader();
DataSourceComponent component = null;
if( null == classLoader )
{
if( !"".equals( driver ) )
{
Class.forName( driver, true,
Thread.currentThread().getContextClassLoader() );
}
component = (DataSourceComponent)Class.forName( clazz
).newInstance();
}
else
{
if( !"".equals( driver ) )
{
classLoader.loadClass( driver );
}
component = (DataSourceComponent)classLoader.loadClass( clazz
).newInstance();
}
To me it is apparent that the Author have no clue what he/she is doing in
respect to Classloaders, or actually more likely that there was a change at
some point;
If this returns null;
final ClassLoader classLoader =
Thread.currentThread().getContextClassLoader();
why would I not pass "null" directly in the CL argument in;
Class.forName( driver, true,
Thread.currentThread().getContextClassLoader() );
Also, isn't it reasonable that the Classloader for JDBC driver to either be
loaded by the same classloader as the DataSourceSelector or one of its
ancestors, for instance the Extension Classloader?
I think so. In Merlin this is very much the case.
HOWEVER, Is the above some kind of MEGA FIX for problems in ECM, Phoenix
and/or Fortress, or is it just "cruft" that should be made right once and for
all?
How about all the other components that has a similar setup (heaps of them in
our repository and I guess a lot "out there")??
Is Legacy support THAT important?
IMHO, we should tighten the contract and add strong semantics to the thread
context classloader, and incorrect use is a BUG which then needs fixing.
Better to do it now, when Merlin is not that widespread.
Any "historian" care to shed some light?
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: BlockThread
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 03 January 2004 04:43, Noel J. Bergman wrote:
> Niclas Hedhman wrote:
> > The rationale/intention behind this design is a bit flawed, but
> > centers around assigning the Block Classloader to the Thread's
> > ContextClassloader, but the intention is not fulfilled...
>
> Would the easiest change be to set it up so that a Block's Classloader is
> assigned to a Thread's ContextClassloader when dispatching that thread from
> a pool to perform work on that Block?
1. No new thread for each Block.
2. A debate whether the Thread's ContextClassLoader should actually be set to
the Block's classloader, before any call to the LifeCycle methods and/or any
call to the service interface methods.
Argument in favour of NOT doing 2.
==================================
Any code that tries to locate resources, images, classes, resource bundles or
whatever, should do;
ClassLoader cl = this.getClass().getClassLoader();
This ALWAYS guarantees that the resources assoicated with the Block/component
is available in the expected way.
It also leave the ContextClassLoader usage open for "other things", for
instance, global resources, resources defined in a "context" such as a
servlet environment, and so on.
Argument in favour of doing 2.
==============================
So far I have only heard "people normally does;"
ClassLoader cl = Thread.currentThread().getContextClassLoader();
But this is partly true in non-well-defined classloading architectures, where
often the "component" belongs to a higher level classloader, but is passed
"stuff" which resides in lower level Classloaders, for instance, Swing is
part of the Bootstrap classloader, and when it is given a new L&F it must
read resources in that L&F's classloader, which is typically the System
classloader.
So we must ask ourselves;
Do WE have use-cases where "inner blocks" will pass resources/classes/stuff to
its Outer blocks or blocks in other branches??
If we DO have such use-case, things get complicated, because if the Thread
ContextClassloader is set in the Proxy's service interface methods, the above
won't work either. It must then be that the context classloader is ONLY set
at the "lowest" entry level in each container branch. But that will still
makes the resources unreachable across lowest-level components in different
branches.
Bottomline, IMVNSHO, the ContextClassloader SHOULD NOT be set for the
LifeCycle method calls, NOR for the service interface method calls. And that
we MAY discover later what it should be set to, so for now it is left
"undefined" and any usage until then is an explicit "violation of contract".
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: BlockThread
Posted by "Noel J. Bergman" <no...@devtech.com>.
Niclas Hedhman wrote:
> The rationale/intention behind this design is a bit flawed, but
> centers around assigning the Block Classloader to the Thread's
> ContextClassloader, but the intention is not fulfilled...
Would the easiest change be to set it up so that a Block's Classloader is
assigned to a Thread's ContextClassloader when dispatching that thread from
a pool to perform work on that Block?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: BlockThread
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 02 January 2004 22:59, Fernando Padilla wrote:
> Is there any reason why a new Thread is created and then kept around doing
> and endless sleep loop ( sleeping for measely 300 millisec ), for every
> block instanciation?
This is _NOT GOOD_, I know that, and I think Steve knows it by now, and I will
change it later for sure, if he doesn't do it before me, but I/we didn't want
to hold up the release this way around for that.
The rationale/intention behind this design is a bit flawed, but centers around
assigning the Block Classloader to the Thread's ContextClassloader, but the
intention is not fulfilled...
I can promise that by 3.3 this will have get rectified. :o)
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org