Re: [5.0] Cluster features
Costin Manolache wrote: Remy Maucherat wrote: Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I think it is time to stop bloating the base tomcat source and binaries. BTW, it may be a good time to move some of the current features in separate modules as well. ( SSI, WebDAV, etc ). For webdav - I would rather see slide bundled with tomcat and the current code deprecated. I'm not talking ( for now ) about a real module with descriptors or anything, just separate dirs in the CVS and a .jar target that can be included or not. It may be worth reopening the minimal tomcat discussion :-) Costin +1 to Costin's comments -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Remy Maucherat wrote: Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? I could be a full +1, if we could convince them to make JavaGroups BSD/Apache licence. Or use something related with BSD license (see mod_backend) Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [5.0] Cluster features
Hi, In a rush on my way to (yet another ;() meeting, so: - The current cluster API is dead. - JavaGroups is good. - Clustering is important. = Your approach seems reasonable, +1 IMHO. Yoav Shapira Millennium ChemInformatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 11:50 AM To: Tomcat Developers List Subject: [5.0] Cluster features Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Henri Gomez wrote: Remy Maucherat wrote: Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? I could be a full +1, if we could convince them to make JavaGroups BSD/Apache licence. Or donate it ;-) One other project I have been working with (Slide) could definitely use a distributed cache. Or use something related with BSD license (see mod_backend) I forgot to mention it, but one missing piece of the puzzle is the HTTP proxy(ies) sitting in front of the cluster. It could be: - Some webserver + JK - Apache 2 + mod_proxy - some yet-to-be-written NIO based proxy (which probably wouldn't need to know anything about HTTP; doing a dumb TCP proxy might be enough) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Remy Maucherat wrote: Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I think it is time to stop bloating the base tomcat source and binaries. BTW, it may be a good time to move some of the current features in separate modules as well. ( SSI, WebDAV, etc ). For webdav - I would rather see slide bundled with tomcat and the current code deprecated. I'm not talking ( for now ) about a real module with descriptors or anything, just separate dirs in the CVS and a .jar target that can be included or not. It may be worth reopening the minimal tomcat discussion :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Costin Manolache wrote: Remy Maucherat wrote: Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I wanted to, however I can't do that without changing the API some stuff in the session package (the damn classes are all package private) :-P I suppose it's a lot better to stop the hacks *now*, fix that, and put everything in the cluster package. I think it is time to stop bloating the base tomcat source and binaries. BTW, it may be a good time to move some of the current features in separate modules as well. ( SSI, WebDAV, etc ). For webdav - I would rather see slide bundled with tomcat and the current code deprecated. I'm not talking ( for now ) about a real module with descriptors or anything, just separate dirs in the CVS and a .jar target that can be included or not. Ok. It may be worth reopening the minimal tomcat discussion :-) Maybe. If the difference is only a couple MBs, then it's not worth it, though. If we do an alternate distribution, it would have to be radically different IMO (like for example, being a simple set of JARs without the complex dir structure). The laucher + the catalina.properties + future mods to the config system should make that easy. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Remy Maucherat wrote: +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I wanted to, however I can't do that without changing the API some stuff in the session package (the damn classes are all package private) :-P I suppose it's a lot better to stop the hacks *now*, fix that, and put everything in the cluster package. Well, if you must - you must. But we shouldn't have the core depend on the clustering, just add the minimal stuff that you need in the session. If we can stop the hacks and clean something - I think 5.0 is the best chance. I would preffer to have a consistent hook mechanism for everything - I'm not sure what callbacks will be involved in the clustering. It may be worth reopening the minimal tomcat discussion :-) Maybe. If the difference is only a couple MBs, then it's not worth it, though. Bloat is not about MB or storage. It's about code complexity, potential security, etc. If we do an alternate distribution, it would have to be radically different IMO (like for example, being a simple set of JARs without the complex dir structure). The laucher + the catalina.properties + future mods to the config system should make that easy. That's what I was thinking about - a set of jars and minimal configuration. Eventually using only MBeans for configuration and setup. BTW, we could use MBeans for the optional packages too. I think it works pretty well. We'll need to get a consensus on requiring JMX for tomcat5, but so far it doesn't seem it'll have a big impact on the code ( I did all kind of experiments with modeler and ant lately ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Costin Manolache wrote: Remy Maucherat wrote: +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I wanted to, however I can't do that without changing the API some stuff in the session package (the damn classes are all package private) :-P I suppose it's a lot better to stop the hacks *now*, fix that, and put everything in the cluster package. Well, if you must - you must. But we shouldn't have the core depend on the clustering, just add the minimal stuff that you need in the session. If we can stop the hacks and clean something - I think 5.0 is the best chance. I would preffer to have a consistent hook mechanism for everything - I'm not sure what callbacks will be involved in the clustering. I'll remove stuff in the Cluster API, modify some of the session classes to allow extending them in a different package, and everything in the core is then independent of the clustering. It may be worth reopening the minimal tomcat discussion :-) Maybe. If the difference is only a couple MBs, then it's not worth it, though. Bloat is not about MB or storage. It's about code complexity, potential security, etc. Ok. All distributions need to be thought as secure, though. If we do an alternate distribution, it would have to be radically different IMO (like for example, being a simple set of JARs without the complex dir structure). The laucher + the catalina.properties + future mods to the config system should make that easy. That's what I was thinking about - a set of jars and minimal configuration. Eventually using only MBeans for configuration and setup. I thought this was supposed to be JNDI. JMX does not have any support for bean state serialization, right ? BTW, we could use MBeans for the optional packages too. I think it works pretty well. We'll need to get a consensus on requiring JMX for tomcat5, but so far it doesn't seem it'll have a big impact on the code ( I did all kind of experiments with modeler and ant lately ). +1 for JMX (as there's MX4J); as well as JNDI, BTW. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Costin Manolache wrote: Remy Maucherat wrote: +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I wanted to, however I can't do that without changing the API some stuff in the session package (the damn classes are all package private) :-P I suppose it's a lot better to stop the hacks *now*, fix that, and put everything in the cluster package. Well, if you must - you must. But we shouldn't have the core depend on the clustering, just add the minimal stuff that you need in the session. If we can stop the hacks and clean something - I think 5.0 is the best chance. I would preffer to have a consistent hook mechanism for everything - I'm not sure what callbacks will be involved in the clustering. Are you thinking about having coyote Action(s)? If yes, we might one to extend the current API having in mind that we will need to supports Clustering, Authentification, Authorization, etc. It may be worth reopening the minimal tomcat discussion :-) Maybe. If the difference is only a couple MBs, then it's not worth it, though. Bloat is not about MB or storage. It's about code complexity, potential security, etc. If we do an alternate distribution, it would have to be radically different IMO (like for example, being a simple set of JARs without the complex dir structure). The laucher + the catalina.properties + future mods to the config system should make that easy. That's what I was thinking about - a set of jars and minimal configuration. Eventually using only MBeans for configuration and setup. BTW, we could use MBeans for the optional packages too. I think it works pretty well. We'll need to get a consensus on requiring JMX for tomcat5, but so far it doesn't seem it'll have a big impact on the code ( I did all kind of experiments with modeler and ant lately ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I wanted to, however I can't do that without changing the API some stuff in the session package (the damn classes are all package private) :-P I suppose it's a lot better to stop the hacks *now*, fix that, and put everything in the cluster package. Well, if you must - you must. But we shouldn't have the core depend on the clustering, just add the minimal stuff that you need in the session. If we can stop the hacks and clean something - I think 5.0 is the best chance. I would preffer to have a consistent hook mechanism for everything - I'm not sure what callbacks will be involved in the clustering. I'll remove stuff in the Cluster API, modify some of the session classes to allow extending them in a different package, and everything in the core is then independent of the clustering. No security problems if we kept the current package protection mechanism. Making those classes public can be dangerous if the package protection is not enabled. It may be worth reopening the minimal tomcat discussion :-) Maybe. If the difference is only a couple MBs, then it's not worth it, though. Bloat is not about MB or storage. It's about code complexity, potential security, etc. Ok. All distributions need to be thought as secure, though. Does that implies re-writting the current set of classloader? It might be a good time to revisit classloader and security :-) If we do an alternate distribution, it would have to be radically different IMO (like for example, being a simple set of JARs without the complex dir structure). The laucher + the catalina.properties + future mods to the config system should make that easy. That's what I was thinking about - a set of jars and minimal configuration. Eventually using only MBeans for configuration and setup. I thought this was supposed to be JNDI. JMX does not have any support for bean state serialization, right ? BTW, we could use MBeans for the optional packages too. I think it works pretty well. We'll need to get a consensus on requiring JMX for tomcat5, but so far it doesn't seem it'll have a big impact on the code ( I did all kind of experiments with modeler and ant lately ). +1 for JMX (as there's MX4J); as well as JNDI, BTW. +1 -- Jeanfrancois Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Jeanfrancois Arcand wrote: +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I wanted to, however I can't do that without changing the API some stuff in the session package (the damn classes are all package private) :-P I suppose it's a lot better to stop the hacks *now*, fix that, and put everything in the cluster package. Well, if you must - you must. But we shouldn't have the core depend on the clustering, just add the minimal stuff that you need in the session. If we can stop the hacks and clean something - I think 5.0 is the best chance. I would preffer to have a consistent hook mechanism for everything - I'm not sure what callbacks will be involved in the clustering. Are you thinking about having coyote Action(s)? If yes, we might one to extend the current API having in mind that we will need to supports Clustering, Authentification, Authorization, etc. I don't care too much if it is called Coyote Action, Jk2 Handler, 3.3 Interceptor(with a single method), or 4.0 Valve ( in multiple chains ) or Axis Handler/Chain. Or even Event/Listener. Some time ago I started a package to implement yet-another hook, as a replacement for Action in coyote. I remove it because there is absolutely no point for yet another API - any of those APIs can do the job. All I want is a single and simple and consistent hook mechanism that is used for callbacks in all extension points ( simple is quite important :-) Since Coyote is now used in all tomcat versions and also jk - I think it is a good idea to use with coyote Action. But I'm +1 on anything else - as long as we converge on a single mechanism ( it is simple to wrap any hook - Vavle, interceptor, action. into any interface ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Jeanfrancois Arcand wrote: I'll remove stuff in the Cluster API, modify some of the session classes to allow extending them in a different package, and everything in the core is then independent of the clustering. No security problems if we kept the current package protection mechanism. Making those classes public can be dangerous if the package protection is not enabled. That depends on the class loader - if tomcat is embedded in something else ( like J2EE or some other app ) I'm not sure how it'll protect this. Also, a number of classes are public because they are intended to be used, and a number of security problems may happen ( as we learned ) even if the class is not accessible ( like the recent web.xml entity issues ). Bloat is not about MB or storage. It's about code complexity, potential security, etc. Ok. All distributions need to be thought as secure, though. Does that implies re-writting the current set of classloader? It might be a good time to revisit classloader and security :-) Do you have so much free time :-) ? I'm +1 BTW. If we reach consensus on JMX - it may be a good idea to use its class loading mechanism, or something very close - the model in theory is very good. You have full control ( using mlet tags or API ) over the class loaders and hierarchy. +1 for JMX (as there's MX4J); as well as JNDI, BTW. +1 I'll send a separate mail with a VOTE subject. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Costin Manolache wrote: Jeanfrancois Arcand wrote: I'll remove stuff in the Cluster API, modify some of the session classes to allow extending them in a different package, and everything in the core is then independent of the clustering. No security problems if we kept the current package protection mechanism. Making those classes public can be dangerous if the package protection is not enabled. That depends on the class loader - if tomcat is embedded in something else ( like J2EE or some other app ) I'm not sure how it'll protect this. It will work if, in their classloader implementation, they call securityManager.checkPackageDefinition(...). The current J2EE 1.4 RI doesn't., and most of the EE implementation doesn't because of the Security Manager performance hit. Also, a number of classes are public because they are intended to be used, and a number of security problems may happen ( as we learned ) even if the class is not accessible ( like the recent web.xml entity issues ). Bloat is not about MB or storage. It's about code complexity, potential security, etc. Ok. All distributions need to be thought as secure, though. Does that implies re-writting the current set of classloader? It might be a good time to revisit classloader and security :-) Do you have so much free time :-) ? I'm +1 BTW. What do you do when its -20 celcius? ;-) Try to find something to warm yourself :-) I was under the impression Remy was having a proposal for the classloader stuff. (IMBW). Once I have a clear understanding on all the hooks (inclusing Axis/Apache), I would certainly work on his proposal :-) -- Jeanfrancois If we reach consensus on JMX - it may be a good idea to use its class loading mechanism, or something very close - the model in theory is very good. You have full control ( using mlet tags or API ) over the class loaders and hierarchy. +1 for JMX (as there's MX4J); as well as JNDI, BTW. +1 I'll send a separate mail with a VOTE subject. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [5.0] Cluster features
we have a project on sourceforge to continue development of this. but we would love to integrate this into Tomcat where it really belongs. http://sourceforge.net/projects/tomcat-jg Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 8:50 AM To: Tomcat Developers List Subject: [5.0] Cluster features Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
