Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 15292 invoked from network); 4 Mar 2002 17:54:33 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 4 Mar 2002 17:54:33 -0000 Received: (qmail 21154 invoked by uid 97); 4 Mar 2002 17:53:46 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 21010 invoked by uid 97); 4 Mar 2002 17:53:44 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 20969 invoked from network); 4 Mar 2002 17:53:43 -0000 X-Authentication-Warning: localhost.localdomain: costinm owned process doing -bs Date: Mon, 4 Mar 2002 08:54:50 -0800 (PST) From: X-X-Sender: To: Tomcat Developers List Subject: RE: mod_jk2 config In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Mon, 4 Mar 2002, GOMEZ Henri wrote: > >uri.servletName:/my.host.com:8080/examples/HelloW=HelloWorldServlet > > Could we get these translation from web.xml forwarded by Ajp14 > autoconf feature ? We should get these from web.xml - either extracted directly or by extracting the info from tomcat. The information can be passed to jk via ajp14 ( wire ), or properties, or other methods. I don't think we can support ajp14 for the first release of jk2, the goal is to replace the old connector with one with the same features, but better interfaces ( and easier config, faster, etc ). We can add ajp14 later. > >With this jk will pass the servlet name to tomcat and eliminate the > >second mapping, like mod_jserv did. > > Why not just use : > > JkAutoMount webapp worker > > => get all mapping for a particular webapp for a worker There are 2 problems: - it requires tomcat to be started before apache - it's very tricky to even describe how this would work in a complex configuration ( multiple tomcats, multiple apache servers, etc). We'll add (back) this after we stabilize the code and release the first version ( and figure out how to do it ). BTW, I was thinking of separating the config protocol from normal ajp - the config is clearly not perf. critical ( no need for a binary protocol ). Instead of extending ajp13, we can have a simple ajp13 request to /jk2/servlet/autoConf?webapp=/examples ( done by a jk2 autoConfig worker ). That would return a normal response, with the body beeing a properties file in the same format as the one generated. The implementation is very simple ( most of the code already exists ), and would allow much easier programming, regular servlets - maybe with some container-specific code, for java ( like the manager or admin ), very little change in the C side. > What about jk-status which should present state of jk connections > and informations ? It's 'work in progress'. I want to get at least the basic things we had in jserv - especially for lb and worker status, plus some of the 'stop sending requests to this lb worker', 'add/remove a lb worker to the pool'. > Also are we agree in adding a REQUEST flag to LogLevel to be able > to track the query/reply timestamp ? +1 In addition some mgmt info in all objects - how many requests were served with each worker ( a simple ++ ), total/average time, number of errors, etc. Some may be enabled by default ( counters have minimal impact on perf. ), some with config ( if it requires calling system methods, like get time, etc ). getProperty() in each jk2 object is supposed to allow easy access to this information from the status worker or other means. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: