Re: fault-tolerant/backup_mode in mod_jk : Was: [j-t-c] OS poll = [j-t-c] webserver poll
Henri, This is actually very easy with the existing code and a tiny patch I submitted a few weeks ago. We're using it in production mode, so it is known to be stable. The first version I submitted had some additional logging added, but I'm attaching a minimal patch. All you have to do is set the lbfactor in workers.properties to 0, and it should never select that worker unless the session route points to it, or the primary worker is down. This also has the added benefit of making externally load balanced clusters behave properly for AOL/Compuserve users without special configuration of the load balancer. Those services use IP randomizing proxies which break generic IP-based sticky. This will cause the sessions to be re-routed from the Apache that receives the request to the Tomcat that initiated the session. This actually works, because we were able to remove all of our special configurations to deal with this from our load balancers. The problem is described at http://webmaster.info.aol.com/index.cfm?article=15 This patch changes the behavior by pre-initializing lb_value for each worker. The selection algorithm searches for the worker with the lowest lb_value that is not in a failed state. It then increments the lb_value by the lb_factor. lb_factor is set to the inverse (1/x) of the lb_factor specified in the config file. When lb_factor in the config file is 0, this number becomes basically MAX_DOUBLE. That means that lb_value becomes MAX_DOUBLE, so it will never be selected for any practical purposes. This patch has been tested extensivly in production use, and works perfectly. Paul Frieden GOMEZ Henri wrote: On Thu, Jun 14, 2001 at 10:28:47AM +0200, GOMEZ Henri wrote: mod_jk support Apache 2.0 And TC 4.0 as preliminary support for ajp13 used in mod_jk. Could you take a look at it ? Okay, what's the difference between mod_webapp and mod_jk? I thought that mod_webapp was the preferred TC 4.0 connector? This seems like this is worthy of a FAQ. We've still got people using mod_jserv... One of the goal of j-t-c, is to be the answer to : 'how to connect my webserver to tomcat ?' A great effort has been deployed in having an easy to use build stuff. Next effort will be documentation and ... lobbying :) Oh, is it that mod_webapp uses the Warp protocol, not ajp13? Does ajp13 support the TC 4.0 hot-deploy functionality? -- justin not in ajp13. But it's successor ajp14, have a strongest login procedure, and autoconf support (uri handled passed to web-server). Also planned is to inform the web-server of context state, ie when a context is put down (for admin purpose), the web-servlet must learn it and route request to another servlet-engine (if we are in load-balancing configuration). what make me think we should add a fault-tolerant/backup-mode worker in mod_jk. A la load-balancing, having a group of worker (servlet engine), with one principal, and many as backup. If the principal could no more handle a request (failure or context down), just have the request routed to next worker in list. What about ? --- jk_lb_worker.orig Fri Jun 15 10:23:42 2001 +++ jk_lb_worker.c Fri Jun 15 10:23:54 2001 @@ -426,7 +426,7 @@ p-lb_workers[i].lb_factor = jk_get_lb_factor(props, worker_names[i]); p-lb_workers[i].lb_factor = 1/p-lb_workers[i].lb_factor; -p-lb_workers[i].lb_value = 0.0; +p-lb_workers[i].lb_value = p-lb_workers[i].lb_factor; p-lb_workers[i].in_error_state = JK_FALSE; p-lb_workers[i].in_recovering = JK_FALSE; if(!wc_create_worker(p-lb_workers[i].name,
[PATCH] jk_lb_worker patch
Attached is a patch for the lb worker for mod_jk. Basically, it changes
the selection behavior slightly and adds some error and debugging
logging where we would find it useful.
The code uses two variables, lb_factor, and lb_value. lb_factor is the
numerical inverse (1/x) of what is entered into the workers.properties
file. This causes the lb_factor to become very large if the lb_factor
in workers.properties is 0. lb_value always starts at 0.
The decision of which worker is used is based on lb_value. The worker
with the lowest lb_value gets selected to service a request. After a
worker is used, its lb_value is incremented by lb_factor.
Unfortunately, this causes the balancer to service at least one request
on each worker before the lb_factor actually has any effect. This one
request will often lead to an entire session being served off of a
different worker.
This behavior isn't really a problem, but in a scenario where you have
an external load balancer, it is preferable to try to honor its
decisions except where there is an error. Such an error can happen with
providers that use IP randomizing proxies such as AOL. Its also nice to
be more deterministic in the normal case.
This patch seeds the lb_value with 1/lb_factor. This changes the
behavior by causing lb_value to be larger for servers with lower weights
than servers with higher weights. If the lb_factor in
workers.properties is 0, it becomes very large and should only be
selected in the case of all the regular workers being unavailable or due
to a session route.
I added error logging for if the worker specified by the session route
is unavailable. I added debug logging for selecting a worker by session
route, and for which worker is selected.
This hasn't been tested much, but its almost a trivial change. This is
against 3.2.1, but it should apply clean to later versions as well.
Feedback is welcome.
Paul
--- /tmp/jakarta-tomcat-3.2.1-src/src/native/jk/jk_lb_worker.c Tue Dec 12 16:51:56
2000
+++ ../jk/jk_lb_worker.cMon May 7 16:23:20 2001
@@ -244,7 +244,8 @@
}
static worker_record_t *get_most_suitable_worker(lb_worker_t *p,
- jk_ws_service_t *s)
+ jk_ws_service_t *s,
+jk_logger_t *l)
{
worker_record_t *rc = NULL;
double lb_min = 0.0;
@@ -255,8 +256,14 @@
for(i = 0 ; i p-num_of_workers ; i++) {
if(0 == strcmp(session_route, p-lb_workers[i].name)) {
if(p-lb_workers[i].in_error_state) {
- break;
+ jk_log(l, JK_LOG_ERROR,
+ In get_most_suitable_worker, requested worker (%s)
+unavailable, redirecting session\n,
+ p-lb_workers[i].name);
+ break;
} else {
+ jk_log(l, JK_LOG_DEBUG,
+ In get_most_suitable_worker, selected %s because of
+session_route\n,
+ p-lb_workers[i].name);
return (p-lb_workers[i]);
}
}
@@ -282,13 +289,13 @@
lb_min = p-lb_workers[i].lb_value;
rc = (p-lb_workers[i]);
}
-}
+}
}
if(rc) {
rc-lb_value += rc-lb_factor;
+ jk_log(l, JK_LOG_DEBUG, In get_most_suitable_worker, selected %s\n,
+rc-name);
}
-
return rc;
}
@@ -309,7 +316,7 @@
while(1) {
-worker_record_t *rec = get_most_suitable_worker(p-worker, s);
+worker_record_t *rec = get_most_suitable_worker(p-worker, s, l);
int rc;
if(rec) {
@@ -347,7 +354,7 @@
* Error is not recoverable - break with an error.
*/
jk_log(l, JK_LOG_ERROR,
- In jk_endpoint_t::service, none recoverable error...\n);
+ In jk_endpoint_t::service, non recoverable error...\n);
break;
}
@@ -426,7 +433,7 @@
p-lb_workers[i].lb_factor = jk_get_lb_factor(props,
worker_names[i]);
p-lb_workers[i].lb_factor = 1/p-lb_workers[i].lb_factor;
-p-lb_workers[i].lb_value = 0.0;
+p-lb_workers[i].lb_value = p-lb_workers[i].lb_factor;
p-lb_workers[i].in_error_state = JK_FALSE;
p-lb_workers[i].in_recovering = JK_FALSE;
if(!wc_create_worker(p-lb_workers[i].name,
Re: Jakarta PMC Meeting Agenda / Info
Rather than add fuel to the fire, I would like to summarize what I need out of a servlet engine. Hopefully this will help the members of the PMC make the correct decisions based off of what users need. High Priority: * Stability We've been running Tomcat 3.1 without any problems for quite a while now, and it has held well under moderate production load, as well as very high testing load. The speed could be better, but its stable. * Speed Everybody wants speed, but in a hosting operation such as ours, the faster the software, the fewer servers we will need to add to support the load. * Mature, stable web server connector This is of utmost importance. We would like for this to have some features in support of load balancing, but we won't be using it to actually do the load balancing. An example of this is session routing. The only load balancers that can handle IP randomizing proxies and HTTP-HTTPS transitions are SSL accelerators, and there aren't as many of those on the market as regular load balancers. * Virtual Hosting We need to be able to have the same context names, specifically the root context, under multiple hosts. Low Priority: * Built in HTTP server We currently use Apache httpd, and will continue to do so for its flexibility. * API 2.3 As long as the API is 100% backwards compatible, we don't really care if it implements 2.3. We just don't plan to implement it for the time being. I would also like to say that everybody involved in this flame could be a little more civil and still make their strong opinions known. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [MY_OPINION] Tomcat 3.x
Not everybody is in a position to throw away their investment in the 3.x series just yet. While its fun to try the latest and greatest, not everybody can do that. Craig, is java.sun.com running on Tomcat 4.0? Jon, is www.apache.org running Apache 2.0 yet? When do you think they will be ready to run those packages? While this may be a "reference implementation," it is still being used in production environments. Production environments have very different requirements than development environments. Does Tomcat 3.x have bugs? Absolutely. But we've found those bugs in our QA environment, identified them, and worked around them as needed. Tomcat 4.0 will have a whole new set of bugs that we will need to spend time working around. We're still running our sites on 3.1, because we haven't had time to re-do the verification work with 3.2 yet. I'm just saying that while Tomcat 4.0 may have the most perfect design, it is un-proven in production environments. Tomcat 3.x has been proven for our application. We need to continue the 3.x tree at least until 4.0 is proven as ready. That takes time. 3.x has been brewing for a very long time. There have been lots of changes, but more has stayed the same than has changed. Tomcat 4.0 is almost entirely new code. We need something we can count on for production. Tomcat 4.0 isn't there yet. I also think that its appalling that people should tell Costin to go away. The Apache project should be very very thankful that they have somebody around to maintain the code that others have abandoned. Where would we be if the latest stable version of Apache was 1.3.0, and all the other developers had run off to work on 2.0? If that had happened, the Apache project would have been dismissed by everybody as a toy, and Apache wouldn't be in the position it is in today. Paul Frieden PS: www.apache.org runs Apache 1.3.15-dev, and java.sun.com runs Apache 1.3.3. GOMEZ Henri wrote: It really scares me that you are the only person (as far as I can tell) that is seriously interested in maintaining and developing Tomcat 3.x into the future. It is not good to have the entire rest of the core developers work on Tomcat 4.x and having you sit here and say that you are going to work towards back porting everything that the Tomcat 4.x people come up with on your own. Talk about a complete duplication of effort by only a single individual. * Costin is not alone on the TC 3.3 tree. You could see there is contributions 3.3 from Larry, Nacho and Dan. I can't even understand someone wanting to base their work on Tomcat 3.x when all of the core developer support (ie: more than just one person) is going towards Tomcat 4.x. * Hey, don't forget that tomcat 3.x is now the only real running distribution. Me and others see TC 4.0 as an experimental product, a way to test and validate the servlet 2.3 and JSP 1.2 API. I *personally* think that you should either drop your Tomcat 3.x development and work towards making Tomcat 4.0 have all the features and benefits that you want to see in Tomcat 3.x (and thus show that we are all working together instead of this constant fork within the overall Tomcat project) or simply fork what you are doing into another project that is hosted somewhere else. * The good point with TC 4.0 are all the good things inside (JMX, JAXP 1.0/1.1) The bad point on TC 4.0 are all these good things (JMX, JAXP 1.0/1.1). You have seens the thread on '[PROPOSAL] building is easy'. We need too many things now to build TC 4.0. Also even if TC 4.0 is an OpenSource projects, too many of the required packages are not 'Open Sourced' or not easily exportable. Also many peoples want to have a fast servlet engine with a low memory profile. I saw TC 4.0 to be much hungry. In fact, I'm pretty strongly -1 on Tomcat 3.3. If anything it would need to be suggested as Tomcat 5.0 because as far as I can tell, we have already come to the conclusion that Catalina will be Tomcat 4.0. * Why not consider TC 3.3 as a light servlet engine ? It make sense since many sites will not need all the stuff inside TC 4.0. I hope that Apache Group will not forget that many of the web sites which run it's httpd servlet are personal computers and not clusters of Ghz CPUs and Gb of RAM. Don't take what I said as me kicking you out or killing things or anything even remotely personal. What I'm most concerned with here is the overall Tomcat project goals and seeing you duplicating work and effort is really not making me happy. Sure, you could say that the goals might be flawed in your opinion, which is perfectly valid, but the fact of the matter is that the rest of the people on the project are working towards making Tomcat 4.0 the future. * I don't saw that as a duplicate effort. TC 3.3 is the continuation of 3.x tree. TC 4.0 is much more ambitiuous and nice for the n
Re: how to maintain session between HTTP and HTTPS?
In a load balanced environment, this is tricky with people behind a IP randomizing proxy (like AOL). If you use all SSL, the load balancer can track the SSL session ID across different IPs. If you use all non-SSL, you can track with a cookie. You can use IP based sticky if the IP stays the same. Its tricky if you have to mix more than one of those. What we're doing is using IP sticky with our load balancers, with mod_jk sending all new sessions to the local server, and redistributing them to the proper server if they aren't local. I might write up a document describing how we run Tomcat in this environment if anybody is interested. Paul
Re: Tomcat sessions and load balancing
I take your message to mean that you have an external load balancing device. We're doing the same thing. We're using mod_jk, and the lbworker. You'll need to define all your servers in workers.properties. We set the weight much higher on the local server because we have IP based sticky session in our load balancers and they normally get it right. The documentation covers how to do the configuration, but doesn't actually explain how the lbworker can be used in an external load balanced configuration. Has it been added in the new documentation waiting in CVS? If not, I'd be willing to write up a section on it. Anybody interested? Paul Frieden On Wed, 6 Dec 2000, Bohm, Matt wrote: I am a programmer in an environment that features load balancing on 3 production machines. Typically, requests to a given URL will be routed to any of the three machines, depending on which is the least busy. Can Tomcat session management work correctly in this environment? In other words, will requests associated with a given session always return to the machine where the session originated? Matt
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/http Cookies.java ServerCookie.java
I was just flipping through this code because I did some changes to
CookieTools. To force a V0 cookie to be deleted properly, the time
should actually be set way in the past rather than the current time to
make it be deleted properly. I did it by checking if maxAge was 0 and
setting the expires time way back if it was rather than converting the
current time to the expiration time.
Paul
[EMAIL PROTECTED] wrote:
costin 00/11/30 22:00:39
Modified:src/facade22/org/apache/tomcat/facade
HttpServletRequestFacade.java
HttpServletResponseFacade.java
src/share/org/apache/tomcat/core Request.java
src/share/org/apache/tomcat/helper CookieTools.java
src/share/org/apache/tomcat/modules/session SessionId.java
src/share/org/apache/tomcat/util/http Cookies.java
ServerCookie.java
Added: src/examples/WEB-INF/classes CookieExample1.java
Log:
- Start using Cookies and the enhanced ServerCookie.
- CookieTools are no longer needed ( it's all commented out, will be
removed after I test the new code )
- Added a new example, that supports all V1 attributes ( even if no
browser except lynx can be use V1 ) - it is needed to verify the
parsing code works for V1.
- The code now uses RFC2109 ( easy to go forward to 2965 ). Discard is removed,
since it's in the new spec.
Revision ChangesPath
1.1
jakarta-tomcat/src/examples/WEB-INF/classes/CookieExample1.java
Index: CookieExample1.java
===
/* $Id: CookieExample1.java,v 1.1 2000/12/01 06:00:23 costin Exp $
*
*/
import java.io.*;
import java.text.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
/**
* Example servlet showing request headers
*
* @author James Duncan Davidson [EMAIL PROTECTED]
*/
public class CookieExample1 extends HttpServlet {
ResourceBundle rb = ResourceBundle.getBundle("LocalStrings");
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("html");
out.println("body bgcolor=\"white\"");
out.println("head");
String title = rb.getString("cookies.title");
out.println("title" + title + "/title");
out.println("/head");
out.println("body");
// relative links
// XXX
// making these absolute till we work out the
// addition of a PathInfo issue
out.println("a href=\"/examples/servlets/cookies.html\"");
out.println("img src=\"/examples/images/code.gif\" height=24 " +
"width=24 align=right border=0 alt=\"view code\"/a");
out.println("a href=\"/examples/servlets/index.html\"");
out.println("img src=\"/examples/images/return.gif\" height=24 " +
"width=24 align=right border=0 alt=\"return\"/a");
out.println("h3" + title + "/h3");
Cookie[] cookies = request.getCookies();
if (cookies.length 0) {
out.println(rb.getString("cookies.cookies") + "br");
for (int i = 0; i cookies.length; i++) {
Cookie cookie = cookies[i];
out.print("Cookie Name: " + cookie.getName() + "br");
out.print("Cookie Value: " + cookie.getValue() + "br");
out.println("Cookie Version: " + cookie.getVersion() + "br");
out.println("Cookie Domain: " + cookie.getDomain() + "br");
out.println("Cookie Path: " + cookie.getPath() + "br");
out.println("br");
}
} else {
out.println(rb.getString("cookies.no-cookies"));
}
String cookieName = request.getParameter("cookiename");
String cookieValue = request.getParameter("cookievalue");
String path= request.getParameter( "cookiepath" );
String domain= request.getParameter( "cookiedomain" );
String secure= request.getParameter( "cookiesecure" );
String version= request.getParameter( "cookieversion" );
String comment= request.getParameter( "cookiecomment" );
String maxage= request.getParameter( "cookiemaxage" );
if (cookieName != null !"".equals( cookieName) ) {
// cookie without value is valid !
Cookie cookie = new Cookie(cookieName, cookieValue);
if( ! "".equals( path ))
cookie.setPath( path );
if( ! "".equals( domain ))
cookie.setDomain( domain
Re: Fw: Virtual Hosts and Context Path Question
We're doing essentially the same thing. First thing you'll need to do is upgrade to Tomcat 3.2. There are lots of reasons other than the virtual hosting support to do this. If you use multiple Host name="..." entries where the name matches the ServerName from httpd.conf, it should pick the proper host. Each Host can have its own context with path="". Example httpd.conf: VirtualHost www.a.com ServerName www.a.com DocumentRoot /opt/tomcat/webapps/www.a.com JkMount /servlet/* lbworker JkMount /*.jsp lbworker /VirtualHost VirtualHost www.b.com ServerName www.b.com DocumentRoot /opt/tomcat/webapps/www.b.com JkMount /servlet/* lbworker JkMount /*.jsp lbworker /VirtualHost Example server.xml: Host name="www.a.com" Context path="" docBase="webapps/www.a.com" / /Host Host name="www.b.com" Context path="" docBase="webapps/www.b.com" / /Host I don't think there is any reason why this wouldn't work with mod_jserv, but I've only tested it with mod_jk and ajp12. Is this documented in the new user guides? If not, it might be helpful if it was. Paul Frieden Shahed Ali wrote: -Original Message- From: Shahed Ali [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Friday, December 01, 2000 11:33 AM Subject: Virtual Hosts and Context Path Question I am running Apache Stronghold with Virtual Hosts and Tomcat 3.1 I am using Named Hosts and have www.a.com and www.b.com both pointing to the same IP address. Now when I go to http://www.a.com I want my DoucmentRoot to point to /usr/local/jakarta-tomcat/webapps/A_APP/index.jsp But I also have to modify the Context Path = "" in server.xml to point to webapps/MYAPP Now suppose I want http://www.b.com to point to /usr/local/jakarta-tomcat/webapps/B_APP/index.jsp, I would need to also set the Context path = "" ? How can I go about doing this ? OR Or If I have virtual hosts using the same Tomcat Server, then do I need to keep all my jsp stuff in different contexts and Set up an alias in each virtual host = Context Path ? So when I want to serve up jsp pages for site A I say http://www.a.com/siteAjsp/myapp.jsp And when I want to serve up jsp pages for site B I say http://www.b.com/siteBjsp/myapp.jsp Where siteAjsp , siteBjsp etc all have to be unique aliases/context-paths combinations. Eg NameVirtualHost 192.168.5.100 Virtual Host 192.168.5.100 ServerName www.a.com DocumentRoot "/home/a" Alias /siteAjsp "/usr/local/jakarta/tomcat/webapps/siteAjsp" ApJServMount /siteAjsp/servlet /siteAjsp Location /siteAjsp/WEB-INF . /Location /Virtual Host For this Host in server.xml Context path="/siteAjsp" docbase = "webapps/siteAjsp" Virtual Host 192.168.5.100 ServerName www.b.com DocumentRoot "/home/a" Alias /siteBjsp "/usr/local/jakarta/tomcat/webapps/siteBjsp" ApJServMount /siteBjsp/servlet /siteBjsp Location /siteAjsp/WEB-INF . /Location /Virtual Host For this Host in server.xml Context path="/siteBjsp" docbase = "webapps/siteBjsp" Thanks Shahed
Re: No revolution today
In our situation, we plan to use multiple virtual hosts, each with its own root context. That makes the URLs shorter and easier for people to work with. It also lets you more easily move/copy one context to another without having to fix all the links. I've posted patches that make this work for us in the past, along with several other patches for cookie behavior. We're not running this in production yet, but I've had load balancing working as expected (as far as I can tell) with mod_jk and tomcat_32. I don't have the load balancing hardware available for testing, but I've set up DNS round robin, as well as things like killing apache on one host to force it to the other and the sessions being routed properly. If anybody is interested in the patches, let me know and I'll post them to the list again. One fixed root context load balancing (at least for us), cookie deletion, session cookie selection, and one that prevents session cookies other than the valid one from being leaked into a webapp. I'd also like to cast my vote for a production quality release and continued development of tomcat 3.x for production use. Tomcat 4.0 may be elegant, but what I need right now is robust and fast Servlet 2.2/JSP 1.1. Paul Frieden Joseph Chiu wrote: Matthew, In my environment, I wanted to force all contexts to be in the root context. So, my point is -- if you only need the root context (one context only!), my kludge works. If you want root context and non-root contexts to both coexist, then you'll need to modify my kludge to NOT force the context to the root context. You'll have to test it to see if it works for you (because I haven't). I think Andrew Cowie did the latter (not force the contexts to the root context), but I don't want to speak for him. If you need multiple contexts without the root context, then the existing Tomcat should be perfectly fine. Joseph -Original Message- From: Matthew Dornquast [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 09, 2000 2:28 PM To: [EMAIL PROTECTED] Subject: Re: No revolution today Well, but if you don't need the root-context, then the load balancing *should* work with other contexts. You are using mod_jserv with APJ Balancesets, right? Right Jospeh! So how important is it to support load balancing of root contexts? How many users use the root context? From where I sit, it's a requirement, I have no other option. I don't want to go into the reasons as to why this is, (Unless there is a great deal of interest) but I do wonder how many others are doing it like I am? its a big change. fix for 3.3 ? This would seriously nuke loadbalancing for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable out after so many months (years?). I wish I knew if it was a big change or not. When I was trying to do it, it felt like it was more of a mod_jserv issue and had little/nothing to do with tomcat. It seemed like mod_serv config parser just couldn't grok what I was telling it. (Kudos to the designer(s) of the API for mod_jserv, I thought it well thought out and easy to config given the amount of power/flexibility they were giving me.) 3.2 Stable is very important, at a minimum however, documentation should be updated to state it's not supported in 3.2 root context. -matthew - 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: Tomcat 3.3 / 4.0 confusion, rant and plan...
I'd like to speak up about this briefly. Catalina/Tomcat-4.0 may be the future which is fine, but Tomcat is now being used in production settings. We've been testing the 3.2b* releases and the performance is better than 3.1 which is important for us. The performance of 3.3 is supposed to be better still. Catalina may have the perfect design, but I can't say anything about that because I haven't gotten time to look at the code. From previous emails though, it sounds like the supporting code such as Apache httpd connectors may not be ready yet, let alone tested. Mod_jk wasn't perfect at the last time that I tested it, but it was functional. What am I saying? Tomcat 3.x may not be perfect yet, but it has the supporting software in place and working. Catalina may have the perfect embedded http server, but that is of no interest to us. We need the speed and flexibility of the Apache httpd. What I'm asking is will Catalina be ready for production usage any time soon? Has it been tuned for speed yet? As for 3.3, I see it as a finish of what 3.2 started. We don't need Servlet 2.3 yet, so that isn't important to us. What we need is stability and performance. Once 3.2 is in production use, people will find bugs and problems. Thats the nature of software. I think that should be the real place of 3.3. Take what has been done as far as performance, and the fixes for bugs and spec compliance issues from 3.2 and put them in 3.3 and release that. I think that perhaps the choice between the 3.x architecture and the Catalina proposal may have been a little premature. Catalina doesn't have the supporting features yet that the 3.x series has. We can't do a head-to-head comparison between the two because Catalina doesn't have the connectors in place yet. I would like to thank Costin and everybody involved in the 3.x series. They took a non-optimal code base and turned it into something suitable for production use. They got it up and running soon enough that it has been able to get traction in the industry and let us develop applications based off the newer specifications. They made the way for Tomcat 4.0, whatever code that may be. I don't think that code that works now should be thrown away until the code that is intended to replace it is ready to replace it. Paul Frieden On Sat, 4 Nov 2000 [EMAIL PROTECTED] wrote: time explaining to people, "Well, 3.x is sort of this unfinished thing that they weren't happy with, so they started 4.x". To me, that DOES give the 3.x and 4.x are 2 different servlet containers, with very different design. The only confusing thing is the fact that the same name is used for both, and the number looks like 4 is a continuation of 3. Which one is better should be based on code reading and real-world testing, not on the number that is stick on it. ( BTW, the feature set is very different, the core design is different and of course the performance is different too ) Again, I don't remember when Apache decided to throw away a particular design and codebase and the reasons behind it, but if Members decide so I don't think I can do too much about it. Costin - 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]
