Cluster fixes
I am going through the cluster code right now and will be adding fixes along the way. I think the development of this code has focused more on features than stability, so I would like to ask that for the next period, lets focus on the stability and get this beast back in shape again. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.9 Stability
ok, I'll look into this this week. Filip Peter Rossbach wrote: Hey, the problem is arround the keep a live handling code and the auto reconnect at SimpleTcpCluster. One thread can say: I drop the connection and open new one, then start transfer message and wait for ack. Other thread comes and see ups. the connection is not there. ( Arrg missing sychronized). I open a new socket and close the old current use socket. Under Suse Linux 9.1, the first thread wait for keepAlive timeout (60 sec). BAD!!! = Asnyc mode the queue grow very fast. Sometimes all other nodes have the same problem and the complete cluster standing still. Nothing todo wait for ACK I am made very limited testing the effects at sync,pooled mode. I preferred the async modes. I have merge my fix at the 5.5.10 CVS Head Basis. Currently my customer start a weekend load test. I also merge the changes at 5.5.9 Basis. Both version needs testing and documentation, but my time and ressource are limited. Need help, setup clusters and start loading tests. I start to open a bug report for better community discussion and add my fix pack for testing. build-src bin pack I must review my changes and document my szenario. Than Filip can start to review the changes and testing the clustering. Thanks for you help. :-) My customers needs the new 5.5.9 Release. The best thing is, we package a separate patch-cluster-fix and mark 5.5.9 as beta. Peter Filip Hanik - Dev Lists schrieb: Hi Peter, what's up with the cluster code? I will have some time to load test and debug any problems you might have, also, do you have problems on the synced-pooled setting, or on all connectors? Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.9 Stability
Hi Peter, what's up with the cluster code? I will have some time to load test and debug any problems you might have, also, do you have problems on the synced-pooled setting, or on all connectors? Filip Peter Rossbach wrote: Hey, [X] Stable -- good build (Normal Tomcat) [X] unstable and buggy cluster code, Argg! The normal Tomcat features are very stable on my tests. But my cluster code refactorings has drop the clustering. I have test the cluster under load this week and find some very bad bugs :-( - Complete cluster hang sometimes - In some situation the async mode can't dequeue I have build some quick fixes and can build a patch for some 5.5.9 cluster classes (Monday evening). Vote for a server classes fix pack or package the catalina-cluster.jar again. Sorry, Peter Yoav Shapira schrieb: Hi, Tomcat v5.5.9 has been out for more than a week now, so hopefully we have had time to test/use it. We're still waiting for the TCK results, but let's hear your opinion: [ ] Stable -- good build [ ] Beta -- minor bad stuff: what is it? [ ] Alpha -- something serious is wrong: what is it? The vote will run for about 72 hours as usual. Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA [EMAIL PROTECTED] / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Proposed API change to the Manager interface
Remy Wrote:
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
That would have been the obvious solution, the jvmRoute must have come from a
dark basement somewhere :)
Whatever the change you decide on, I'll be happy to implement it and test it
for the cluster stuff
Filip
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Monday, February 07, 2005 11:34 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
@@ -744,15 +747,17 @@
session.setValid(true);
session.setCreationTime(System.currentTimeMillis());
session.setMaxInactiveInterval(this.maxInactiveInterval);
-String sessionId = generateSessionId();
+if (sessionId == null) {
+sessionId = generateSessionId();
+}
I just noticed my patch needs something for jvmRoute handling
(basically, the session id which is recieved must be edited for the
right route). I'll fix that.
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Proposed API change to the Manager interface
its not at all that complicated.
This is how a big5 load balancer does it.
A) it sets a cookie, and based on the cookie it load balances.
B) if a cookie is not supported, it does a calculation based on the IP address,
and stays sticky that way.
No need to exchange any info in this scenario and very straight forward, and
never goes wrong. The only time it goes wrong is for
AOL users who can change gateway between HTTP and HTTPS
Filip
- Original Message -
From: Rainer Jung [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Tuesday, February 08, 2005 10:39 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
I'm afraid that change will have negative implications: The jvmRoute is
used to enable routing decisions by balancing components. All these
components usually support routing either COOKIE-based or URI-based.
In the URI-based case it is more or less the only clean way to include
the jvmRoute in the jsessionid, since the jsessionid is standardized, so
all common balancing products know how to handle it.
But then it is pretty common to assume the jsessionid and the cookie to
have the same value. They are sort of two different ways to transport
the same session information. So most balancer providers implement the
routing decision features the same way, independant of the source of the
session string.
Splitting the jvmRoute from the session id in the cookie case will most
likely make the situation for all implementers of balancers more complex
and instable (e.g.: mod_jk).
Of course we would all profit, if some JSR would standardize the way,
distributed applications exchange routing information with the
clients/balancers. As long as that's not the case it is very likely,
that jvmRoute as a suffix of the session id has much better support from
balancer providers.
Rainer
Filip Hanik - Dev wrote:
Remy Wrote:
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
That would have been the obvious solution, the jvmRoute must have come from a
dark basement somewhere :)
Whatever the change you decide on, I'll be happy to implement it and test it
for the cluster stuff
Filip
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Monday, February 07, 2005 11:34 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
@@ -744,15 +747,17 @@
session.setValid(true);
session.setCreationTime(System.currentTimeMillis());
session.setMaxInactiveInterval(this.maxInactiveInterval);
-String sessionId = generateSessionId();
+if (sessionId == null) {
+sessionId = generateSessionId();
+}
I just noticed my patch needs something for jvmRoute handling
(basically, the session id which is recieved must be edited for the
right route). I'll fix that.
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: The FIX - Shutdown not working under SLES8 and FC2
Costin Wrote: ( BTW - if you plan to participate in any open source project - be prepared for a lot of hurt feelings and negative comments, if you can't handle it, stay out. It happens to all of us. Track the problem, send a patch and friendly reminders if it gets ignored - and be prepared to accept a 'no' ) This by all means doesn't mean that all open source developers are not equipped with social skills, its just more common in the Java world :) Filip - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: tomcat-dev@jakarta.apache.org Cc: tomcat-user@jakarta.apache.org Sent: Thursday, February 03, 2005 11:16 AM Subject: Re: The FIX - Shutdown not working under SLES8 and FC2 What about: - add this information to the bug report - send a patch to the FAQ or edit a wiki page ( well, the tc wiki is not very used, but probably google will find this if anyone has a similar problem ). Or post it in your weblog/site/etc for google to find. It should be obvious changing the default configuration only to deal with this case won't happen. If a computer can't locate itself by name - you'll have a lot of other problems. Costin ( BTW - if you plan to participate in any open source project - be prepared for a lot of hurt feelings and negative comments, if you can't handle it, stay out. It happens to all of us. Track the problem, send a patch and friendly reminders if it gets ignored - and be prepared to accept a 'no' ) [EMAIL PROTECTED] wrote: After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts you've got a strange config, it's your problem, I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address=127.0.0.1 to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine. I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh). Thanks again, Al. -Original Message- From:
Fw: Multi-Site Clustering? (hot failover)
- Original Message - From: Peter Lin [EMAIL PROTECTED] I should add that some service provider include it free, if you rent rack space in the other hosting facility. I've used Level3 in the past and I know they definitely provide multi-site load balancing. all of the top 3 service providers offer it I think. it's not cheap though, so be ready to open up the wallet. peter On Wed, 10 Nov 2004 13:13:51 -0600, Filip Hanik - Dev [EMAIL PROTECTED] wrote: which might also give you the idea, if you control your own DNS, you could manually switch it over to a new set of IP addresses when your old data center blows up. Filip - Original Message - From: Peter Lin [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Wednesday, November 10, 2004 1:08 PM Subject: Re: Multi-Site Clustering? (hot failover) normally ISP will offer multi-site load balancing using DNS. In terms of failover, it generally handled the same way. If an earthquake swallows the first location, the second site's DNS will pick and route the traffic to the second cluster. I would talk to your service provider. the smaller shops don't offer it, so you'll have to talk to a bigger ISP. peter On Wed, 10 Nov 2004 12:52:17 -0600, Filip Hanik - Dev [EMAIL PROTECTED] wrote: Even a datacenter by itself plugs in to more than one backbone (network provider) So a datacenter itself has more than one connection into it. So what I am saying, if you want to fail over between data centers, that is not something you configure in tomcat, or in your own network, that is something you probably arrange with the data centers or the network providers, cause if your data center gets shattered in an earth quake, all the routers in there will be dead anyway. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
actually, its a negative filter, (if one can say that :) Anything that doesn't match the filter, gets replicated. I did that since people use all kinds of extensions on the MVC framework. Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 29, 2004 4:39 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml [EMAIL PROTECTED] wrote: Valve className=org.apache.catalina.cluster.tcp.ReplicationValve - filter=.*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;/ + filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ -0. Adding static resources to that list is not good IMO. The idea is that replication (with the Tomcat defaults) will only have to occur for dynamic content. If the guy has special needs, then he can change this. Obviously, this is not a big issue for the 5.5.4 build ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Yoav, you made the right choice. The checkin is good. Filip - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, November 01, 2004 8:25 AM Subject: RE: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml Hi, Without knowing the filter, I figured if .jpg was there than .png wasn't much different, and if .txt was there .css is not much different. So it made sense from a consistency standpoint. However, I have no particular attachment to the filter itself or this commit: if you don't like it, feel free to undo it ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 9:25 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml actually, its a negative filter, (if one can say that :) Anything that doesn't match the filter, gets replicated. I did that since people use all kinds of extensions on the MVC framework. Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 29, 2004 4:39 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml [EMAIL PROTECTED] wrote: Valve className=org.apache.catalina.cluster.tcp.ReplicationValve - filter=.*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;/ + filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ -0. Adding static resources to that list is not good IMO. The idea is that replication (with the Tomcat defaults) will only have to occur for dynamic content. If the guy has special needs, then he can change this. Obviously, this is not a big issue for the 5.5.4 build ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.3 Stability Rating
[ X ] Beta, it's getting closer to stable [what's missing?] Unfortunately due to an acquisition I am jammed at work. Cluster features that previously worked and need to be fixed: 1. Farm deployment I haven't had time to check the other stuff, I know that 5.0.28 had problem with reloading the context where it wouldn't assign a cluster manager properly when reloading, this worked in 5.0.25, it could be possible the same problem exists in 5.5 Filip - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, October 12, 2004 10:36 AM Subject: [VOTE] 5.5.3 Stability Rating Hi, Tomcat 5.5.3 has been available for about a week now, so it's time for a stability vote. I tentatively rated it Alpha when releasing as my own personal impression, but I haven't had any significant issues with it myself. It passes our internal tests, and with the StandardWrapper hotfix it passes the Servlet and JSP TCKs. So: Tomcat 5.5.3 should be rated: [ ] Alpha still, because ??? [ X ] Beta, it's getting closer to stable [what's missing?] [ ] Stable, it's rock solid My vote, as shown above, is for Beta. What's missing from Stable rating: StandardWrapper hotfix, a few minor features for the JDT compiler that are done only for the Ant compiler, JDT compiler support for J2SE 5.0, a few bells and whistles. This vote will run for about 72 hours as usual. Also as usual, only committer votes are binding, but opinions from other readers are welcome. Thanks, Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.3 and 5.0.29 Tagging Today
There was a bug introduced between 5.0.25 and 5.0.28. When a context is reloaded and there is a distributable/ element in web.xml, the context still doesn't get a ClusterManager assigned. A user reported this on the tomcat user list, I've been way to swamped to check on it. The cluster code didn't change between those versions, so it might be somewhere else, I will see if I can reproduce it today, and if so, open a bugzilla bug Filip - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 7:54 AM Subject: Tomcat 5.5.3 and 5.0.29 Tagging Today Hi, As previously suggested last week, and since no on objected, I will tag Tomcat 5.5.3 and 5.0.29 in CVS today, at 1700h GMT. Please give me a few minutes' safety margin around the above time, as the network here at work seems troubled today. Thanks, Yoav Shapira Millennium Research Informatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is DeltaManager actively being maintained?
patches are always welcome, I'd be happy to test and submit it Filip - Original Message - From: Michael Leditschke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 2:28 AM Subject: Is DeltaManager actively being maintained? In poking around in the manager code today, I noticed that this manager hasn't had a couple of recent changes in ManagerBase ported to it, namely 1) It is still managing its own expired sessions counter 2) It is still doing its own duplicate session detection and adding of jvmroute information. If its still being supported, I'd be happy to generate a patch to fix the above. Regards Michael +61 407 671 480 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat build broken with strange javac error(never seen this one before)
post on tomcat-user in the future, thanks! these are simple steps cvs co jakarta-tomcat-5 cd jakarta-tomcat-5 ant update ant download ant dist Filip - Original Message - From: Hiller, Dean D (Dean) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 12, 2004 2:00 PM Subject: tomcat build broken with strange javac error(never seen this one before) I have never seen an error from javac like this before(and I am by no means new to java). I have even read the JLS and am not sure what in the world this is. Can anyone point me somewhere on how to resolve this issue? Or possibly point me to a build.xml for tomcat5 that works? The one on the website does not work as I get the below. I am using 1.4.2_05. Does the build.xml file work for anyone else? If so, what version of java are you using? build-catalina-core: [javac] Compiling 302 source files to C:\ROOT\views\jakartaviews\tomcatTry\jakarta-tomcat-5\build\classes [javac] C:\ROOT\views\jakartaviews\tomcatTry\jakarta-tomcat-catalina\catalina\sr c\share\org\apache\catalina\Container.java:23: cannot access javax.servlet.ServletException [javac] bad class file: C:\usr\share\java\servlet-api-2.4\lib\servlet-api.jar(javax/servlet/Serv letException.class) [javac] class file has wrong version 49.0, should be 48.0 [javac] Please remove or make sure it appears in the correct subdirectory of the classpath. [javac] import javax.servlet.ServletException; [javac] ^ [javac] 1 error Also, I really want to know more about this error and how it is possible. Does anyone know what this means? Ps. Am I on the wrong list? Is this really a problem with the servlet api jar?, but which project is that and who do I talk to??? thanks, dean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: both jdk1.5 and jdk1.4 needed to build tomcat????
It works for me with those steps using JDK 1.4, no problem if you need to try again, I suggest to clean your machine, and start over (this includes all the downloads in /usr/share/java) Filip - Original Message - From: Hiller, Dean D (Dean) [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, August 12, 2004 4:38 PM Subject: both jdk1.5 and jdk1.4 needed to build tomcat I for some reason needed 1.4jdk and 1.5jdk to build tomcat. My steps are below. Any help would be appreciated as to how I can correct this Using jdk1.5 and Filip's great list of steps(thanks Filip, the list made life easier, and I am almost there) I go through the list to build tomcat 1. cvs co jakarta-tomcat-5 works great 2. cd jakarta-tomcat-5 obviously works 3. ant update works great 4. ant download breaks, and looks like 1.5 problems, so I switch to 1.4 and it works!!!. Basically the tomcat-deps module is not compiling in 1.5 as it conflicts with many different things. 5. ant dist sticking with 1.4 doesn't work, and going to 1.5 doesn't work. So now, I am basically stuck again on Jakarta-tomcat-5/build/classes not compiling at all. I am not sure where to go. I am trying to think what are the possibilities of what is wrong. 1. I need to do some configuration which I haven't done. 2. Builds currently don't work if starting from scratch as something was modified on accident? 3. they do work if you already had everything downloaded? I followed the steps above twice. I don't suppose having to switch between 1.4 and 1.5 makes my situation easier to debug, as that could be part of my problem too. Don't suppose someone just wants to send me a zipped up version of their view that builds?? I would like to fix this and will continue to look at the problem, but I am not really sure where to start so it may take me some time as I jump into all this. Thanks, dean -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 2:16 PM To: 'Tomcat Developers List' Subject: RE: tomcat build broken with strange javac error(never seen this one before) 1. Ignore the stop sending me mail message. Someone has managed to get themselves subscribed to the list and is obviously incapable of following the simple instructions included in every mail to unsubscribe. One of the list owners (of which I am one) will sort this out. 2. 3. The right place to posts depends on the question and will always be a judgement call and different people will make different judgements. I wouldn't worry about it too much - personally I thought this one was on the border line. Mark -Original Message- From: Hiller, Dean D (Dean) [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 8:29 PM To: Tomcat Developers List Subject: RE: tomcat build broken with strange javac error(never seen this one before) Huh, 3 questions about this mail list then. 1. confused by stop sending me mail when this is my first mail to this list 2. Huh, I thought building would be a developer issue 3. Where should I post future questions on the source code I am looking at in tomcat??? The users list states it is for configuration issues, etc. ps. Thanks shapira for the jdk1.5 note. That makes sense, duh. Thanks, dean -Original Message- From: Joshua Paul [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 1:21 PM To: Tomcat Developers List Subject: Re: tomcat build broken with strange javac error(never seen this one before) Stop sending me e-mail. - Original Message - From: Hiller, Dean D (Dean) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 12, 2004 3:00 PM Subject: tomcat build broken with strange javac error(never seen this one before) I have never seen an error from javac like this before(and I am by no means new to java). I have even read the JLS and am not sure what in the world this is. Can anyone point me somewhere on how to resolve this issue? Or possibly point me to a build.xml for tomcat5 that works? The one on the website does not work as I get the below. I am using 1.4.2_05. Does the build.xml file work for anyone else? If so, what version of java are you using? build-catalina-core: [javac] Compiling 302 source files to C:\ROOT\views\jakartaviews\tomcatTry\jakarta-tomcat-5\build\classes [javac] C:\ROOT\views\jakartaviews\tomcatTry\jakarta-tomcat-catalina\c atalina\sr c\share\org\apache\catalina\Container.java:23: cannot access javax.servlet.ServletException [javac] bad class file: C:\usr\share\java\servlet-api-2.4\lib\servlet-api.jar(javax/se rvlet/Serv letException.class) [javac] class file has wrong version 49.0, should be 48.0 [javac] Please remove or make sure it appears in the correct subdirectory of the classpath. [javac] import javax.servlet.ServletException; [javac]
Re: StandardClassLoader ?
During session replication I optimized my code to decide what order class loader to use based on the class name. For example, if you load a class that starts with org.apache.catalina. I attempt to load it with the SCL first, it gave the app a huge performance boost. I know I know, this breaks the rule of thumb with webapps, but there are smart shortcuts you can make, like make a list of all the classes in common/lib and server/lib and never load those through WebCL unless specified by the user. Most user would love the performance gain of this, and the ability to turn it on/off Filip - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 05, 2004 9:54 AM Subject: Re: StandardClassLoader ? Remy Maucherat wrote: Costin Manolache wrote: Is there any reason we still need StandardClassLoader ? It seems it is only used once, in ClassLoaderFactory, and it is used exactly like a regular URLClassLoader - the only thing that needs to be moved is the convert() method. The code itself is just debug and duplication of URLClassLoader - the reverse loading is not used and it's not even really implemented in all parts of the code. I'll keep it for now, since I'll try experiments to try to have faster classloading. If my stuff isn't efficient, then I'll remove it. Can you experiment with WebappClassLoader instead :-) ? SCL is only used in standalone mode and only for loading internal classes. And removing it will improve class loading time by itself - one less layer of if() and indirections. ( I'm experimenting with class loading too, and it's easier to do it in one loader ) What I'm trying to do is allow some modules ( connectors, auth, etc ) to be deployed and loaded/unloaded/upgraded at runtime. Costin It would reduce in half the complexity in the loader package :-), and it would make 'embeded' and 'standalone' more similar ( embeded doesn't usually use Bootstrap and StandardClassLoader but the embedding app loader). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StandardClassLoader ?
here is the huge performance boost: Every single time I deserialized an object, it has to do a cl.loadClass(), now using a custom object stream, it would search the WCL first, then the SCL. And since it didn't exist in WCL, it still seemed to do a long scan each time, and then defaulting back to SCL at which point it was fast. By bypassing the WCL check, knowing the class didn't exist there, it was a lot faster. JProbe told me, I trust him :) Is this scenario clear? Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, August 05, 2004 11:01 AM Subject: Re: StandardClassLoader ? Filip Hanik - Dev wrote: During session replication I optimized my code to decide what order class loader to use based on the class name. For example, if you load a class that starts with org.apache.catalina. I attempt to load it with the SCL first, it gave the app a huge performance boost. I know I know, this breaks the rule of thumb with webapps, but there are smart shortcuts you can make, like make a list of all the classes in common/lib and server/lib and never load those through WebCL unless specified by the user. Most user would love the performance gain of this, and the ability to turn it on/off This is extremely easy to test: you need to add stuff to the package array in WCL, so that it will delegate for these packages. This doesn't improve performance in any noticeable way (as I expected), so I don't see where you found any huge performance boost. While it does sound great, I think your test seemed either bad or very specific. From my profile, the bottleneck for the startup time is XML parsing and accessing entries in JARs (we can't do anything about that), with a little for classloading as well (but it's not very big, and my optimization plans were to experiment loading everything at once on stratup, to be able to remove all syncing in the CL - I don't even know if that would have been efficient, and since it does conflict with the more interesting stuff from Costin, I'm giving up on that one for now). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StandardClassLoader ?
From my profile, the bottleneck for the startup time is XML also I missed this one, startup time...my scenario is a dynamic one where some webapps have 20+ libraries in the WCL Filip - Original Message - From: Filip Hanik - Dev [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, August 05, 2004 12:37 PM Subject: Re: StandardClassLoader ? here is the huge performance boost: Every single time I deserialized an object, it has to do a cl.loadClass(), now using a custom object stream, it would search the WCL first, then the SCL. And since it didn't exist in WCL, it still seemed to do a long scan each time, and then defaulting back to SCL at which point it was fast. By bypassing the WCL check, knowing the class didn't exist there, it was a lot faster. JProbe told me, I trust him :) Is this scenario clear? Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, August 05, 2004 11:01 AM Subject: Re: StandardClassLoader ? Filip Hanik - Dev wrote: During session replication I optimized my code to decide what order class loader to use based on the class name. For example, if you load a class that starts with org.apache.catalina. I attempt to load it with the SCL first, it gave the app a huge performance boost. I know I know, this breaks the rule of thumb with webapps, but there are smart shortcuts you can make, like make a list of all the classes in common/lib and server/lib and never load those through WebCL unless specified by the user. Most user would love the performance gain of this, and the ability to turn it on/off This is extremely easy to test: you need to add stuff to the package array in WCL, so that it will delegate for these packages. This doesn't improve performance in any noticeable way (as I expected), so I don't see where you found any huge performance boost. While it does sound great, I think your test seemed either bad or very specific. From my profile, the bottleneck for the startup time is XML parsing and accessing entries in JARs (we can't do anything about that), with a little for classloading as well (but it's not very big, and my optimization plans were to experiment loading everything at once on stratup, to be able to remove all syncing in the CL - I don't even know if that would have been efficient, and since it does conflict with the more interesting stuff from Costin, I'm giving up on that one for now). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StandardClassLoader ?
You could enable delegation to the parent CL, if it fits your needs better. yup, it does this already. I totally missed that we are talking CL at startup time, in this case it doesn't really matter. Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, August 05, 2004 12:48 PM Subject: Re: StandardClassLoader ? Filip Hanik - Dev wrote: here is the huge performance boost: Every single time I deserialized an object, it has to do a cl.loadClass(), now using a custom object stream, it would search the WCL first, then the SCL. And since it didn't exist in WCL, it still seemed to do a long scan each time, and then defaulting back to SCL at which point it was fast. By bypassing the WCL check, knowing the class didn't exist there, it was a lot faster. JProbe told me, I trust him :) Is this scenario clear? I do understand it. However, I don't quite see a big problem, as most of the application stuff should be application types, except the wrapper session object. You could enable delegation to the parent CL, if it fits your needs better. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
-1
how about not putting your home directory in the default property file :)
Filip
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, August 05, 2004 3:10 PM
Subject: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
yoavs 2004/08/05 13:10:49
Modified:.build.properties.default
webapps/docs changelog.xml
Log:
Updated Jakarta-Commons dependencies (BeanUtils to 1.7.0, Collections to 3.1).
Revision ChangesPath
1.131 +8 -7 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.130
retrieving revision 1.131
diff -u -r1.130 -r1.131
--- build.properties.default 29 Jul 2004 19:16:08 - 1.130
+++ build.properties.default 5 Aug 2004 20:10:48 - 1.131
@@ -35,9 +35,10 @@
cvsroot=:pserver:[EMAIL PROTECTED]:/home/cvspublic
# - Default Base Path for Dependent Packages -
-base.path=/usr/share/java
+#base.path=/usr/share/java
#base.path=../repository
#base.path=/usr/local
+base.path=/home/yoavs/temp
# - Jakarta files base location -
base-jakarta.loc=http://archive.apache.org/dist/jakarta
@@ -54,17 +55,17 @@
# - Commons Beanutils, version 1.4 or later -
-commons-beanutils.home=${base.path}/commons-beanutils-1.6.1
+commons-beanutils.home=${base.path}/commons-beanutils-1.7.0
commons-beanutils.lib=${commons-beanutils.home}
commons-beanutils.jar=${commons-beanutils.lib}/commons-beanutils.jar
-commons-beanutils.loc=${base-jakarta.loc}/commons/beanutils/binaries/commons-beanutils-1.6.1.tar.gz
+commons-beanutils.loc=${base-jakarta.loc}/commons/beanutils/binaries/commons-beanutils-1.7.0.tar.gz
# - Commons Collections, version 2.0 or later -
-commons-collections.home=${base.path}/commons-collections-2.1.1
+commons-collections.home=${base.path}/commons-collections-3.1
commons-collections.lib=${commons-collections.home}
-commons-collections.jar=${commons-collections.lib}/commons-collections-2.1.1.jar
-commons-collections.loc=${base-jakarta.loc}/commons/collections/binaries/commons-collections-2.1.1.tar.gz
+commons-collections.jar=${commons-collections.lib}/commons-collections-3.1.jar
+commons-collections.loc=${base-jakarta.loc}/commons/collections/binaries/commons-collections-3.1.tar.gz
# - Commons Launcher, version 0.9 or later -
1.87 +5 -2 jakarta-tomcat-catalina/webapps/docs/changelog.xml
Index: changelog.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
retrieving revision 1.86
retrieving revision 1.87
diff -u -r1.86 -r1.87
--- changelog.xml 5 Aug 2004 13:10:35 - 1.86
+++ changelog.xml 5 Aug 2004 20:10:48 - 1.87
@@ -14,7 +14,7 @@
body
-section name=Tomcat 5.1.0 (yoavs)
+section name=Tomcat 5.5.0 (yoavs)
subsection name=General
changelog
fix
@@ -33,7 +33,10 @@
bug29826/bug: Modified setclasspath.bat exit code to 1. (yoavs)
/fix
update
-Updated status page, basically completely rewritten for Tomcat 5.1. (yoavs)
+Updated status page, mostly rewritten. (yoavs)
+ /update
+ update
+Updated Jakarta-Commons dependencies: BeanUtils to 1.7.0, Collections to
3.1. (yoavs)
/update
/changelog
/subsection
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: New committer: Peter Rossbach
+1 - Original Message - From: Tim Funk [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, July 30, 2004 8:10 AM Subject: Re: New committer: Peter Rossbach +1 -Tim Remy Maucherat wrote: Hi, I'd like to nominate Peter Rossbach pr _at_ objektpark.de as a committer on the Tomcat project. Peter submitted a significant amount of useful patches for Tomcat, and wants to contribute more. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Refactoring save-to-XML
Xerces still provide an XML Serializer, two actually
they all do, it is part of the standard Java XML API
see below, this way you don't have to import any outside libraries of the JDK
Filip
public static void writeXmlToFile(java.io.File f, Document d) {
Transformer transformer =
TransformerFactory.newInstance().newTransformer();
java.io.FileOutputStream out = new java.io.FileOutputStream(f);
StreamResult result = new StreamResult(out);
DOMSource source = new DOMSource(d);
transformer.setOutputProperty(OutputKeys.INDENT,yes);
//depending on which library you have
transformer.setOutputProperty({http://xml.apache.org/xalan%7dindent-amount,4;);
transformer.setOutputProperty({http://xml.apache.org/xslt%7dindent-amount,4;);
transformer.setOutputProperty(OutputKeys.METHOD,xml);
transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION,yes);
transformer.transform(source, result);
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Friday, July 30, 2004 11:57 AM
Subject: Re: [5.next] Refactoring save-to-XML
Shapira, Yoav wrote:
Hi,
I think a gradual transition might be OK. Server.xml, as Remy said, nicely conveys
the structure of the server's configuration.
That's possible to replicate in a JMX- or JBoss-style configuration file, but it tends
to look uglier and more verbose IMHO.
However, your desired a good long-term goal also, I think.
So for now I like the DOM + PropertyChangeEvent model that Remy has proposed.
Especially combined with the increased use of
setAllProperties, the configuration will be both less verbose and easier to
save/restore.
Xerces still provide an XML Serializer, two actually. One is what I think we should
use, the DOM Level 3 Standard (meaning there's
a shot this thing is portable ;)):
http://xml.apache.org/xerces2-j/javadocs/api/org/w3c/dom/ls/LSSerializer.html,
specified in
http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/. But as you see these things
are fairly new, and as such might be buggy:
http://xml.apache.org/xerces2-j/dom3.html. There's also at least one unimplemented
method of the LSSerializer
(normalize-characters) but we might not need that one.
This is a big plus in favor of DOM 3. +1 for using it.
I see this stuff is available bundled on JDK 1.5 (like JMX and JMX
remote), so if we choose to use this, I think I'll advocate having the
default download for JDK 1.5, and a download for JDK 1.4 compatibility.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
The Java VM does this through file handling, we would have to find out where it issues this call and if we can get around it. The Tomcat developers are not calling stat anywhere in the code, but the underlying JVM code does, we just don't know where Filip - Original Message - From: David Rees [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 11:08 AM Subject: Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev] Remy Maucherat wrote, On 7/28/2004 7:54 AM: One thing I noticed when looking at Tomcat 5.0.x is that its default, static-file-delivering servlet does a stat(2) of each path prefix leading up to the file. A standard installation of Apache 2.x, with FollowSymlinks enabled, doesn't do these stat calls, for obvious performance reasons. Is the stat'ing of all the directories leading up to the requested file in Tomcat intentional (it *is* valuable in some environments for security purposes), or is it just a side-effect of the implementation? I really have no idea what this stuff means. stat is a Unix system call which retrives the status information of a file or directory. Each stat call can potentially hit the disk, so this can be a very expensive system call to make if you have deep directory trees and could explain some of the performance differences between Apache and Tomcat. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
There's a cache for that, so canonicalization will happen only once in a while. I don't understand how it can possibly be a performance issue. maybe I am reading the code wrong, but the method file() in FileDirContext creates a new file object each time, so there is no caching there. So I guess the caching is on a higher level? Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
- Original Message - From: Mladen Turk [EMAIL PROTECTED] I also see no reason why the mod_proxy functionally cannot be implemented in mod_jk2 :). yes, but it is rocket science to actually get jk2 compiled and configured and to work properly. mod_proxy is part of the core, and takes about 5 seconds to setup. That is the biggest difference the current user base is experiencing today. I've been on three commercial projects where mod_jk2 has been dropped and replaced with mod_proxy, (and not on my recommendation). That alone speaks for itself. If the successor of jk2 can be as easy to configure and setup with apache, then go for it. Otherwise I humble suggestion would be to start looking that direction. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info yes, this is what alot of users want Filip - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 9:27 AM Subject: Re: Invitation to HTTPD commiters in tomcat-dev Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Ok, I was wrong. Multiple protocol support is sometimes usefull :-), http and ftp are a good example of that. It wasn't in mod_jk. But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. Costin Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
ok, there are two very simple memory friendly ways to do sticky load balancing. And as a matter of fact, this is how some hardware loadbalancers do it. 1. Set a cookie on the clients machine - no server memory to hold a map 2. If the client doesn't accept cookies, do a simple sticky load balancing based on the IP of the client request. Again, no memory map needed. The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options above. So right then and there, there is one less thing to configure. Filip - Original Message - From: Graham Leggett [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 9:34 AM Subject: Re: Invitation to HTTPD commiters in tomcat-dev Costin Manolache wrote: But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. I think this is a good idea. Solve the general load balancer case first, then you will soon see whether HTTP works for everybody, or whether there is still a need for AJP. If there is a need, then someone will develop the AJP part of the module, but as the AJP module need not cocern itself with load balancing (that function being handled for it) it will be a far simpler module all round. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
I didn't say anything about just simple round robin the algorithm for distribution can be entirely separate from the stickiness as they are two separate things. The distribution algorithm, (round robin, load, random, etc) is separate and should not be confused. Stickyness means that if I have been to one server, I should go to that server again and again until that server fails or meets another criteria to not receive requests. Filip - Original Message - From: Mladen Turk [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 11:30 AM Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev Filip Hanik wrote: The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options above. So right then and there, there is one less thing to configure. Ok, If we'll make a lb for a mod_proxy, then at least it will need a balance load factor, not just sticky sessions and simple round robin. Also the JSESSIONID then does not to be harcoded, but rather configurable. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. cool, and then have the server just try them in that order? ie, if the sticky server went down, it just takes the next one from the list (and that list should be ordered well since it comes from the LB algorithm) correct assumption? Filip - Original Message - From: Mladen Turk [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 1:12 PM Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev Graham Leggett wrote: Yes, but why would you wish to separate those? Because they are two separate behaviours that could quite easily be used independantly of each other. OK, it makes sense. I'm not that familiar with mod_proxy code, so please no hooks, not jet :) I am familiar with the code, so don't be afraid of the hooks, as I'm quite willing to tell you where things go :) So, where do you see a lb code in the mod_proxy tree. Do you have some ideas where will it fit? It would be also good if you could make some p-code of the mod_proxy or some data flow diagram. Also do you need our support on coding? It would be perhaps better that you write the function prototypes that need some lb behavior returnig somethig like not_implemented or just mark some /* TODO: ...*/ in the code. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
really, so then there is no fail over. cause that is what fail over does, redirects you to another server. and with session replication in place, you should be good to go FIlip - Original Message - From: Mladen Turk [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 2:00 PM Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev Filip Hanik wrote: I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. cool, and then have the server just try them in that order? ie, if the sticky server went down, it just takes the next one from the list (and that list should be ordered well since it comes from the LB algorithm) correct assumption? Think that it should return 'Server Busy' in case the sticky is not available, cause you may be in the middle of transaction while the other server might have no clue about that. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.27 as Stable
ballot Release 5.0.27 as Stable: [X] Yes [ ] No /ballot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any synchronization issues with SMP?
Clustering is using GZIP byte only with byte array, so it doesnt link to an actual stream, only a byte array stream. Don't think we have a problem Houston! :) Filip - Original Message - From: Rainer Jung [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, July 02, 2004 3:59 AM Subject: Re: Any synchronization issues with SMP? TC clustering uses GZIP(In|Out)putStream in replication. I don't know, if there is buffering on top. Filip? Rainer Martin Schulz wrote: OT: The following is advice to servlet developers rather than container developers. For what it's worth, just be careful when you use GZIP(In|Out)putStream, since the native code uses a mutex (for no good reason, imho), to prevent garbage collection from interfering with the array being used. Bottleneck where I didn't expect one. In particular, never place a Object(In|Out)putStream directly on top of the GZIP streams, always use a buffer stream between the two. Reason is that the object stream reads/writes in very small chunks, causing four system calls per chunk. Or else interesting things are going to happen on larger SMP systems. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Ah ok. Filip was planning (to be forced through any means necessary) to do that, so ask him. yup, still planning on doing so :) just a little slammed with paying work at the moment Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, June 30, 2004 8:47 AM Subject: Re: [5.next] Progress Peter Rossbach wrote: Hello, I have start a Server saved implementation. - Externalize configuration saving out of StandardServer features: * splitt implementation from StandardServer class * refactor the current save methods to some helper classes * every save element from server.xml dialect has it own save factory * central Mbean that have a registry for save factories * save complete Server,Engine,Host or Context xml's * support cluster elements * implement with testcases options: * configure the save factories from xml or properties files. * better backup handling / not only for server.xml, also for context.xmls :-) I hope the first implementation is ready at this weekend. Sure, show me the code. see some comments directly at the 5.next topics. Remy Maucherat schrieb: My upcoming change list: - Attempt to redo a bit the deployer: * remove the CL code which is there to avoid JAR locking (or at least allow disabling this feature for non-Windows OSes); when enabling anti locking code, move everything to a temp deploy folder where everything will be referenced from; controlled by a development flag on the Context to allow disabling this on Windows Good option. I'm so tired of Windows right now ... - Externalize configuration saving out of StandardServer I can do that. I was planning to do it in 5 minutes (take the current code, put it in separate class, ) - BASIC auth optimization - clutering module refactoring, to extend the regular Catalina objects, for easier future maintenance I have a talk with Rainer Jung, and his changes to cluster implementation looks very good. Ah ok. Filip was planning (to be forced through any means necessary) to do that, so ask him. - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) I have made prototype for mx4J JSR 160 support it looks very nice. Can't we refactor the ServerLifecycleListener also? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29259 No, that listener needs to go IMO. This listener is useless in the end (for this branch): this is done at the VM level much more cleanly, and the VM also provides tons of runtime statistics that nobody will want to live without. I'll rethink my position if J2SE 5 (I'm learning ;) ) turns out bad somehow, but I don't think the core VM is a big rewrite, so I expect it to be stable. I'll start using it soon for my builds and testing, and I'll see how it goes. - And the ongoing: allow all config/management/embedding through JMX; note: I think this is almost there already (thanks Costin), so only a little tweaking will likely be needed YES! Lol. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Summary
yup, refatoring of clutering is something we need :) Will start as soon as tag 27 is in place, I will go over the details with you later Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, June 11, 2004 11:50 AM Subject: [5.next] Summary - Move to concrete classes for request/response, and remove all of the RTTI done in Catalina's pipeline - Use Tomcat 4.0 beta valve pattern - Redo logging using commons-logging, and remove Logger - Fork commons-digester, to remove what we don't need (many fancy features provided by beanutils, and in the process remove dependencies on beanutils and collections) - Attempt to redo a bit the deployer: * remove the CL code which is there to avoid JAR locking (or at least allow disabling this feature for non-Windows OSes) * move processing of context.xml to ContextConfig (at the expense of being able to specify the context class, which will move to an attribute on the Host), as I realize it is important to get context level configurability without adding too much complexity in the embedding application - Use the webapp CL as the main CL (without the locking tricks it is likely faster than the regular CL) - And the ongoing: allow all config/management through JMX (actually, we could consider going to a JMX config format) - Use any means necessary (hehe) so that Filip refactors the clutering module, and extend the regular Catalina objects, for easier maintenance - Remove anything useless (spring cleaning time), such as configuration options, container listeners (to be replaced with JMX notifications where it matters), etc - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) Overall, the throughtput of Tomcat should go up about 5-10% with those changes, as most significant optimizations are already done. I don't think any of these items will take too long to implement. I'm away next week, so I'll start the week after. Some of this could eventually be backported to 5.0.x :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp SimpleTcpCluster.java
Remy Wrote: I take note of your intent to refator as well. I'd like to point out that refatoring, unlike regular bland refactoring, is an art which takes years to master. Yes, refatoring is an art, and I intend to master it one day :) How about implementing your FarmWarDeployer as a replacement HostConfig instead ? This seems logical. Yes, that could work, and it is logical. So you would configure it as a life cycle listener of the host? Before I move to replace the host config with a cluster deployer, I want to fine tune the deployer a little bit. How about I make that part of my refatoring? I also noticed that currently the MBeanFactory has the HostConfig class hard coded when creating a standard host. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS branching
I'm planning to refator some and add a bunch of work into HEAD since this where we do dev, I suggest we go with remy's suggestion, to branch off 5.0.x and continue new dev into HEAD Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, June 02, 2004 12:14 PM Subject: Re: CVS branching Shapira, Yoav wrote: Hi, For now, I think a branch is only needed in jakarta-tomcat-catalina (if there are problems, I'll use a build2.xml in jakarta-tomcat-5 with temporary hacks). Would it be better if you did your refactoring in a branch and then merged into the main branch, overwriting as needed, when you're ready? The advantages would include an easier time for me when doing releases, and other people being able to build from HEAD (hopefully ;)). That's not how we do it, usually. HEAD remains the dev branch, while the stable releases are made from a branch. Working from a branch is not very different as working from HEAD, so I don't think you would run into trouble. But at least for now, I can create a Remy_Branch and hack. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS branching
Wouldn't you branch it now prior to any non-5.0 work being done on HEAD? yes - Original Message - From: Jess Holle [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, June 02, 2004 12:45 PM Subject: Re: CVS branching Shapira, Yoav wrote: Hi, OK, if we already have an established practice to continue development on HEAD, that's OK. I'll branch TOMCAT_5_0 when I tag 5.0.27 then. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
session facade not used for event
Quick question, is there a reason the user code has access to the internal session instead of the session facade on session events? event = new HttpSessionBindingEvent(this,name,value); //inside StandardSession as opposed to this code, which would give the user a facade? event = new HttpSessionBindingEvent(new SessionFacade(this),name,value); Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session facade not used for event
Facading is likely worthless for sessions, you think so, you don't think session.setPrincipal is a security issue? Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, June 01, 2004 3:02 PM Subject: Re: session facade not used for event Filip Hanik - Dev wrote: Quick question, is there a reason the user code has access to the internal session instead of the session facade on session events? event = new HttpSessionBindingEvent(this,name,value); //inside StandardSession as opposed to this code, which would give the user a facade? event = new HttpSessionBindingEvent(new SessionFacade(this),name,value); Yes, but no. Facading is likely worthless for sessions, as we're (fortunately) not recycling them anymore. The session manager will prevent accessing any of the extra methods (and even then, I'm not sure there's any public methods worth exploiting). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAASRealm enhancements
if you don't use it, how can you verify (test) that the patch works :) he he he. ~ Trust is good, control is better ~ I wouldn't commit a patch unless I had a test case, just to be on the safe side. Filip - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, May 26, 2004 2:08 PM Subject: JAASRealm enhancements Hi, Any comments on http://issues.apache.org/bugzilla/show_bug.cgi?id=28631 before I commit these patches? I don't use the JAASRealm myself but if anyone else does and doesn't like these enhancements, speak up. Yoav Shapira Millennium Research Informatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Protocol.java
+System.out.println(getClass().getName() +
:)
what is wrong with the logger?
Filip
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 27, 2004 11:12 AM
Subject: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Protocol.java
yoavs 2004/05/27 09:12:09
Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java
Log:
Added support for threadPriority attribute
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28914).
Revision ChangesPath
1.54 +13 -7
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
Index: Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- Http11Protocol.java 2 Mar 2004 01:17:39 - 1.53
+++ Http11Protocol.java 27 May 2004 16:12:09 - 1.54
@@ -76,14 +76,11 @@
public void setAttribute( String name, Object value ) {
if( log.isTraceEnabled())
log.trace(sm.getString(http11protocol.setattribute, name, value));
+
+System.out.println(getClass().getName() +
+ : setAttribute( + name + , + value + ): here.);
+
attributes.put(name, value);
-/*
-if (maxKeepAliveRequests.equals(name)) {
-maxKeepAliveRequests = Integer.parseInt((String) value.toString());
-} else if (port.equals(name)) {
-setPort(Integer.parseInt((String) value.toString()));
-}
-*/
}
public Object getAttribute( String key ) {
@@ -279,6 +276,15 @@
public void setMinSpareThreads( int minSpareThreads ) {
ep.setMinSpareThreads(minSpareThreads);
setAttribute(minSpareThreads, + minSpareThreads);
+}
+
+public void setThreadPriority(int threadPriority) {
+ ep.setThreadPriority(threadPriority);
+ setAttribute(threadPriority, + threadPriority);
+}
+
+public int getThreadPriority() {
+ return ep.getThreadPriority();
}
// Tcp setup
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time for 5.0.26?
I think Tuesday is good. I fixed some code that was broken in the simple manager implementation for clustering, most users use the DeltaManager, but some wish to use the old one, so that is all fixed Filip - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, May 27, 2004 3:12 PM Subject: Time for 5.0.26? Hi, We need to do a new release, 5.0.26, because of http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29255. Does anyone have stuff they're working on, and would therefore like me to wait a couple of days (or more, or less?) before tagging and building? I probably won't have time to do it before the weekend, and I'm out of town over the long weekend, so it'll be Tuesday at the earliest anyhow, unless Remy feels a desire to do it instead and we need to do it before Tuesday. Yoav Shapira Millennium Research Informatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java
- 5.0.25 +1 - A hotfix for 5.0.24 Big -1 Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, May 14, 2004 6:32 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java [EMAIL PROTECTED] wrote: remm2004/05/14 04:00:25 Modified:catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java Log: - Major mistake: the sever cookies should be parsed after the context is mapped, otherwise, the session cookie is never considered valid, and it will use the last one. - Bug 28971. So we're going to have a hotfix ... Two possibilities: - 5.0.25 (cool, I thought we had avoided it ;) ) - A hotfix for 5.0.24 (I'll put and sign a .zip and a .tgz, sign them, and link them from the news and binaries pages) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java
I guess I should explain, since a bunch of user already downloaded 5.0.24, it is not a good idea to release a fix with the same version number. Makes it a lot harder to help people out on the user list Filip - Original Message - From: Filip Hanik - Dev [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, May 14, 2004 9:14 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java - 5.0.25 +1 - A hotfix for 5.0.24 Big -1 Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, May 14, 2004 6:32 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java [EMAIL PROTECTED] wrote: remm2004/05/14 04:00:25 Modified:catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java Log: - Major mistake: the sever cookies should be parsed after the context is mapped, otherwise, the session cookie is never considered valid, and it will use the last one. - Bug 28971. So we're going to have a hotfix ... Two possibilities: - 5.0.25 (cool, I thought we had avoided it ;) ) - A hotfix for 5.0.24 (I'll put and sign a .zip and a .tgz, sign them, and link them from the news and binaries pages) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java
since when could a -1 be shut down by one person, you so far you only have one +1 (Jeanfrancois) Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, May 14, 2004 9:22 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java Filip Hanik - Dev wrote: - 5.0.25 +1 - A hotfix for 5.0.24 Big -1 You seem to be alone, so ... Sorry :/ Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java
roger that, didn't see the votes in tc-user, didn't even know we were voting in that forum :) Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, May 14, 2004 9:41 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java Filip Hanik - Dev wrote: since when could a -1 be shut down by one person, you so far you only have one +1 (Jeanfrancois) This is a release, not a vote with a veto. I have 3 yes (Yoav - look in tc-user: he fully agrees with this, JF, me), and 1 no (you), so it's enough to put out a package. Anyway, I don't think you can prevent the release of such a patch since it will be useful for people. I understand the point of trying to encourage releasing a new build very soon, but I don't see the point of forcing people to d/l and install a big bundle again just for a simple fix. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New RM for Tomcat 5
+1 - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, May 09, 2004 9:43 AM Subject: New RM for Tomcat 5 Hi, Yoav has expressed interest in being the release manager for Tomcat 5. Since he has shown interest in nearly all Tomcat components, and apparently has enough time at the moment, I think he would be the most qualified to replace me, and has my +1. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.23] Release vote
ballot Release 5.0.23 as Stable: [X] Yes [ ] No /ballot - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 04, 2004 6:21 AM Subject: [5.0.23] Release vote Since nobody seems to have any additional updates, here's the vote for the new build. Changelog: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/changelog.html ballot Release 5.0.23 as Stable: [X] Yes [ ] No /ballot Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] And of course you don't discuss this before making the change ? This is the old branch, so this is clearly not acceptable. I have to -1 regardless of the possible merits. Ok, so he forgot to ask the developers if this would be ok, no big deal. Can happen to anybody. But if someone is fixing code and improving it, I don't think a -1 is fair just because you felt that you werent able to control the changes. If there is more to the story which would require the -1 to go into effect, you would need to share that. take-it-lightlyAfter all, we are not running a Boss/JBoss show here :)/take-it-lightly So if there is more to it, share is please, so that we can all know why this change is not reasonable. It is not the -1 that I am against, it is the lack of explanation to it. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.23] Tag at the end of the week ?
10-4 - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, April 29, 2004 4:37 PM Subject: Re: [5.0.23] Tag at the end of the week ? Remy Maucherat wrote: I got some mojo back, and as a result I propose tagging a new release at the end of the week. I'm going to commit a few more pacthes, including improvements to SSO which were propsed. There are lots of JK issues filed for TC 5 (of course, it's not really related to the Tomcat release used). Does someone have time to look into them ? Reminder: I still plan to tag release tomorrow. Yes, I'm aware I'll have to do another tag sometime next week ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.23] Tag at the end of the week ?
he he he 10-4 in america is the roger that radio code. Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, April 29, 2004 5:06 PM Subject: Re: [5.0.23] Tag at the end of the week ? Filip Hanik - Dev wrote: 10-4 Let me guess ... 10 people will complain that their bug is not fixed in this release, and out of these, 4 will point out this is a critical issue and requires a new tag immidiately. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
