You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Felix Knecht <fe...@otego.com> on 2007/03/05 13:32:01 UTC

Configuration of RunnableManager

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I wonder how to create/add my own configuration for the
RunnableManager. At the moment, the given configuration is included in
the deployed jar file (having configured 2 pools (default,daemon)).
Changing this configuration seems not that easy as I need to 'patch'
the existing configuration in the deployed jar file.

Making configuration easier I'd prefer the the 'New Features for the
spring configurator' and introduce a new bean just containing the
configuration data for a pool which implementing a specific (helper)
interface. Thus everybody can add his own threadpool configuration.
The RunnableManager then will create thread pools for all found beans
implementing this (helper) interface.

Configuration could then look as following:

 <bean name="org.apache.cocoon.components.thread.RunnableManager"
        class="org.apache.cocoon.components.thread.DefaultRunnableManager"
        scope="singleton" init-method="init" destroy-method="destroy">
    <property name="threadFactory"
value="org.apache.cocoon.components.thread.DefaultThreadFactory"/>
    <property name="threadPools">
        <configurator:bean-map
type="org.apache.cocoon.components.thread.ThreadPoolConfig" />
    </property>
</bean>


<bean
id="org.apache.cocoon.components.thread.ThreadPoolConfig/default"
class="org.apache.cocoon.components.thread.ThreadPoolConfigImpl">
       <property name="name" value="default"/>
       <property name="priority" value="NORM"/>
       <property name="daemon" value="false"/>
       <property name="queue-size" value="-1"/>
       <property name="max-pool-size" value="5"/>
       <property name="min-pool-size" value="5"/>
       <property name="keep-alive-time-ms" value="60000"/>
       <property name="block-policy" value="ABORT"/>
       <property name="shutdown-graceful" value="false"/>
       <property name="shutdown-wait-time-ms" value="-1"/>
</bean>

<bean id="org.apache.cocoon.components.thread.ThreadPoolConfig/daemon"
class="org.apache.cocoon.components.thread.ThreadPoolConfigImpl">
    <snip />
</bean>


<bean id="org.apache.cocoon.components.thread.ThreadPoolConfig/MyPool"
class="org.apache.cocoon.components.thread.ThreadPoolConfigImpl">
    <snip />
</bean>


I will write a patch if I'm not the only one having this problem and I
get a positive feedback on this.

Regards
Felix

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF7A3B2lZVCB08qHERAqy6AJwOENR7A+FhZWIEok1APe+hOk6oMgCfbsi9
tZT41dnSlTyv3P+4QN3C10Q=
=Q/E6
-----END PGP SIGNATURE-----


Re: Configuration of RunnableManager

Posted by Felix Knecht <fe...@otego.com>.
Reinhard Poetz schrieb:
> Felix Knecht wrote:
>> Thanks Vadim, I'll go on with this.
>>
>> IIRC the interfaces of the core block are stable(freezed) because of RC1. 
> 
> No, they will be freezed *after* RC1 was released. (At least that's my 
> understanding.)
> 

If the API isn't freezed yet I suggest to change it.

Felix

Re: Configuration of RunnableManager

Posted by Reinhard Poetz <re...@apache.org>.
Felix Knecht wrote:
> Thanks Vadim, I'll go on with this.
> 
> IIRC the interfaces of the core block are stable(freezed) because of 
> RC1. 

No, they will be freezed *after* RC1 was released. (At least that's my 
understanding.)

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Re: Configuration of RunnableManager

Posted by Felix Knecht <fe...@otego.com>.
Thanks Vadim, I'll go on with this.

IIRC the interfaces of the core block are stable(freezed) because of 
RC1. Therefor I'm going to introduce a new RunnableManager called 
ConfigurableRunnableManager which is heavy based on the 
DefaultRunnableManager (otherwise I'd need to change the bean 
configuration/interface of the DefaultRunnableManager).

Felix


