>> >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.
tomcat allready decode the information and could send them in a simpler form to jk. >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. so ajp14 will be out of scope in jk2 initial release ? >> >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 He he, not necessary. 1) We could keep a copy on jk side of previously received autoconf information and keep it till the tomcat came back to live. This information will be marked 'not verified' and at the first request for a webapp, ie /examples/servlet/Hello, we should first ask for autoconf refresh. 2) Did we have a in Apache/IIS/iPlanet a way to do the autoconf query retry at a later time ? In Apache 1.3 (not sure for 2.0) each module is called when a request arrive, and we could retry at this time (delaying it a little), ie make a retry each 5/10s. >- it's very tricky to even describe how this would work in a >complex configuration ( multiple tomcats, multiple apache servers, >etc). That's an interesting issue, and may be not so hard that we could imagine. JkAutoMount examples worker just tell web-server that all request to webapp examples should be forwarded to a particular worker. This worker could be a single tomcat or a cluster of tomcat in lb mode (and in that case they should all have the same settings). JkAutoMount examples worker without autoconf information should be seen like : JkSet /examples/* worker In first approach everything under /examples will be forwarded to worker and autoconf will specify (reduce) which URI/MIME will be handled really. >We'll add (back) this after we stabilize the code and release >the first version ( and figure out how to do it ). Ok >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. Yes, may be easier to implement (what do you think about TC3/TC4 developpers ?) >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. A big plus. >> 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'. good >> Also are we agree in adding a REQUEST flag to LogLevel to be able >> to track the query/reply timestamp ? > >+1 And these informations could be also make available to jk-status, which make it a perfect control-desk. >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. Which make me think that time() call is a consuming task and I wonder if there is provision to a faster replacement in Apache 1.3 / 2.0 (via APR) ? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
