You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2006/07/13 15:33:48 UTC
[TC6] Cluster and storeconfig
Hi,
I think it's the right time to add the storeconfig code, as well as a
clustering implementation (so, which one ?).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [TC6] Cluster and storeconfig
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Remy and Filip,
overwhelmed is much more correct than uncomfortable. I think looking at
how much work Filip has put into it since it's beginnings, it was good
to not immediately change the default implementation for TC 5.5 when
Filip started.
As Filip thinks it's ready for TC 6, I will happily dig into the new
code and it's functionality. I'm sure Peter will do as well, but he is
on holidays for a few more days.
Congrats to Filip for ha/groupcom.
Rainer
Filip Hanik - Dev Lists schrieb:
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>>> definitely the modules/ha and modules/groupcom.
>>> I'd like to clean it up first though, my idea is to instead of
>>> configuing all the messaging inside the <Cluster> element, the actual
>>> Tribes impl I'd rather configure as a JNDI resource,
>>> this has a some benefits, to mention a few
>>> - more components can take advantage of it, such as monitoring tools,
>>> other cluster implementations etc
>>> - Avoid having a giant blog that takes up half of server.xml when
>>> clustering is turned on
>>> - Separate out IO tuning from replication configuration
>>>
>>> I know in the past other people felt the need for these to be
>>> modules, for me I dont care either way, I think it might be good for
>>> us to get a consensus before I merge it in.
>>>
>>> You mind sitting a couple of weeks on it and let folks chime in while
>>> I work on the config separation?
>>
>> The problem I have is that the other persons who contributed heavily
>> to clustering seem quite uncomfortable (or at the very least,
>> overwhelmed) with the new implementation at the moment. Personally, I
>> also prefer a server.xml configuration.
> Then its probably wise of use to let this sit for a couple of weeks and
> hash it out. The replication logic hasn't changed, its the underlying
> messaging that has been separated out logically.
>
> Filip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [TC6] Cluster and storeconfig
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> definitely the modules/ha and modules/groupcom.
>> I'd like to clean it up first though, my idea is to instead of
>> configuing all the messaging inside the <Cluster> element, the actual
>> Tribes impl I'd rather configure as a JNDI resource,
>> this has a some benefits, to mention a few
>> - more components can take advantage of it, such as monitoring tools,
>> other cluster implementations etc
>> - Avoid having a giant blog that takes up half of server.xml when
>> clustering is turned on
>> - Separate out IO tuning from replication configuration
>>
>> I know in the past other people felt the need for these to be
>> modules, for me I dont care either way, I think it might be good for
>> us to get a consensus before I merge it in.
>>
>> You mind sitting a couple of weeks on it and let folks chime in while
>> I work on the config separation?
>
> The problem I have is that the other persons who contributed heavily
> to clustering seem quite uncomfortable (or at the very least,
> overwhelmed) with the new implementation at the moment. Personally, I
> also prefer a server.xml configuration.
Then its probably wise of use to let this sit for a couple of weeks and
hash it out. The replication logic hasn't changed, its the underlying
messaging that has been separated out logically.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Mod_jk : function maintain()
Posted by Mladen Turk <mt...@apache.org>.
Jean-frederic Clere wrote:
>>
>> If you finish your maintenance module then it'll
>> be his responsibility to make a heartbeat independent
>> of the request, on the regular intervals.
>
> Sure I need an extra program to make a real heartbeat but I still still
> don't see how I could close a socket in a httpd son if it doesn't get a
> request.
>
By adding additional signal to the mpm for maintenance.
Right now most mpm's have two: shutdown and gracefull.
Additional maintenance will do the trick.
Of course, the other solution is to launch an additional
thread on child_init that will monitor the scoreboard
and do the maintenance. Little bit unusable for
prefork I'm afraid.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Mod_jk : function maintain()
Posted by Jean-frederic Clere <jf...@gmail.com>.
Mladen Turk wrote:
> Jean-frederic Clere wrote:
>
>> Rainer Jung wrote:
>>
>>> It's called once a minute (at least if a request comes in) to be
>>> able to
>>> clean up things not directly related to the actual request, like
>>> closing
>>> idle connections.
>>>
>>>
>> Something to add to mod_proxy probably.
>>
>
> If you finish your maintenance module then it'll
> be his responsibility to make a heartbeat independent
> of the request, on the regular intervals.
Sure I need an extra program to make a real heartbeat but I still still
don't see how I could close a socket in a httpd son if it doesn't get a
request.
> The problem with wc_maintain is burst load where
> you actually don't need maintain, but it happens
> anyhow, so the connection can be closed and then
> created again.
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Mod_jk : function maintain()
Posted by Mladen Turk <mt...@apache.org>.
Jean-frederic Clere wrote:
> Rainer Jung wrote:
>
>> It's called once a minute (at least if a request comes in) to be able to
>> clean up things not directly related to the actual request, like closing
>> idle connections.
>>
>>
> Something to add to mod_proxy probably.
>
If you finish your maintenance module then it'll
be his responsibility to make a heartbeat independent
of the request, on the regular intervals.
The problem with wc_maintain is burst load where
you actually don't need maintain, but it happens
anyhow, so the connection can be closed and then
created again.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Mod_jk : function maintain()
Posted by Jean-frederic Clere <jf...@gmail.com>.
Rainer Jung wrote:
>It's called once a minute (at least if a request comes in) to be able to
>clean up things not directly related to the actual request, like closing
>idle connections.
>
>
Something to add to mod_proxy probably.
Cheers
Jean-Frederic
>gaston.azerty@free.fr schrieb:
>
>
>>Hi,
>>
>>I'm currently working in mod_jk in order to add a particular mechanism, in this
>>work I have to understand the structure and the behavior of the different
>>workers (status, lb,...).
>>
>>So I spend my time in the reverse engineering of mod_jk... An for example I
>>don't really understand the meaning of the function wc_maintain in the
>>jk_worker.c file.
>>
>>Any help will is greatly appreciated.
>>
>>Thanks
>>
>>Thomas d'Erceville
>>
>>PS : If you know a version of mod_jk source code with comments for the
>>functions, I will appreciate.
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Mod_jk : function maintain()
Posted by Rainer Jung <ra...@kippdata.de>.
It's called once a minute (at least if a request comes in) to be able to
clean up things not directly related to the actual request, like closing
idle connections.
gaston.azerty@free.fr schrieb:
> Hi,
>
> I'm currently working in mod_jk in order to add a particular mechanism, in this
> work I have to understand the structure and the behavior of the different
> workers (status, lb,...).
>
> So I spend my time in the reverse engineering of mod_jk... An for example I
> don't really understand the meaning of the function wc_maintain in the
> jk_worker.c file.
>
> Any help will is greatly appreciated.
>
> Thanks
>
> Thomas d'Erceville
>
> PS : If you know a version of mod_jk source code with comments for the
> functions, I will appreciate.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Mod_jk : function maintain()
Posted by ga...@free.fr.
Hi,
I'm currently working in mod_jk in order to add a particular mechanism, in this
work I have to understand the structure and the behavior of the different
workers (status, lb,...).
So I spend my time in the reverse engineering of mod_jk... An for example I
don't really understand the meaning of the function wc_maintain in the
jk_worker.c file.
Any help will is greatly appreciated.
Thanks
Thomas d'Erceville
PS : If you know a version of mod_jk source code with comments for the
functions, I will appreciate.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [TC6] Cluster and storeconfig
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> definitely the modules/ha and modules/groupcom.
> I'd like to clean it up first though, my idea is to instead of
> configuing all the messaging inside the <Cluster> element, the actual
> Tribes impl I'd rather configure as a JNDI resource,
> this has a some benefits, to mention a few
> - more components can take advantage of it, such as monitoring tools,
> other cluster implementations etc
> - Avoid having a giant blog that takes up half of server.xml when
> clustering is turned on
> - Separate out IO tuning from replication configuration
>
> I know in the past other people felt the need for these to be modules,
> for me I dont care either way, I think it might be good for us to get a
> consensus before I merge it in.
>
> You mind sitting a couple of weeks on it and let folks chime in while I
> work on the config separation?
The problem I have is that the other persons who contributed heavily to
clustering seem quite uncomfortable (or at the very least, overwhelmed)
with the new implementation at the moment. Personally, I also prefer a
server.xml configuration.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [TC6] Cluster and storeconfig
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
definitely the modules/ha and modules/groupcom.
I'd like to clean it up first though, my idea is to instead of
configuing all the messaging inside the <Cluster> element, the actual
Tribes impl I'd rather configure as a JNDI resource,
this has a some benefits, to mention a few
- more components can take advantage of it, such as monitoring tools,
other cluster implementations etc
- Avoid having a giant blog that takes up half of server.xml when
clustering is turned on
- Separate out IO tuning from replication configuration
I know in the past other people felt the need for these to be modules,
for me I dont care either way, I think it might be good for us to get a
consensus before I merge it in.
You mind sitting a couple of weeks on it and let folks chime in while I
work on the config separation?
thanks
Filip
Remy Maucherat wrote:
> Hi,
>
> I think it's the right time to add the storeconfig code, as well as a
> clustering implementation (so, which one ?).
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [TC6] Cluster and storeconfig
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Here are my suggestions:
>>
>> 1. Incorporate modules/ha as the cluster solution into TC6
>
> Ok.
>
>> 2. Keep modules/groupcom as a separate module
>> The reason I suggest a separate module, is cause it is a fairly
>> complex component and will have
>> a fairly large documentation base, it might be better to keep it
>> separate and have it
>> release separately from the core. That way, a busted IO component,
>> will not set back the tomcat release.
>
> This sounds ambitious, given the testing that ensures that the
> clustering is not "busted" in a particular release is only done weeks
> later.
not sure I understand.
> Similarly, the plan about big docs is fine, but I didn't see anything
> being started at the moment.
it is ambitious, but it happens to be that I am now in a position to
dedicate way more time than I have ever had before.
There are docs have started,
http://people.apache.org/~fhanik/tribes/docs/introduction.html
paused at the moment while I am developing HTTPS connector with java.nio
(was a little tricky to get my head around but it should be done next week).
> I would like to keep the Tomcat build and packaging simple, so this
> will mean that all external modules would be external components then ?
sure, I understand, shouldn't be very difficult at all.
if you want to include it at build time, then you can just invoke the
build script under modules/groupcom/build, and generate it directly from
there,
or we can keep versioned binaries.
was there ever a decision to have TC6 completely module-less? I don't
remember a final decision on that, do you remember the status of those
conversations?
>
>> 3. Storeconfig - this is Peter's baby and would be his choice.
>> I personally would suggest a rewrite of it and have a storeconfig
>> that is not dependent on the classes of tomcat,
>> ie, storeconfig today has one class for every component in tomcat,
>> so as soon as you swap out a component to a custom class,
>> there is no saving for that component anymore.
>> It could be equally easy to create a completely standalone
>> configuration tool.
>> But since I am not that familiar here,
>> I'd prefer to leave that decision to Peter if he has time to
>> maintain it in TC6.
>
> A rewrite plan is not realistic at this time.
for sure,
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [TC6] Cluster and storeconfig
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> Here are my suggestions:
>
> 1. Incorporate modules/ha as the cluster solution into TC6
Ok.
> 2. Keep modules/groupcom as a separate module
> The reason I suggest a separate module, is cause it is a fairly
> complex component and will have
> a fairly large documentation base, it might be better to keep it
> separate and have it
> release separately from the core. That way, a busted IO component,
> will not set back the tomcat release.
This sounds ambitious, given the testing that ensures that the
clustering is not "busted" in a particular release is only done weeks
later. Similarly, the plan about big docs is fine, but I didn't see
anything being started at the moment. I would like to keep the Tomcat
build and packaging simple, so this will mean that all external modules
would be external components then ?
> 3. Storeconfig - this is Peter's baby and would be his choice.
> I personally would suggest a rewrite of it and have a storeconfig that
> is not dependent on the classes of tomcat,
> ie, storeconfig today has one class for every component in tomcat,
> so as soon as you swap out a component to a custom class,
> there is no saving for that component anymore.
> It could be equally easy to create a completely standalone
> configuration tool.
> But since I am not that familiar here,
> I'd prefer to leave that decision to Peter if he has time to maintain
> it in TC6.
A rewrite plan is not realistic at this time.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [TC6] Cluster and storeconfig
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Here are my suggestions:
1. Incorporate modules/ha as the cluster solution into TC6
2. Keep modules/groupcom as a separate module
The reason I suggest a separate module, is cause it is a fairly
complex component and will have
a fairly large documentation base, it might be better to keep it
separate and have it
release separately from the core. That way, a busted IO component,
will not set back the tomcat release.
3. Storeconfig - this is Peter's baby and would be his choice.
I personally would suggest a rewrite of it and have a storeconfig
that is not dependent on the classes of tomcat,
ie, storeconfig today has one class for every component in tomcat,
so as soon as you swap out a component to a custom class,
there is no saving for that component anymore.
It could be equally easy to create a completely standalone
configuration tool.
But since I am not that familiar here,
I'd prefer to leave that decision to Peter if he has time to maintain
it in TC6.
Filip
Remy Maucherat wrote:
> Remy Maucherat wrote:
>> Hi,
>>
>> I think it's the right time to add the storeconfig code, as well as a
>> clustering implementation (so, which one ?).
>
> Any new comments on this, 3 weeks later ?
>
> I did put in place the necessary scripts and stuff for TC 6, so
> releases could be made in the relatively near future as long as this
> issue is resolved. I volunteer to do the release management, BTW.
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [TC6] Cluster and storeconfig
Posted by Remy Maucherat <re...@apache.org>.
Remy Maucherat wrote:
> Hi,
>
> I think it's the right time to add the storeconfig code, as well as a
> clustering implementation (so, which one ?).
Any new comments on this, 3 weeks later ?
I did put in place the necessary scripts and stuff for TC 6, so releases
could be made in the relatively near future as long as this issue is
resolved. I volunteer to do the release management, BTW.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org