> Felix Knecht wrote:
>> I wonder how to create/add my own configuration for the
>> RunnableManager. At the moment, the given configuration is included in
>> the deployed jar file (having configured 2 pools (default,daemon)).
>> Changing this configuration seems not that easy as I need to 'patch'
>> the existing configuration in the deployed jar file.
>>
>> Making configuration easier I'd prefer the the 'New Features for the
>> spring configurator' and introduce a new bean just containing the
>> configuration data for a pool which implementing a specific (helper)
>> interface. Thus everybody can add his own threadpool configuration.
>> The RunnableManager then will create thread pools for all found beans
>> implementing this (helper) interface.
>>
>> Configuration could then look as following:
>>
>>  <bean name="org.apache.cocoon.components.thread.RunnableManager"
>>         
>> class="org.apache.cocoon.components.thread.DefaultRunnableManager"
>>         scope="singleton" init-method="init" destroy-method="destroy">
>>     <property name="threadFactory"
>> value="org.apache.cocoon.components.thread.DefaultThreadFactory"/>
>>     <property name="threadPools">
>>         <configurator:bean-map
>> type="org.apache.cocoon.components.thread.ThreadPoolConfig" />
>>     </property>
>> </bean>
>>
>>
>> <bean
>> id="org.apache.cocoon.components.thread.ThreadPoolConfig/default"
>> class="org.apache.cocoon.components.thread.ThreadPoolConfigImpl">
>>        <property name="name" value="default"/>
>>        <property name="priority" value="NORM"/>
>>        <property name="daemon" value="false"/>
>>        <property name="queue-size" value="-1"/>
>>        <property name="max-pool-size" value="5"/>
>>        <property name="min-pool-size" value="5"/>
>>        <property name="keep-alive-time-ms" value="60000"/>
>>        <property name="block-policy" value="ABORT"/>
>>        <property name="shutdown-graceful" value="false"/>
>>        <property name="shutdown-wait-time-ms" value="-1"/>
>> </bean>
>>
>> <bean id="org.apache.cocoon.components.thread.ThreadPoolConfig/daemon"
>> class="org.apache.cocoon.components.thread.ThreadPoolConfigImpl">
>>     <snip />
>> </bean>
>>
>>
>> <bean id="org.apache.cocoon.components.thread.ThreadPoolConfig/MyPool"
>> class="org.apache.cocoon.components.thread.ThreadPoolConfigImpl">
>>     <snip />
>> </bean>
>>
>>
>> I will write a patch if I'm not the only one having this problem and I
>> get a positive feedback on this.
> 
> This looks like a sensible approach to me. +1
> 
> Vadim
> 


Re: Configuration of RunnableManager

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Felix Knecht wrote:
> I wonder how to create/add my own configuration for the
> RunnableManager. At the moment, the given configuration is included in
> the deployed jar file (having configured 2 pools (default,daemon)).
> Changing this configuration seems not that easy as I need to 'patch'
> the existing configuration in the deployed jar file.
> 
> Making configuration easier I'd prefer the the 'New Features for the
> spring configurator' and introduce a new bean just containing the
> configuration data for a pool which implementing a specific (helper)
> interface. Thus everybody can add his own threadpool configuration.
> The RunnableManager then will create thread pools for all found beans
> implementing this (helper) interface.
> 
> Configuration could then look as following:
> 
>  <bean name="org.apache.cocoon.components.thread.RunnableManager"
>         class="org.apache.cocoon.components.thread.DefaultRunnableManager"
>         scope="singleton" init-method="init" destroy-method="destroy">
>     <property name="threadFactory"
> value="org.apache.cocoon.components.thread.DefaultThreadFactory"/>
>     <property name="threadPools">
>         <configurator:bean-map
> type="org.apache.cocoon.components.thread.ThreadPoolConfig" />
>     </property>
> </bean>
> 
> 
> <bean
> id="org.apache.cocoon.components.thread.ThreadPoolConfig/default"
> class="org.apache.cocoon.components.thread.ThreadPoolConfigImpl">
>        <property name="name" value="default"/>
>        <property name="priority" value="NORM"/>
>        <property name="daemon" value="false"/>
>        <property name="queue-size" value="-1"/>
>        <property name="max-pool-size" value="5"/>
>        <property name="min-pool-size" value="5"/>
>        <property name="keep-alive-time-ms" value="60000"/>
>        <property name="block-policy" value="ABORT"/>
>        <property name="shutdown-graceful" value="false"/>
>        <property name="shutdown-wait-time-ms" value="-1"/>
> </bean>
> 
> <bean id="org.apache.cocoon.components.thread.ThreadPoolConfig/daemon"
> class="org.apache.cocoon.components.thread.ThreadPoolConfigImpl">
>     <snip />
> </bean>
> 
> 
> <bean id="org.apache.cocoon.components.thread.ThreadPoolConfig/MyPool"
> class="org.apache.cocoon.components.thread.ThreadPoolConfigImpl">
>     <snip />
> </bean>
> 
> 
> I will write a patch if I'm not the only one having this problem and I
> get a positive feedback on this.

This looks like a sensible approach to me. +1

Vadim


Re: Configuration of RunnableManager

Posted by Felix Knecht <fe...@otego.com>.
After some discussions I think also, that Giacomos suggestion is a good
way to go. So I will change
https://issues.apache.org/jira/browse/COCOON-2019 to go in this direction.

Felix

> Giacomo Pati schrieb:
>> Hi Felix
> 
>> Felix Knecht wrote:
>>> I wonder how to create/add my own configuration for the
>>> RunnableManager. At the moment, the given configuration is
>>> included in the deployed jar file (having configured 2 pools
>>> (default,daemon)). Changing this configuration seems not that
>>> easy as I need to 'patch' the existing configuration in the
>>> deployed jar file.
>>> Making configuration easier I'd prefer the the 'New Features for
>>> the spring configurator' and introduce a new bean just containing
>>> the configuration data for a pool which implementing a specific
>>> (helper) interface. Thus everybody can add his own threadpool
>>> configuration. The RunnableManager then will create thread pools
>>> for all found beans implementing this (helper) interface.
>> I'd suggest instead of only breaking out the configuration of a
>> thread pool, break out the hole thread pool itself into a bean.
>> This would reduce the complexity of the RunnableManager and would
>> make the ThreadPool beans have a little more responsability than
>> just holding config values.
> 
>> WDYT?
> 
> 
> This would make things easier for blocks needing just a threadpool
> (like the cron block).
> 
> On the otherhand its possible, that the RunnableManager must share a
> pool with anything else, because all Threadpool beans would be loaded
> into the runnable manager. This must be kept in mind when configuring
> the pool. Adding an optional flag to the threadpool bean indicating if
> the pool can should be used in the RunnableManager could solve this
> problem.
> 
> Felix
> 

Re: Configuration of RunnableManager

Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Felix Knecht wrote:
> Giacomo Pati schrieb:
>> Hi Felix
> 
>> Felix Knecht wrote:
>>> I wonder how to create/add my own configuration for the
>>> RunnableManager. At the moment, the given configuration is
>>> included in the deployed jar file (having configured 2 pools
>>> (default,daemon)). Changing this configuration seems not that
>>> easy as I need to 'patch' the existing configuration in the
>>> deployed jar file.
>>> Making configuration easier I'd prefer the the 'New Features for
>>> the spring configurator' and introduce a new bean just containing
>>> the configuration data for a pool which implementing a specific
>>> (helper) interface. Thus everybody can add his own threadpool
>>> configuration. The RunnableManager then will create thread pools
>>> for all found beans implementing this (helper) interface.
>> I'd suggest instead of only breaking out the configuration of a
>> thread pool, break out the hole thread pool itself into a bean.
>> This would reduce the complexity of the RunnableManager and would
>> make the ThreadPool beans have a little more responsability than
>> just holding config values.
> 
>> WDYT?
> 
> 
> This would make things easier for blocks needing just a threadpool
> (like the cron block).
> 
> On the otherhand its possible, that the RunnableManager must share a
> pool with anything else, because all Threadpool beans would be loaded
> into the runnable manager. This must be kept in mind when configuring
> the pool. Adding an optional flag to the threadpool bean indicating if
> the pool can should be used in the RunnableManager could solve this
> problem.

I cannot see how a flag helps here (keep in mind you'd probably inject the map of ThreadPools into
RunnableManager). Is it the RunnableManager that has to respect such a flag when a request to run
something is issued requesting a ThreadPool having that flag?

- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.2 (GNU/Linux)

iD8DBQFF7UpSLNdJvZjjVZARAmUEAKCyVnjyLSMzWdGIEoLJgvvCsbbakACg3ETj
nCys8JAgnwlCAgSPhFBHFH0=
=t2F4
-----END PGP SIGNATURE-----

Re: Configuration of RunnableManager

Posted by Felix Knecht <fe...@otego.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Giacomo Pati schrieb:
> Hi Felix
>
> Felix Knecht wrote:
>> I wonder how to create/add my own configuration for the
>> RunnableManager. At the moment, the given configuration is
>> included in the deployed jar file (having configured 2 pools
>> (default,daemon)). Changing this configuration seems not that
>> easy as I need to 'patch' the existing configuration in the
>> deployed jar file.
>
>> Making configuration easier I'd prefer the the 'New Features for
>> the spring configurator' and introduce a new bean just containing
>> the configuration data for a pool which implementing a specific
>> (helper) interface. Thus everybody can add his own threadpool
>> configuration. The RunnableManager then will create thread pools
>> for all found beans implementing this (helper) interface.
>
> I'd suggest instead of only breaking out the configuration of a
> thread pool, break out the hole thread pool itself into a bean.
> This would reduce the complexity of the RunnableManager and would
> make the ThreadPool beans have a little more responsability than
> just holding config values.
>
> WDYT?
>

This would make things easier for blocks needing just a threadpool
(like the cron block).

On the otherhand its possible, that the RunnableManager must share a
pool with anything else, because all Threadpool beans would be loaded
into the runnable manager. This must be kept in mind when configuring
the pool. Adding an optional flag to the threadpool bean indicating if
the pool can should be used in the RunnableManager could solve this
problem.

Felix

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF7UH+2lZVCB08qHERAp7iAKCmMi1r5CfZmiKcLVXNPRyk7IpSOQCgz0ib
V74UwgrBPhc/wvtl1cdikGQ=
=lY3m
-----END PGP SIGNATURE-----


Re: Configuration of RunnableManager

Posted by Giacomo Pati <gi...@otego.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Felix

Felix Knecht wrote:
> I wonder how to create/add my own configuration for the
> RunnableManager. At the moment, the given configuration is included in
> the deployed jar file (having configured 2 pools (default,daemon)).
> Changing this configuration seems not that easy as I need to 'patch'
> the existing configuration in the deployed jar file.
> 
> Making configuration easier I'd prefer the the 'New Features for the
> spring configurator' and introduce a new bean just containing the
> configuration data for a pool which implementing a specific (helper)
> interface. Thus everybody can add his own threadpool configuration.
> The RunnableManager then will create thread pools for all found beans
> implementing this (helper) interface.

I'd suggest instead of only breaking out the configuration of a thread pool, break out the hole
thread pool itself into a bean. This would reduce the complexity of the RunnableManager and would
make the ThreadPool beans have a little more responsability than just holding config values.

WDYT?

Ciao

>         <configurator:bean-map
> type="org.apache.cocoon.components.thread.ThreadPoolConfig" />
>     </property>
> </bean>
> 
> 
> <bean
> id="org.apache.cocoon.components.thread.ThreadPoolConfig/default"
> class="org.apache.cocoon.components.thread.ThreadPoolConfigImpl">
>        <property name="name" value="default"/>
>        <property name="priority" value="NORM"/>
>        <property name="daemon" value="false"/>
>        <property name="queue-size" value="-1"/>
>        <property name="max-pool-size" value="5"/>
>        <property name="min-pool-size" value="5"/>
>        <property name="keep-alive-time-ms" value="60000"/>
>        <property name="block-policy" value="ABORT"/>
>        <property name="shutdown-graceful" value="false"/>
>        <property name="shutdown-wait-time-ms" value="-1"/>
> </bean>
> 
> <bean id="org.apache.cocoon.components.thread.ThreadPoolConfig/daemon"
> class="org.apache.cocoon.components.thread.ThreadPoolConfigImpl">
>     <snip />
> </bean>
> 
> 
> <bean id="org.apache.cocoon.components.thread.ThreadPoolConfig/MyPool"
> class="org.apache.cocoon.components.thread.ThreadPoolConfigImpl">
>     <snip />
> </bean>
> 
> 
> I will write a patch if I'm not the only one having this problem and I
> get a positive feedback on this.
> 
> Regards
> Felix
> 

- --
Otego AG                                  Tel:   +41 (0)1  240 00 55
Giacomo Pati, CTO                         Mobile:+41 (0)79 262 21 04
Apache Software Foundation Member         Mailto:giacomo@apache.org
Hohlstrasse 216                           Mailto:Giacomo.Pati@otego.com
CH-8004 Zuerich                           http://www.otego.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.2 (GNU/Linux)

iD8DBQFF7RPpLNdJvZjjVZARAmaxAKCu16RwJP9CiPDZ3NzH1a7buxiBpwCcCOmT
1uWov1o/rgnNy8f6guqeKss=
=1ozv
-----END PGP SIGNATURE-----