RE: Use of Apache proxy module to connect to Tomcat
>Of course it is. > >Proxy HTTP is probably not as efficient as a lightweight >protocol (ie: AJP), >especially if the two systems are running on the same box (ie: local >sockets). > >It also doesn't solve the configuration issues. > >All you are doing in this case is putting another layer in front of the >Tomcat HTTPd. I don't see a reason to do that when the Tomcat >HTTPd works >just fine. All you are gaining is the Apache module features (like >mod_rewrite). And mod_jk / ajp allow you to have one Apache HTTP server connected to many Tomcat to do load-balancing and fault-tolerance. And it is indispensable when your site grow..
CVS / mod_webapp / web-connector sub-project
Fine to see mod_webapp back to life :) 1) You added many features interesting in building (autoconf, apr) which we could study to adapt to mod_jk (at least autoconf). 2) I plan to update the mod_webapp RPM and hope the code will compile under GCC (it wasn't the case with tc 4.0b2/b3) 3) You still didn't tell us what you think into merging mod_webapp and mod_jk. Why not use mod_webapp/mod_jk to start the web-connector sub-project allowing us to remove many question related to connectors from Tomcat user/dev lists ? The same web-connector project could be used against Tomcat 3.2/3.3/4.0 but not be restricted to Tomcat. Any project understanding the concept of HTTP request/reply could use it. Much more what about using the connector to have the Apache store sessions (serialized) data from Tomcat. Here is the idea : - One Apache may be connected to multiple Tomcat (TomcatA/TomcatB). - Each Tomcat have sessions related data which may be good to see available to other Tomcats in case of failure : ie: TomcatA create a session and data in that session. When replying to Apache (via mod_jk or mod_webapp) it also send the session datas (serialized) when they are created (or updated). Apache store that informations for possible future use (db1/gdb) TomcatA fail (stopped, restarted, jvm dumped...) and Apache (via at least mod_jk) decide to route the request to TomcatB. TomcatB miss the session datas allready generated by TomcatA but Apache could route the request ALONG WITH THE previously saved session informations. TomcatB could then recreate the session, set the session data and then serve the request in the same condition that TomcatA. You get a real fault-tolerant system (no need to resign in some case). What do you think about that proposal (Costin, Craig, Dan, Jon, Pier...) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: mod_webapp, mod_jk etc.
>Forgot to ask, would you be interested in instructions/simple shell >script for building mod_jk as a statically linked Apache module? > Yes, certainly. Instruction and better shell script :) But did mod_jk is really faster in statically mode rather in DSO ? >Bojan > >Dan Milstein wrote: >> >> I can't speak to mod_webapp, but a mod_jk response: >> >> > - I understand the need for the TCP connections to be persistent in >> > mod_jk and mod_webapp, but I'm not sure why another >connection wouldn't >> > be attempted after the reuse of the previous connection fails; >> >> This was just added to the 3.3 branch (by Henri) for mod_jk >-- if the Apache >> plugin detects a dead connection, it opens a new one (so you >don't have to >> restart Apache when you restart Tomcat). Needs testing, but >it's in there. >> >> -Dan >> -- >> >> Dan Milstein // [EMAIL PROTECTED] >
TC 4.0B3 src missing
Could someone upload the servlet and tomcat sources to : http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b3/src/ I could get it from CVS but RPM convention insist having .tar.gz somewhere :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Torgeir Veimo [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, April 17, 2001 11:34 AM >To: [EMAIL PROTECTED] >Subject: Re: [Tomcat 4] - JndiRealm Proposals > > >"Craig R. McClanahan" wrote: >> >> * Support for two major modes of operation: >> >> * SYSTEM LOGIN. Realm implementation binds itself to the >server using >> a system-level username/password, then reads the >username and password >> attributes to perform authentication (analogous to how JDBCRealm >> works). Would also support the optional digesting >functionality that >> JDBCRealm supports. >> >> * USER LOGIN. Realm implementation attempts to bind to the server >> using the username and password specified by the user. >If this is >> successful, the user is considered to be authenticated, and the >> associated roles are looked up. > >This is the way we do it, but it has the problem of not being >able to be >used with digest authentication, since the input to the digest method >are different when done on the LDAP server, and when done by the http >client. (Ok, maybe a genious of an SASL expert could do it, >but it would >require getting the nounce from the LDAP server, which would require >some modification to some tomcat classes.) > > > > >-- >- Torgeir >
RE: CVS / mod_webapp / web-connector sub-project
>> 3) You still didn't tell us what you think into merging mod_webapp >> and mod_jk. > >And I'll continue to be silent on that... As I don't really >want to start another flamewar... >I've been thru enough already on that, and >all I can say >is that I'll let the people on this list (but me) decide... How could you be silent on that since you're the only developper on mod_webapp ? I didn't see why a flamewar must start here. What we're discussing here is technic not politic, and it's an open and honest thread. mod_jk is the de-facto standard to link a web server (not only Apache) to tomcat. mod_webapp is really new and having it incompatible with mod_jk will raise more questions and requests than necessary. >> Why not use mod_webapp/mod_jk to start the >> web-connector sub-project allowing us to remove many question >> related to connectors from Tomcat user/dev lists ? > >Make a proposal... The proposal is simple. Just remove all connector stuff, both native and java code from tomcat 3.3/4.0 tree and move it to another sub-project. As I said it will remove connectors questions from Tomcat list. Merging mod_jk and mod_webapp will help people switching from Tomcat 3.2.x to Tomcat 4.0 without changing anything from there webserver side. Many sites will strongly require to have a AJP12/AJP13 connectors in Tomcat 4.0 since they may have mixed Tomcats systems 3.x and 4.0 and we just can't demand them to just do the 'big bang' and replace their running mod_jserv/mod_jk by mod_webapp. the ajp12/ajp13 integration in Tomcat 4.0 is a pragmatic and realist choice. What about VOTE like : [ ] I want to have a ajp12/ajp13 in Tomcat 4.0 ? [ ] I don't want to have a ajp12/ajp13 in Tomcat 4.0 ? >> The same web-connector project could be used against >> Tomcat 3.2/3.3/4.0 but not be restricted to Tomcat. >> Any project understanding the concept of HTTP request/reply >> could use it. > >Probably what you want to see is something more like mod_backend... What's mod_backend ? > >> Much more what about using the connector to have the Apache >> store sessions (serialized) data from Tomcat. >> >> Here is the idea : >> >> - One Apache may be connected to multiple Tomcat (TomcatA/TomcatB). >> >> - Each Tomcat have sessions related data which may be good to >> see available to other Tomcats in case of failure : >> >> ie: >> >> TomcatA create a session and data in that session. >> >> When replying to Apache (via mod_jk or mod_webapp) it also >> send the session datas (serialized) when they are created >> (or updated). >> >> Apache store that informations for possible future use (db1/gdb) >> >> TomcatA fail (stopped, restarted, jvm dumped...) and Apache >> (via at least mod_jk) decide to route the request to TomcatB. >> TomcatB miss the session datas allready generated by TomcatA but >> >> Apache could route the request ALONG WITH THE previously saved >> session >> informations. TomcatB could then recreate the session, set the >> session data and then serve the request in the same condition that >> TomcatA. >> >> You get a real fault-tolerant system (no need to resign in some >> case). > >I don't see this as a viable solution... Storing session data >within the web >server itself is tricky, and definitely not what I would like >to see, but I >live up the decision to the list... > >How do you approach the case where multiple web servers are a >front end to >multiple servlet containers? I still doubt that storing sessions in the >server does the trick... > >> What do you think about that proposal (Costin, Craig, Dan, >Jon, Pier...) > >The only solution I see is to have sessions shared on the back of the >servlet container, and do the web server do its job (without >loading up with >too much crap) Did there is a project somewhere to store the session outside the tomcat ? A persistant session storage hosted in a web server may be bad but I'm ready to try other solutions Henri (Going Bed)
TC 4.0B3 RPM available
RPM built and uploaded to : http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b3/rpms/ - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: CVS / mod_webapp / web-connector sub-project
>I think Dan is right on this one - improving the configuration >of mod_jk >is probably the most important thing, and merging with mod_webapp and >porting it's protocol and config mechanism would be a good way >to do that. I agree that integrating mod_webapp functionnalities is not a priority for the 3.x branch. We could add the autoconf stuff or may be also use APR which will hide all OS complexity. The problem today, is that there is 2 version of mod_jk : *) mod_jk in Tomcat 3.3 Latest code, maintainers, bugs fixed and Apache 1.3/2.0 support *) mod_jk in Tomcat 3.2.x The same code since 3.2, no much maintainers, some bugs fixed in 3.3 are not in 3.2, only Apache 1.3 support. If a user have problem using mod_jk against it's Tomcat 3.2.1 release (or upcoming Tomcat 3.2.2), we'll ask him to use the mod_jk from Tomcat 3.3 CVS ! Problems could be using Apache 2.0 or Apache restart needed after Tomcat shutdown/restart when using ajp13, . >I think the best way to do that would be a revolution ( like >jasper34 ), >and when it's ready propose it as either a replacement for >both mod_jk and >mod_webapp, or as a top level project ( if enough people will >contribute >on it ). Combining mod_jk and mod_webapp is likely to result >in something >better than both, so the vote to replace mod_jk and mod_webapp >will be a >formality :-) I strongly think we must have the connectors in a separate project so I'll follow your proposal and start a revolution. >( making it a top level project now is not a good idea right >now, neither >to do the development in the main tree - there are just few >big bugs to be >fixed before a 3.3 beta. ) Yep, I'll keep maintain the code in 3.3 tree and in parallel start the proposed revolution : * native code extracted => connector * java code moved from tomcat core/utils => org.apache.connector >P.S. It's fun beeing a "revolutionar" ! Let's go, there were not much revolution from France since 1789
RE: [PATCH] */build.sh
What about checking also the build.sh for Tomcat 3.3 :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] >Sent: Thursday, April 19, 2001 6:36 PM >To: [EMAIL PROTECTED] >Subject: [PATCH] */build.sh > > > >Hi, > >I found that adding the following lines to the different >build.sh files contained in the jakarta-tomcat-4.0 CVS module >makes the build.sh files cygwin friendly. > ># Here to show context >if [ "$CLASSPATH" != "" ] ; then > CP=$CLASSPATH:$CP >fi > ># To be added: >if [ "$OSTYPE" = "cygwin32" ] || [ "$OSTYPE" = "cygwin" ] ; then > CP=`cygpath --path --windows "$CP"` >fi > >That's it. Ceki Gülcü >
fdatasync in mod_jk
I'm strongly to remove the fdatasync in mod_jk since : - it slow down too much Apache when running in DEBUG/TRACE mode - not very portable (not PORTABLE/FREEBSD/WIN32) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Arkadiusz Rychlinski [mailto:[EMAIL PROTECTED]] >Sent: Friday, April 20, 2001 8:53 AM >To: [EMAIL PROTECTED] >Subject: I made some changes in Tomcat's sources > > >I made some changes in (maybe not exacly) Tomcat's sources. >How can I make >it public? > >I've added support for encoding different than ISO-8859-1 in >form data from >GET/POST request and processing multipart forms and file upload. > >What should I do to present these changes to tomcat team? > > > >Arek > > > >
RE: fdatasync in mod_jk
If nobody object during the week-end, I'll remove the fdatasync On monday :) Yes fflush will be suffisant - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: jean-frederic clere [mailto:[EMAIL PROTECTED]] >Sent: Friday, April 20, 2001 4:47 PM >To: [EMAIL PROTECTED] >Subject: Re: fdatasync in mod_jk > > >GOMEZ Henri wrote: >> >> I'm strongly to remove the fdatasync in mod_jk since : >> >> - it slow down too much Apache when running in DEBUG/TRACE mode >> - not very portable (not PORTABLE/FREEBSD/WIN32) > >And probably others platforms because it needs _POSIX_SYNCHRONIZED_IO > >I do not think that mod_jk may crash a box... fflush() is >enough to write a >logfile! > >Cheers > >Jean-frederic >> >> - >> Henri Gomez ___[_] >> EMAIL : [EMAIL PROTECTED](. .) >> PGP KEY : 697ECEDD...oOOo..(_)..oOOo... >> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >> >> >-Original Message- >> >From: Arkadiusz Rychlinski [mailto:[EMAIL PROTECTED]] >> >Sent: Friday, April 20, 2001 8:53 AM >> >To: [EMAIL PROTECTED] >> >Subject: I made some changes in Tomcat's sources >> > >> > >> >I made some changes in (maybe not exacly) Tomcat's sources. >> >How can I make >> >it public? >> > >> >I've added support for encoding different than ISO-8859-1 in >> >form data from >> >GET/POST request and processing multipart forms and file upload. >> > >> >What should I do to present these changes to tomcat team? >> > >> > >> > >> >Arek >> > >> > >> > >> > >
RE: [VOTE] New Committer: Bip Thelin
+1 - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Kief Morris [mailto:[EMAIL PROTECTED]] >Sent: Sunday, April 22, 2001 11:22 AM >To: [EMAIL PROTECTED] >Subject: [VOTE] New Committer: Bip Thelin > > >I would like to propose Bip Thelin as a new committer. He has >made a number >of contributions of patches over the past several months, >including SSI and >JDBCRealm, and most recently, is doing solid work on session >persistence. > >Kief >
RE: [PATCH] mod_jk timestamp and process id logging
Timestamp is already present in CVS. Did others modules add the pid ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Pogo Com [mailto:[EMAIL PROTECTED]] >Sent: Sunday, April 22, 2001 7:10 PM >To: [EMAIL PROTECTED] >Subject: [PATCH] mod_jk timestamp and process id logging > > >>2) I suggest adding a timestamp to mod_jk-logging in >jk_util.c. Logging >>without a timestamp is not very useful. (change 1 line, add 2 lines) > >Yes, this is a must-have... the other thing that is really >useful is the >Apache child process id. That way if one process gets stuck, >you can get the >id from the Apache mod_status, and grep the mod_jk.log for >that pid to see >where it is. Attached is another version of the patch that adds both, >relative to 3.3-m2. > >This was the only way that I could figure out that Tomcat >didn't have enough >threads in its thread pool for my Apache config! > >Bill > > >__ >Do You Yahoo!? >Yahoo! Auctions - buy the things you want at great prices >http://auctions.yahoo.com/ >
RE: [3.3] Release request
As a RPM packager I'd like ALSO having .tar.gz archive URL access like : http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3-m2/src/jakarta- tomcat-version-src.tar.gz It's the case for 3.2.x but not each time in 4.0/3.3. It allow RPM/DEBIAN? packagers all the version archives under the same sub-dirs (ie /usr/src/redhat/SOURCES. Having the untarred datas under jakarta-tomcat-version-src (Jon), but I'll be for using jakarta-tomcat-version (ant, oro, regexp, Apache HTTPD server, ) >Minor request: > >When you guys make releases of 3.3, could you please tar them >up so that the >untared directory name is "jakarta-tomcat-3.3-VERSION" instead >of just plain >old "tomcat"? :-) > >For example, if the .tar.gz is called: >"jakarta-tomcat-3.3-m2.tar.gz" the >directory that would end up creating should be called >"jakarta-tomcat-3.3-m2", not "tomcat". > >Thanks! > >-jon >
RE: Patch suggestions mod_jk/ajp13
Hi Rainer, Thanks for the patches : >I participated in the mod_jk fdatasync discussion on Friday. I >have 4 more >mod_jk/ajp13 patches on my personal wishlist. Since nobody object, I removed the fdatasync from log :) >The first three >(these are >mod_jk patches) apply to 3.2.2 as well as to 3.3-milestone2. >The fourth >(which is the tomcat ajp13 patch) is already fixed in 3.3, >but not in 3.2.2. Could you use next time, diff -Nru, since it's much more easy to see the differences... >I describe the four and add some diff-output for 3.2.2-beta2. >I'm not an >experienced Java/C-developper, so do not blindly use the code, >although all >patches are very small. > >1) In jk_ajp12_worker.c the HTTP return reason phrase (the text that >belongs to the numeric status, like "OK" for "200") is not >handled correct. >If the phrase consists of more than one token, like "Not >Found", only the >first token is read from tomcat and returned to the client. >(change two >lines, add 5 lines) Seems good to me >2) I suggest adding a timestamp to mod_jk-logging in >jk_util.c. Logging >without a timestamp is not very useful. (change 1 line, add 2 lines) Allready present in tomcat 3.3 CVS >3) I think in jk_uri_worker_map.c is a little bug. For me it >loggs (very >rarely) "NULL parameters" and looking at the code I can see, >that the two >places are exactly those, where the code does not return >before the log >statement, even if it succesfully completes the call. All other places >where "NULL parameters" could be logged first try to do something >successful, if yes return, if no do logging. So I think one gets the >logging although it should not have happened. (delete 4 lines, >change 3 >lines, add 1 line) Never saw these NULL that but I cleanup a little jk_uri_worker_map >4) In Ajp13ConnectorResponse.java the http reason phrase is >missing in the >returned status line. The change that has been done to tomcat >3.3 milestone >2, and maybe could be added to 3.2.2 also. (change 1 line) > >Maybe some of these could go into 3.2.2 or 3.3? 3.2.x tree is closed and only bug fixes will be included. All majors updates to mod_jk must be in 3.3 tree !!!
RE: Access log files in the style of Apache
+1 for 3.3. Since it's not a bug fixes, we may never see that in 3.2.2 or 3.2.3... - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] >Sent: Monday, April 23, 2001 12:44 PM >To: '[EMAIL PROTECTED]' >Subject: RE: Access log files in the style of Apache > > >Hola a Todos, Costin, Jochen: > >> >> +1 for 3.3, >> +1 for checking the code in for 3.2 ( but not enable it be >> default ) - it >> can't hurt in any way code stability. ( but it's Marc's call ) >> > >+1 to add it to 3.3 release >+1 and to provide it disabled for upcoming 3.2.3, if MArc agrees.. > >Saludos , >Ignacio J. Ortega >
RE: [PATCH] mod_jk timestamp and process id logging
Let me clarify. Did other apache modules add the pid() in their logs ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] >Sent: Monday, April 23, 2001 12:34 PM >To: [EMAIL PROTECTED] >Subject: RE: [PATCH] mod_jk timestamp and process id logging > > >Timestamp is already present in CVS. > >Did others modules add the pid ? > > >- >Henri Gomez ___[_] >EMAIL : [EMAIL PROTECTED](. .) >PGP KEY : 697ECEDD...oOOo..(_)..oOOo... >PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 > > > >>-Original Message- >>From: Pogo Com [mailto:[EMAIL PROTECTED]] >>Sent: Sunday, April 22, 2001 7:10 PM >>To: [EMAIL PROTECTED] >>Subject: [PATCH] mod_jk timestamp and process id logging >> >> >>>2) I suggest adding a timestamp to mod_jk-logging in >>jk_util.c. Logging >>>without a timestamp is not very useful. (change 1 line, add 2 lines) >> >>Yes, this is a must-have... the other thing that is really >>useful is the >>Apache child process id. That way if one process gets stuck, >>you can get the >>id from the Apache mod_status, and grep the mod_jk.log for >>that pid to see >>where it is. Attached is another version of the patch that adds both, >>relative to 3.3-m2. >> >>This was the only way that I could figure out that Tomcat >>didn't have enough >>threads in its thread pool for my Apache config! >> >>Bill >> >> >>__ >>Do You Yahoo!? >>Yahoo! Auctions - buy the things you want at great prices >>http://auctions.yahoo.com/ >> >
RE: Store Proposal
What about having the session store stuff used also in Tomcat 3.2 / 3.3 . It seems to be a fine candidate to jakarta-commons ... - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Bip Thelin [mailto:[EMAIL PROTECTED]] >Sent: Friday, April 20, 2001 9:02 PM >To: [EMAIL PROTECTED] >Subject: Store Proposal > > >We've had some issues with the background threads, expiration >and stuff so I >migrated some of the common stuff into a StoreBase and had >JDBCStore and FileStore >extend it and have the opportunity to implement it's own >processexpires and some >other methods. The code is attatched. I've also implemented an >extended table for >JDBCStore, there still remains some work on using the extended >fields when checking >expiration and loading I'll have that done soon. This is what >a table for JDBCStore >now should look like: >TABLE [tomcat$sessions] ( > [id] [varchar] (100) NOT NULL , > [data] [varbinary] (1000) NULL , > [valid] [char] (1) NOT NULL , > [maxinactive] [int] NOT NULL , > [lastaccess] [numeric](18, 0) NULL >) > >Here's how you can configure the table and column names: > > > > > ..bip >
RE: Bugs <500
>345 - Date header >348 - Security roles >375 - // security checking - revert to paranoid path checks >454 - mod_jk spawning (hunged ) apache processes when tomcat is down > ( maybe later - tomcat should be running or be restart ) #454 (mod_jk bug spawns unlimited rogue Apache processes BugRat Report#776) If #454 is related to apache behaviour when tomcat was restarted, this one is allready fixed (but I couldn't locate the bug id in nagoya). It was my fixe in two time (one for get, then for post in jk13_worker) => When a JSP Page that has an error is refreshed, and the Tomcat engine has been shutdown, an Internal Server error is produced and a seperate Apache processes is spawned, irregardless of the limit of Apache servers. We had set the limit of 10 servers for Apache to be initialized, and were able to open 80 additional instances of Apache by hitting refresh. This consumed nearly all system resources and made the entire system practically unusable. <= If someone could send an example, I'll check that on my TC 3.3 with latest mod_jk >486 - rusian in jsp @include > >There are 8 jasper bugs I think we should leave open, I wouldn't change >jasper before refactoring: > >75 - translation time attrs >105 - custom tag attrs >143 - tag handlers >360 - jsp:include expressions >366 - doAfterBody if no body >376 - Jsp error messages in some cases ( no setter ) >387 - special tokens in tag name ( extend to jsp files ) >412 - JSPC and \ paths ( it may be easy to fix ) > >4 bugs are fixed in 3.3, we should close them: > >149 - log, fixed >295 - config generation, fixed >296 - "can't happen", fixed >485 - cookies, fixed > >Also, 4 bugs I don't think we'll cover in 3.3: >166 - spaces on nt ( has workarounds ) >962 - redirect sys out, err; config in server.xml, rotate ( RFE ) >471 - mod_jk and spaces in dir name on windows ( has workarounds ) #471 (blank space in tomcat_home directory path) BugRat Report#797) => Hi, I am trying to make Tomcat as NT service. It works fine when tomcat_home directory(in wrapper.properties file) is a continuous string. But, it does not work when I use the directory name with a blank space in between. For example, it works if the tomcat_home directory path is c: \jakartatomcathome\ but causes problem if it is c: \jakarta tomcat home\ <= I'm not using Tomcat under Windows but having tomcat under c:\tomcat\ and having mentioned in doc will fixes the problem. Are you sure it's related to mod_jk ? >112 - BAT script on windows - bin/ as default > >Costin >
RE: [PATCH] mod_jk timestamp and process id logging
We could add the getpid() but what about Apache 2.0 in MPM mode (threaded) ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Pogo Com [mailto:[EMAIL PROTECTED]] >Sent: Monday, April 23, 2001 7:36 PM >To: [EMAIL PROTECTED] >Cc: GOMEZ Henri >Subject: RE: [PATCH] mod_jk timestamp and process id logging > > >Regarding logging the Apache child process id in mod_jk.log: > >>Timestamp is already present in CVS. >>Did others modules add the pid ? > >I am not sure, but the process id makes debugging a problem >with an individual >Apache child much simpler, because it directs you to the >events of interest. >Without the process id, you have to use timestamps, which are >significantly >less accurate. > >Bill > > >__ >Do You Yahoo!? >Yahoo! Auctions - buy the things you want at great prices >http://auctions.yahoo.com/ >
RE: [PATCH] mod_jk timestamp and process id logging
Depend the OS:
AS/400 =>
int GetThreadId()
{
pthread_t lSelf = pthread_self();
pthread_id_np_t lTid;
pthread_getunique_np(&lSelf, &lTid);
return (lTid.intId.lo);
}
Linux =>
int GetThreadId()
{
return (pthread_self());
}
What about others platforms like AIX/HPUX/Windows
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-Original Message-
>From: Pogo Com [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, April 24, 2001 2:36 AM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: RE: [PATCH] mod_jk timestamp and process id logging
>
>
>>We could add the getpid() but what about Apache 2.0
>>in MPM mode (threaded) ?
>
>The getpid() isn't going to be very helpful in that case, but
>at least it
>doesn't hurt.
>
>Is there some other notion like a thread id that would be
>applicable to the
>multithreaded Apache case?
>
>Bill
>
>
>__
>Do You Yahoo!?
>Yahoo! Auctions - buy the things you want at great prices
>http://auctions.yahoo.com/
>
RE: ServerSocket not being closed properly.
>I think you have a lucky VM/OS - close() on the accepting >socket doesn't >stop the accept() thread ( at least not on Linux/JDK1.3 ). That's right on Linux Redhat 6.2 and glibc 2.1.x and IBM JDK 1.3. But it seems to work fine on Redhat 7.0 which use a glibc 2.2. But the fundamental step for the Linux community is kernel 2.4 found for example in Redhat 7.1, and I consider that Redhat 7.0 is just an interim release.
RE: [Patch] Tomcat 3.2.2
Commited to 3.3 branch.
What about 3.2 branch Marc ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-Original Message-
>From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, April 24, 2001 6:47 AM
>To: [EMAIL PROTECTED]
>Subject: [Patch] Tomcat 3.2.2
>
>
>Gentlefolk,
>
> on the Apache side we ran into a headache on Win2K. Windows
>services introduced
>a SHUTDOWN event with a new signal. Unfortuantely, they did
>_not_ continue to
>support the STOP event from NT. This patch teaches the
>jk_nt_service to solicit
>and respect the SHUTDOWN event as well as the old STOP event.
>
>Your,
>
>Bill
>
>Index: src/native/mod_jk/nt_service/jk_nt_service.c
>===
>RCS file:
>/home/cvspublic/jakarta-tomcat/src/native/mod_jk/nt_service/jk_
>nt_service.c,v
>retrieving revision 1.2
>diff -u -r1.2 jk_nt_service.c
>--- src/native/mod_jk/nt_service/jk_nt_service.c 2000/11/19
>04:15:13 1.2
>+++ src/native/mod_jk/nt_service/jk_nt_service.c 2001/04/24 04:33:25
>@@ -248,6 +248,7 @@
> /*
> * Stop the service.
> */
>+case SERVICE_CONTROL_SHUTDOWN:
> case SERVICE_CONTROL_STOP:
> ssStatus.dwCurrentState = SERVICE_STOP_PENDING;
> stop_jk_service();
>@@ -281,7 +282,8 @@
> if(dwCurrentState == SERVICE_START_PENDING) {
> ssStatus.dwControlsAccepted = 0;
> } else {
>-ssStatus.dwControlsAccepted = SERVICE_ACCEPT_STOP;
>+ssStatus.dwControlsAccepted = SERVICE_ACCEPT_STOP
>+| SERVICE_ACCEPT_SHUTDOWN;
> }
>
> ssStatus.dwCurrentState = dwCurrentState;
>
>
RE: Tomcat 3.2.2 patches
I'll commit later the latest mod_jk patches but only those which could be under the 3.2.2 mod_jk. (I couldn't add the fix for tomcat restart case for example) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Marc Saegesser [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, April 24, 2001 11:40 PM >To: [EMAIL PROTECTED] >Subject: Tomcat 3.2.2 patches > > >Costin, Henri, > >You both asked about some simple patches for Tomcat 3.2.2. >There will be >another (hopefully the last) beta release for 3.2.2, so go >ahead and commit >those changes. > >I'm working a bug in Jasper that will certainly require some >soak time to >make sure nothing else gets broken. JspServlet.java is an >excellent example >of how *NOT* to write multithreaded Java code. In fact I'm >tempted to start >using it as an interview pre-test. Anyone who can't find at least 3 (I >think there are at least 5) synchronization problems doesn't even get >brought in for an interview. >
RE: [PATCH] mod_jk timestamp and process id logging
Nothing is simple when you want to have
C code for multiples OS :)
That's why APR was developped ...
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-Original Message-
>From: Pogo Com [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, April 24, 2001 7:13 PM
>To: GOMEZ Henri; [EMAIL PROTECTED]
>Subject: RE: [PATCH] mod_jk timestamp and process id logging
>
>
>This is starting to sound complicated. I'd say go with the
>getpid(), since it
>covers a major case and is pretty portable and simple.
>
>Bill
>
>
>--- GOMEZ Henri <[EMAIL PROTECTED]> wrote:
>> Depend the OS:
>>
>> AS/400 =>
>>
>> int GetThreadId()
>> {
>> pthread_t lSelf = pthread_self();
>> pthread_id_np_t lTid;
>>
>> pthread_getunique_np(&lSelf, &lTid);
>> return (lTid.intId.lo);
>> }
>>
>> Linux =>
>>
>> int GetThreadId()
>> {
>> return (pthread_self());
>> }
>>
>> What about others platforms like AIX/HPUX/Windows
>
>
>__
>Do You Yahoo!?
>Yahoo! Auctions - buy the things you want at great prices
>http://auctions.yahoo.com/
>
RE: what is the deal with tomcat 4 and web server connectors??
>I think those pieces are very valuable - and instead of >implementing the >AJP13 ( and future 14 ) it would be much better to extract the full >implementation and make it independent of tomcat3.3 +1 >That would allow to also build a tomcat3.2 adapter ( since >most people are >using 3.2 right now - and changing a production site is a slow process >). It will give also to TC 3.2 users a more stable mod_jk and ajp12/ajp13. Some fixes couldn't be include in mod_jk code for TC 3.2 and would be here since 3.2.x serie will be updated only for easy bugs fixes, those without any refactor. For example, mod_jk in 3.3 fixe the problem when you restart Tomcat and use ajp13. In mod_jk for 3.2, you'll need to restart Apache, no more needed in 3.3. And that's a mad situation since connectors code which is mainly native code, could be common to Tomcat Servlet Engines (3.2/3.3). > Tomcat4 is supposed to be more flexible than 3.x :-) - so >creating an >adapter should be easy ( well, I don't understand most of the >4.0 design, >but I was able to build a prototype adapter - and get ajp13 >support into >4.0. Unfortunately my head exploded due to class loading >problems - but it >can be done ). > >So what I would do ( or I'll do :-) is start with a new package, taking > MessageBytes, MimeHeaders, subset of Request/Response, add an adapter >interface ( tc3.1 used to have one - but it had a bad design - >I can say >that since I did it ) using a notification model ( for example a >AdapterListener that will allow the adapter to plug to upper layers ) +1 >Then create interceptors/valves for 3.2, 3.3, 4.0 ( maybe:-) >and plug it in. Yep, get the merge the great ideas of all Tomcat projects 3.2/3.3/4.0 >Of course, this is just an idea - there are many details to >discuss ( and other, better ideas - I'm sure of that :-). Discussion is open, and it's a good point >On Tue, 24 Apr 2001, Dan Milstein wrote: > >> One thing which I think would be useful (which I wanted to >do myself, but >> don't think I'll have time to do), would be to write an >ajp13 connector for >> TC 4. This would allow TC 4 users to use mod_jk as their >plugin (which >> supports iPlanet and IIS). If you are interested in doing >some development, >> I think that would be an excellent contribution. >> >> Steps: >> >> - Take a look through the Ajp13 doc in the 3.3 branch >(src/doc/AJPv13.html) >> -- this explains how the protocol works. >> >> - Review the ajp13 connector code in 3.3 >> (share/org/apache/tomcat/modules/server/Ajp13.java and >> Ajp13Interceptor.java). >> >> - Adapt that code to the TC 4 codebase (basing on HttpConnector, or >> WarpConnector, possibly). >> >> Wins: connect to multiple servers (including netscape and iis), load >> balancing, debugged C code. >> >> Losses: painful to configure >> >> Although I don't have time to write this code myself, I can >contribute some >> help (I understand the 3.3 ajp13 code pretty thoroughly). >> >> -Dan >> >> > Kevin Seguin wrote: >> > >> > i want to move from tomcat 3.x to tomcat 4. i absolutely >must be able to >> > use tomcat 4 with netscape/iplanet and microsoft (iis) web >servers. as >> > near as i can tell, the only connector that will be >available in the >> > foreseeable future is for apache 1.3. is this true? >> > >> > i have come across very little (almost no) information >regarding this new >> > webapp lib (which appears to be undergoing some significant change >> > recently) and the warp thing... does *anybody* have >anything to share?? >> > i'm willing to help out with connector development, or >even write my own >> > connectors... if i could only figure out where to start... >> >> >
RE: Tomcat 3.2.2 and Thread synchronization
I'll have also some patches to port back in TC 3.2 mod_jk/ajp13
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-Original Message-
>From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, April 26, 2001 1:40 AM
>To: [EMAIL PROTECTED]
>Subject: Tomcat 3.2.2 and Thread synchronization
>
>
>I've made some pretty major changes to JspServlet.java to
>clean up lots of
>thread synchroniztion problems. The commit message summarizes
>most of the
>changes. Because this is a major change very late in the beta
>cycle I would
>appreciate it if other developers would give this a through review. Be
>kind, my head is still spinning from all this synchronization stuff.
>
>If no one has any complaints I'll cut a new (and hopfully final) beta
>release for Tomcat 3.2.2 in a couple days.
>
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>> Sent: Wednesday, April 25, 2001 6:30 PM
>> To: [EMAIL PROTECTED]
>> Subject: cvs commit:
>jakarta-tomcat/src/share/org/apache/jasper/servlet
>> JspServlet.java
>>
>>
>> marcsaeg01/04/25 16:29:30
>>
>> Modified:src/share/org/apache/jasper/resources Tag: tomcat_32
>> messages.properties messages_es.properties
>> messages_fr.properties
>>src/share/org/apache/jasper/servlet Tag: tomcat_32
>> JspServlet.java
>> Log:
>> This is a fairly major update. There were numerous thread
>> synchronization
>> problems involving compiling JSP files. These problems were
>> most apparent
>> on systems running under load in which page re-compilations might
>> happen while pages are being executed and where new requests
>> arrive while
>> a page compilation is underway.
>>
>> I've made lots of changes so I'll just summarize the major
>differences
>> here.
>>
>> 1) The thread synchronization in doLoadJSP() is quite
>different. The
>> comments before that method describe the synchronization model
>> in detail.
>>
>> 2) The synchronization in doLoadJSP() is now based on the
>> JspServletWrapper object instead of the JspServlet object.
>>
>> 3) The class loading and the object instantiation used to be
>> split between
>> doLoadJSP() and the JspServletWrapper. They are now
>combined into a
>> single synchronization block inside doLoadJSP().
>>
>> 4) In JspServletWrapper, the data member theServlet was
>used directly by
>> several methods. Access to this is now provided only through a
>> synchronized accessor method(). Any method that needs to
>obtain the
>> servlet must call getServlet() and store the result in a
>stack variable
>> (or other per-thread storage). Multiple threads of
>execution through
>> JspServletWrapper may be executing different servlet
>classes if a page
>> compilation happened while other requests were being processed.
>>
>> 5) When a new JSP implementation class replaces an
>existing class, the
>> original classes destroy() method should be called so that any
>> jspDestroy() method on the page will be executed. However, the
>> destroy()
>> method can't be invoked until we know that there are no
>more requests
>> being processed on that instance. To support this, the JSP
>> implementation
>> class is wrapped inside a new class called JspCountedServlet.
>> This class
>> provides simple reference counting in the service() method. If the
>> classes destroy method is called it flags the class for
>destruction but
>> does not call the servlet's destroy() method until it
>> determines that the
>> service method has completed on all threads running in the class.
>>
>> PR: 1280
>>
>> Revision ChangesPath
>> No revision
>>
>>
>> No revision
>>
>>
>> 1.17.2.9 +3 -1
>>
>jakarta-tomcat/src/share/org/apache/jasper/resources/messages.p
>roperties
>>
>> Index: messages.properties
>> ===
>> RCS file:
>> /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/resources/mes
>> sages.properties,v
>> retrieving revision 1.17.2.8
>> retrieving revision 1.17.2.9
>> diff -u -r1.17.2.8 -r1.17.2.9
>> --- messages.properties2001/01/12 04:47:00 1.17.2.8
>> +++ messages.properties2001/04/25 23:29:28 1.17.2.9
>> @@ -1,4 +1,4 @@
>> -# $Id: messages.properties,v 1.17.2.8 2001/01/12 04:47:00
>larryi Exp $
>> +# $Id: messages.properties,v 1.17.2.9 2001/04/25 23:29:28
>> marcsaeg Exp $
>>#
>># Default localized string information
>># Localized this the Default Locale as is en_US
>> @@ -214,3 +214,5 @@
>>jsp.error.unterminated.user.tag=Unterminated user-defined tag:
>> ending tag {0} not found or incorrectly nested
>>jsp.error.invalid.javaEncoding=Invalid
RE: [PATCH] mod_jk apache20 shells
>I have tried mod_jk with apache20 and I have noted the shells >scripts to build >and install it need improvements. >Find enclosed the patch I have used. >apxs looks buggy... apxs -c -o mod_jk.so *.c does not work, >but it should ;=) I've built a RPM for Apache 2.0 and have provided some time ago a patch for apxs (attached). Allready sent to Ryan Bloom but he was very busy at this time... >Cheers > >Jean-frederic > apxs.patch
RE: [PATCH] mod_jk apache20 shells
I'll commit ASAP. Thanks - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: jean-frederic clere [mailto:[EMAIL PROTECTED]] >Sent: Friday, April 27, 2001 4:42 PM >To: [EMAIL PROTECTED] >Cc: Martin Kraemer >Subject: [PATCH] mod_jk apache20 shells > > >Hi all, > >I have tried mod_jk with apache20 and I have noted the shells >scripts to build >and install it need improvements. >Find enclosed the patch I have used. >apxs looks buggy... apxs -c -o mod_jk.so *.c does not work, >but it should ;=) > >Cheers > >Jean-frederic >
RE: Why Tomcat brakes connection?
Tomcat 3.2 only support HTTP 1.0 So no keep-alive here (HTTP 1.1) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Aleksey Studnev [mailto:[EMAIL PROTECTED]] >Sent: Thursday, April 26, 2001 8:07 AM >To: [EMAIL PROTECTED] >Subject: FW: Why Tomcat brakes connection? > > > > >-Original Message- >From: Aleksey Studnev [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, April 25, 2001 2:03 PM >To: [EMAIL PROTECTED] >Subject: Why Tomcat brakes connection? > > > > Tomcat 3.2 under Win Nt 4. > Client wants to re-use socket connection > for multiple requests from server - it is > actually a feature of HTTP 1.1. This saves > time on creating socket object, making > TCP connection. > What Tomcat is doing unlike other web servers > we have ( Apache, Weblogic) is resetting connection > after every request. The sequense which is seen in > the network is the following: > > Client -> Connect > Client -> GET(socket NNN) > Tomcat -> Response > Client -> GET(socket NNN) > Tomcat -> Reset connection <- Whats the hell? > Client -> Connect > Tomcat -> Bind > Client -> GET(socket MMM) > Tomcat -> Response > > Who knows why it happens? > > Aleksey >
RE: porting ajp13 to tomcat 4 (was Re: ajp13 question)
>damn! i wasn't expecting that complex of an answer ;) The difficulty is in the difference between TC 3.2/3.3 and 4.0 and the how the connector are written. They're just to highly linked in the tomcat core ! >> If you wanted to cheat (fine with me!), you could cut this >feature out for >> now, and get ajp13 working *without* load-balancing (still >useful), document >> that fact, and return to it later (or beg for help to fix it >once you get >> everything else working). To do that, just have TC ignore >whatever jvmroute >> is sent over. Everything but load-balancing should still >work just fine. If you have java ajp13 works in non-balancing mode, you've done the hardest part ! >that's what i've decided to do. my goal is to first get >things working, >at least minimally, then i (or someone else) can address load-balancing >later. my gut feeling, though, after spending some time on ajp13 and >tomcat 4 is it's certainly possible. of course, i'm pretty new to the >whole tomcat 4 architecture, so i could be way off :) > >thanks for the info. > >btw, i've got ajp13/tomcat 4 about half working (probably the easy >half...). Could you send the code, we're interest (at least I) ;)
RE: ajp13 question
>What about creating a directory jakarta-tomcat/src/doc/notes and >checking in all the "relevant" mail - like this one ? I'm talking about >proposals, technical notes, etc. +1 for notes on lb works. >Searching the mail archive to find "good stuff" is hard ( given the >noise), and maybe someone could turn various mails into documentation >( but even if not - we can save the info: if it's hard to find it >almost doesn't exist ) And when you write long from Internet it's almost impossible, which raise another question, could we have a FAQ for Tomcat projects include in CVS ?
RE: porting ajp13 to tomcat 4 (was Re: ajp13 question)
Fine, I'll study it - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: kevin seguin [mailto:[EMAIL PROTECTED]] >Sent: Monday, April 30, 2001 5:53 PM >To: [EMAIL PROTECTED] >Subject: Re: porting ajp13 to tomcat 4 (was Re: ajp13 question) > > >> >> If you have java ajp13 works in non-balancing mode, you've done >> the hardest part ! >> > >that's encouraging :) > >> >that's what i've decided to do. my goal is to first get >> >things working, >> >at least minimally, then i (or someone else) can address >load-balancing >> >later. my gut feeling, though, after spending some time on >ajp13 and >> >tomcat 4 is it's certainly possible. of course, i'm pretty >new to the >> >whole tomcat 4 architecture, so i could be way off :) >> > >> >thanks for the info. >> > >> >btw, i've got ajp13/tomcat 4 about half working (probably the easy >> >half...). >> >> Could you send the code, we're interest (at least I) ;) > >the code isn't real pretty right now. in fact, it's downright ugly! >but that's ok, that's what refactoring is for ;) and hopefully, >somebody who knows more can help! > >it's basically based on parts of the http connector, and >Ajp13.java/Ajp13Interceptor.java from the 04.27 build of tomcat 3.3. > >i'm attaching a zip file containing my code. i've make it an ajp >subpackage of org.apache.catalina.connector. > >advice/help is welcome/wanted :) > >-kevin. >
RE: porting ajp13 to tomcat 4 (was Re: ajp13 question)
You make a great job here and the ajp13 port to Tomcat 4.0 will be strategic for many sites. >the code isn't real pretty right now. in fact, it's downright ugly! >but that's ok, that's what refactoring is for ;) and hopefully, >somebody who knows more can help! Refactoring could still be done later, but you show we could hope to see ajp13 in TC 4.0 and that's the important point. >it's basically based on parts of the http connector, and >Ajp13.java/Ajp13Interceptor.java from the 04.27 build of tomcat 3.3. > >i'm attaching a zip file containing my code. i've make it an ajp >subpackage of org.apache.catalina.connector. I've started look at it. >advice/help is welcome/wanted :) Keep up the good works. I'll test it against my mod_jk. Which version of Tomcat 4.0 must I use, TC 4.0B3 ? Regards
RE: porting ajp13 to tomcat 4 (was Re: ajp13 question)
>for those who are interested... > >updated code for ajp13 connector for tomcat 4. this version more or >less works, but needs some major cleanup/refactoring. > >i ended up copying a bunch of code out of some files in the http >connector package, and the Http*Base classes out of the connector >package. perhaps some of this code could someday be put into >utility/common classes... may be something that could go to jakarta-commons ?
RE: porting ajp13 to tomcat 4 (was Re: ajp13 question)
>> unfortunately, i have an immediate need for ajp13 in tomcat >4. i want >> to move to tomcat 4, but can't without connectivity between >> iis/netscape >> web servers and tomcat. porting ajp13 from tomcat 3.x to tomcat 4 >> seemed like it would be easier than writing iis/netscape >> connectors for >> the new webapp/warp stuff. especially since webapp seems to >> be a moving >> target >> > >AFAIK, IIS/Netscape connector only works with ajp12 not ajp13..at least >this is the documented behavior and i have been unable to put it work >with ajp13 ( i've tested on the last minutes ).. What's the problem with ajp13 under IIS/NES ? I didn't have access to them but we may find help around...
RE: porting ajp13 to tomcat 4 (was Re: ajp13 question)
>-Original Message- >From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, May 01, 2001 12:10 AM >To: '[EMAIL PROTECTED]' >Subject: RE: porting ajp13 to tomcat 4 (was Re: ajp13 question) > > >The documentation is wrong...IIS works with ajp13...i'll change docs >accordingly.. > >Saludos , >Ignacio J. Ortega > Good. Did there is people around using NES/IPLANET which could confirm the status of ajp13 and NES ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >> >> unfortunately, i have an immediate need for ajp13 in tomcat >> >4. i want >> >> to move to tomcat 4, but can't without connectivity between >> >> iis/netscape >> >> web servers and tomcat. porting ajp13 from tomcat 3.x to tomcat 4 >> >> seemed like it would be easier than writing iis/netscape >> >> connectors for >> >> the new webapp/warp stuff. especially since webapp seems to >> >> be a moving >> >> target >> >> >> > >> >AFAIK, IIS/Netscape connector only works with ajp12 not >> ajp13..at least >> >this is the documented behavior and i have been unable to >put it work >> >with ajp13 ( i've tested on the last minutes ).. >> >> What's the problem with ajp13 under IIS/NES ? >> I didn't have access to them but we may find help around... >> >
RE: porting ajp13 to tomcat 4 (was Re: ajp13 question)
- >HAve sense to continue naming ajp12 on IIS howto doc? i think not as >there isnt a substitute for isape_redirect.dll as mod_jserver vs. >mod_jk..so use ( or recommend ) a deprecated protocol has no sense for >me .. ajp12 and ajp13 are both protocols used to link web-server to tomcat. when mod_jserv was designed only ajp12 exist. Later mod_jk added ajp13 and maintain ajp12 even it's clear that ajp13 is much more faster. >If nobody complaints i will change *all* ajp12 references to >ajp13..getting rid of every ajp12 reference ... +0
RE: porting ajp13 to tomcat 4 (was Re: ajp13 question)
Good and Apache 2.0 with mod_jk is also very fast. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, May 01, 2001 12:33 AM >To: [EMAIL PROTECTED] >Subject: RE: porting ajp13 to tomcat 4 (was Re: ajp13 question) > > >> Good. >> >> Did there is people around using NES/IPLANET which could >> confirm the status of ajp13 and NES ? >> > >I tested it ( long ago ), both NES and IIS ( yes, I did >installed windows >for that !). Ajp13 and JNI used to work fine ( JNI doesn't >work very well >with Apache1.3.x, as it's not multithreaded - but works just >great on NES, >IIS or Apache2.0 ). In fact, JNI is the tricky part, not ajp13. > >Costin > > >
ANNOUNCE - web-connector
A quick note to announce I'll start Thursday a mini-revolution in proposals/web-connector/ The goals of the revolution are: - improved ajp13: better configuration,etc - build improvements - support all tomcat versions - single codebase that will be used for all versions ( reduce maintainance overhead ) - add apr support - libtool and autoconf support - improved security and protocol negociation Regards - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
[ANNOUNCEMENT] Tomcat 3.2.2 beta 4 RPMS released
RPM available at : http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.2-beta-4/rpms/ Linux i386 mod_jk.so (EAPI and STDAPI) at : http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.2-beta-4/bin/li nux/i386/ - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
[VOTE] New Committer: Kevin Seguin
I would like to propose Kevin Seguin as a new committer. He make a great job in developping the ajp13 protocol for Tomcat 4.0 and this code will be a great help for sites wanting to upgrade from 3.2.x to 4.0 while still using mod_jk Henri
RE: ANNOUNCE - web-connector
>> The goals of the revolution are: >> >> - improved ajp13: better configuration,etc >> - build improvements >> - support all tomcat versions >> - single codebase that will be used for all versions ( >reduce maintainance >> overhead ) >> - add apr support >> - libtool and autoconf support >> - improved security and protocol negociation > >Could you also please add full Servlet API 2.3 support? We don't need >another web connector that only half supports the latest servlet spec. Each trip start with an initial step, but yes we can add this one. The current protocol AJP13 couldn't statisfy API 2.3 but I'll send later today a proposal for AJP14 which may overcome the AJP13 limitations regarding API 2.3 And I hope to see Pier contribute also in that project >thanks, Il est normal d'être exigeant.
RE: ANNOUNCE - web-connector
>Hopefully we might even get back to one that worked as well as JServ's >connector. > >As a goal, could you add back the ability to restart the JVM >if necessary? What did you means by restart the JVM ? Did you think about having the web server launch the servlet engine JVM ? I could be done but don't forget that today site tend to use a single web server and farms ot tomcat behind on differents systems. >Scott Sanders > >GOMEZ Henri wrote: > >> A quick note to announce I'll start Thursday a mini-revolution >> in proposals/web-connector/ >> >> The goals of the revolution are: >> >> - improved ajp13: better configuration,etc >> - build improvements >> - support all tomcat versions >> - single codebase that will be used for all versions ( >reduce maintainance >> overhead ) >> - add apr support >> - libtool and autoconf support >> - improved security and protocol negociation >> >
RE: [TC3.3]Servlet-Engine Header in ajp13 and Http10 connectors
>On Tue, 1 May 2001, Ignacio J. Ortega wrote: > >> Hola a todos: >> >> I'm wondering if the lack of "Servlet-Engine:" header in ajp13 and >> http10 connectors is intentional or a missed feature ( for >>not call it a bug as for me it's not :) ?? mod_jk has code for Servlet-Engine support but ajp13 didn't send it now certainly for performance reasons. I take a look in Tomcat 4.0 and even in Resin but this Header is not present. If "Servlet-Engine:" is required by specs we may add it but which RFC require this header ? >> The same for the "Date" header in Http10 ?? >> >> "Date" header is mandatory , no? > >Yes, it's a bug for date, we must fix it. > >For ajp13, ajp12, jni - the server should generate the date header, >and I would sugest to also generate the ServletEngine header in mod_jk, >to avoid sending it over the wire on each request. mod_jk could set the ServletEngine but it must know before which worker run which servlet engine. In a farm of tomcat you could have at the same time TC 3.2/3.2.1/3.3/4.0 ajp14 will learn which version of servlet-engine is running at login time. >The code for sending "date" is commented out in the Http1.0 connector, >it was very inefficient - and the idea was to use the same optimization >that is used in Log ( FastDateFormat ) or copy the optimizations from 4.0 >( if any ). We could speed-up again a little FastDateFormat by also checking the full date since it may called by many threads in the same MS. I'll commit the patch later :) The Apache team grab this kind of optimization from SGI patches !!!
RE: Tomcat 3.2.2 beta 4
>Hi, all! >I've made a little modification in Tomcat 3.2.1 codebase that >I think would >be nice to include in TC 3.2.2. > >Problem: shutdown script always connects to "localhost" to >send shutdown command. >It is a problem on a "multihomed" machine running multiple >tomcats where >tomcats use same port numbers but bound to different IP >adresses using inet="" >configuration option in server.xml. Hey do you really want someone outside you machine send a shutdown command to your tomcats ? Warning, Warning here. The "localhost" is used here for security reasons. I didn't understand why your multihomed machine couldn't listen on localhost ? Thanks to give us more informations, for example did you use multiples JVMs ? >Fix: query PoolTcpConnector.INET attribute in shutdown code. > >Attached please find a little patch file. This is patch >against my repository >and TC 3.2.1 but I checked the very same file >(src/share/org/apache/tomcat/task/StopTomcat.java) in TC 3.2.2 >beta 4 and it >was identical to the old one, so I beleive the patch would be the same. > > >Thanks. > >-- >oo Andrey >oo >oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo >"All mail clients suck. This one just sucks less." > -- http://www.mutt.org/ Jeremy Blosser >oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo >
RE: [PROPOSAL/VOTE] New Repositories for Collaborative Development
>Over the last few weeks, there has been a lot of discussion on >collaborative development, across the various Tomcat branches, on two >major areas: +1 for the split. > >* Web connectors > >* A new Jasper (the "jasper34" proposal) > >and efforts have begun in the HEAD branch "proposals" directory of the >jakarta-tomcat repository. I'd like to propose a slightly different >approach -- create two new repositories (perhaps >"jakarta-tomcat-connectors" and "jakarta-tomcat-jasper") to be >the homes >of these development efforts, independent of any of the existing code >bases. The reasoning for this approach is as follows: Did these CVS will be like the jakarta-servletapi and jakarta-watchdog ? >* Avoid any appearance of politics or attachment based > on which repository the code is hosted in Yes, please. >* Make it easier to enforce the technical separation of > this code from any existing Tomcat base code (you have > to declare external dependencies pretty directly) +1 >* Avoid the need for everyone working on these shared > components to have *all* of the Tomcat code on all branches > checked out all the time -- you can focus on the repository > for your favorite Tomcat plus the common stuff you care about Thanks, porting mod_jk native patches in all TC branch is really time consuming and subject to problems. >* Smaller CVS repositories means faster CVS checkouts for everyone > on daedalus, on all projects It was slow today... >Because these repositories would both be part of the overall Tomcat >subproject, all existing and new Tomcat committers would have commit >access to both of them, just as we all have access to >"jakarta-tomcat" and >"jakarta-tomcat-4.0" today. > >Comments? Questions? Votes? Again +1
RE: Tomcat 3.2.2 beta 4 (problem with shutdown code)
>> >Problem: shutdown script always connects to "localhost" to >> >send shutdown command. >> >It is a problem on a "multihomed" machine running multiple >> >tomcats where >> >tomcats use same port numbers but bound to different IP >> >adresses using inet="" >> >configuration option in server.xml. >> >> Hey do you really want someone outside you machine send a shutdown >> command to your tomcats ? >I think it is very common configuration where Ajp connector is >bound to something other than "127.0.0.1". >Here are couple of examples: It is possible and some times >desired to have >Apache web server load balance tomcat servers that run on >physically different >machines; It is possible and some times useful to run mutiple Tomcat >instances on the same box that has multiple IP's (this may be good for >testing/developement). I agree you could run multiples tomcat on the same box, and in that case each JVM will listen AJP12 to handle shutdown on a differents port. >> Warning, Warning here. The "localhost" is used here for security >I strongly disagree with this:) If you configure your Ajp >connector to listen >to a particular interface someone _CAN_ send you shutdown >command regardless >of your shutdown code abilities. Let's be prudent here. The standard configuration must avoid security hole. Many users will have tomcat in front and we must avoid someone outside shutdown their TC boxes. >If you want security - you need to think about your network >configuration, >not the shutdown code. This is what sys admins are for:) Actually TC with it's localhost shutdown scheme is secure and why did you want to open the door to bad boys ?:) >A good example would be a machine that has multiple interfaces with >non-routable addresses (a developement machine) Or load >balanced machines behind the firewall. >I don't mean to enumerate all the possibilities here - this is >just a few >examples. > >> reasons. I didn't understand why your multihomed machine couldn't >> listen on localhost ? >> >> Thanks to give us more informations, for example did you use >multiples >> JVMs ? > >Our configuration: >We have a developement machine with multiple interfaces >running multiple >instances of Tomcat. It is behind the firewall. These >different interfaces >have different internal DNS names and you can't hit them from outside:) > >There are 2 ways to set up Tomcat here: > 1) All Ajp connectors bound to the same 127.0.0.1 but >on different ports. > 2) Ports are the same but Ajp connectors are bound to >different IP's I'm ok for the solution 1 and -1 for the solution 2. >We prefer second case. Why? - It's a matter of taste&style. >The problem is that in this case shutdown code misbehaves as >you may guess:) >Solution to this is very simple and I had it attached to >previous E-Mail. Don't forget that in web-server -> tomcat farm, web-servers will be in the 'sensible zone' and if they are compromized the attacker could just send the AJP12 command to shutdown all your Tomcat Next is a standard schema to protect Tomcat behind firewall and web server ! INTERNET ---> FIREWALL EXT ---> WEB SERVER --> FIREWALL INT ---> TOMCAT FARMS AJP12+AJP13 AJP13 ONLY NO AJP12 HERE In that case you're secure, nobody could send AJP12 shutdown from outside :)
TC 3.2.2 release
Hi, Did there is a date for the 3.2.2 release ? Just to be sure the RPM will be done ASAP - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [PROPOSAL/VOTE] New Repositories for Collaborative Development
The title of the thread was about "Collaborative Development" :! The objective of the new repositories are to help share some code between all the Tomcats. While working on using ajp12/ajp13 java code from Tomcat 3.3 CVS, I quickly realize the need for a common toolbox handling http related objects (Mimes, Cookies, MessageBytes...) We could imagine at least three subprojects : - jakarta-tomcat-toolbox An general toolbox, which defines and handle all sorts of http related projects, like cookies, mimes, request/response. May be code, interface, abstract (and so on) - jakarta-tomcat-connectors A kind of ORB based on HTTP with both native code (to link with majors WebServers) and java code (interfaces to be implemented in tomcats). This sub-project will use the jakarta-tomcat-toolbox - jakarta-tomcat-jasper the JSP implementation (which could also use jakarta-tomcat-toolbox). I can't speak for jasper34 but the connector goal is to have an open project with a common code for all the current (and future tomcats). I hope it will reduce questions on tomcat-user about 'mod_jk' build, configuration and use. In the spirit of openess, I'll send later today a document about the possible evolution of protocol between web-server and tomcat, AJP14. >We already went over this again and again and my conclusions were >always: > - People working on 3.3 have their own reasons to do it at the moment; > - Work is not being lost on 4.x because the 3.3 people do not have the > same motivation to work on 4.x; > - It is not a matter of one group being right and the other being > wrong. Yes, There is two teams working on differents core projects. The good news is that with the "Repositories for Collaborative Development" we could have peoples from each group working again together. That's important. >And that is what is happening here: at the moment (things will probably >evolve in some different direction) there are to big groups of itches >to scratch - 3.3 and 4.x. > >Instead of loosing more time fighting about the stupid concept of one >of the groups having to be wrong, let's focus on how the two groups >still can cooperate scratching common itches. +1 We must locate what could be common in both branch, and shared it. In TC 4.0, I think about the excellent works from Bip Thelin (TC 4.x Clustering). What make it specific to TC 4.x ? In contrario, why mod_jk from TC 3.3 couldn't be used in TC 4.x ? Also shareable are all objects related to HTTP (cookies, messages, headers, ). Having smaller CVS, will also encourage new commiters contributing in area where they could be more at ease. >There are some very interesting developments on this directions with >mod_jk and jasper. Focusing in this kind of thing is quite productive >and puts some of the 3.3 people cooperating in the development of the >4.x version and vice versa. +1 I strongly think that merging the best of 3.3 and 4.0 could make an incredible Tomcat 5.0. Having Costin and Craig in the same team may be a dream but frankly what a bright combinaison. Let's start by sharing what could be done, it will help identify what's the core and what could be modules (in reference to Apache http server no politics here :). Using 4.0 Valves and 3.3 modules didn't seems incompatible. There is many modules in 3.3 which are not related to Request/Response... >Trying to force one of the groups out of its way will just fragment >this project and take the 3.3 people somewhere else (SourceForge or >so). Not sure it will force people to go somewhere else. Some may be just tired of political problem and stop contributing to ASF. That will be bad news for both groups, and there will be no winner in that case, the looser will be the OpenSource spirit. >In due time, the usual survival rules will tend to favor the >solution that proves to be the best and everybody will work together >again... until the next revolution. A sort of 'Software Darwinism' and species adaptability.
RE: ajp12, ajp13, mod_webapp, and http protocols
>1. I know ajp protocol was originally introduced by >by mod_jserv to communicate with JServ. But what I >was wondering is, why at that time, a new protocol, >ajpxx was introduced rather using the existing http >protocol. ajp is faster than http and use less bandwith (binary compression) It's also a ligth protocol (compared to http 1.1 full proto) >2. As I mentioned in my previous email, I have >already implemented http worker (very similar to ajp12 >and ajp13 worker, with HTTP 1.0) in mod_jk. And it >works with Tomcat, Orion, JServ without any problem. >What it does is to simply forward the request to the >web container's http listener (like a proxy). (Thanks >for the great design of mod_jk!) When I compare the >performance between mod_jk/http/Tomcat and >mod_jk/ajp12/Tomcat, I can not see any difference. Could you provide the code ? Don't forget that ajp allow you to use a cluster of Tomcats... >3. I am working on implementing http 1.1 in my http >worker of mod_jk to take advantage of its persistant >connection with "KeepAlive" option. Once I am done, I >can compare the performance between >mod_jk/http1.1/Tomcat with mod_jk/ajp13/Tomcat because >ajp13 has persistant connection too. Thanks again to forward the code. >4. There seems to have no difference between http and >ajpxx protocols on hooking up with other web servers, >such as IIS, Netscape, ... mod_jk support JNI :) >5. Essentially, there is no difference between ajpxx >and http protocol in terms of forwarding the request >from the web server side to the web container side. >The only difference is the protocol itself. Yes >6. So, my conclusion is, if there is no performance >difference, with the advantage of that http can cross >firewall and almost all web containers support have >http listeners, why http is not used in either >mod_jserv, mod_jk or mod_webapp? I must have missed >some points. :-) mod_jk with ajp12/ajp13 is a one way protocol, web-server to servlet-engine. mod_jk/web-connector with ajp14 will be 2 way protocol, ie the servlet engine will talk with the web server (ie which context to handle, which URIs, status) Stay tuned for more info.
RE: Tomcat 3.2.2 beta 4 (insecure default settings)
>> > Let's be prudent here. The standard configuration must avoid >> > security hole. Many users will have tomcat in front and we >> > must avoid someone outside shutdown their TC boxes. >> Also if I'm not mistaken - Tomcat binds to all interfaces by >default as I don't >> see inet="" option set to 127.0.0.1 in default server.xml >file for Ajp >> connectors. I'll double check that:) You're right. TC still use ajp12 at its default connector so it listen all interface (which I agree could rise problem). I'm using in my prod systems, ajp13 to connect webservers and ajp12 only for the shutdown purpose (and listen only on localhost) >Here is the same test but with slightly modified server.xml: > > > > > Thanks to mention this one. The "inet" is not a well know and used param. >Please note that port 8007 is bound to 127.0.0.1 interface _ONLY_. The secure way. >So if security of default settings is of any concern I'd >suggest you, guys >modify default server.xml file the way described above. I understand your valid requirement, but why not just developp a servlet in admin which use ajp12 to send (to localhost), the ajp12 shutdown command. >Hope this helps :) Yes, and I hope you'll take a look at the ajp14 proposal...
RE: [PROPOSAL Tomcat 4.x] Cluster
Did you consider use the Multicast cluster with Spread (http://www.spread.org/) ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
[PROPOSAL AJP14] AJP13 Evolution
Hi to all, You could find attached a proposal of evolution to the current Apache JServ Protocol version 1.3, also known as ajp13. Let start the comments, questions, remarks cycle. PS : I've not cover here the full protocol but only the add-on from ajp13. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 Proposal for Apache JServ 1.4 This document is a proposal of evolution of the current Apache JServ Protocol version 1.3, also known as ajp13. I'll not cover here the full protocol but only the add-on from ajp13. Missing features in AJP13 - ajp13 is a good protocol to link a servlet engine like tomcat to a web server like Apache: * use persistants connections to avoid reconnect time at each request * encode many http commands to reduce stream size * send to servlet engine many info from web server (like SSL certs) But ajp13 lacks support for : * security between web server and servlet engine. Anybody can connect to an ajp13 port (no login mecanism used) You could connect, for example with telnet, and keep the remote thread up by not sending any data (no timeout in connection) * context information passed from servlet engine to web server. Part of the configuration of mod_jk, the web server connector, is to indicate to the web server which URI to handle. The mod_jk JkMount directive, told to web server which URI must be forwarded to servlet engine. A servlet engine allready knows which URI it handle and TC 3.3 is allready capable to generate a config file for mod_jk from the list of available contexts. * state update of contexts from servlet engine to web server. Big site with farm of Tomcat, like ISP and virtuals hosters, may need to stop a context for admin purposes. In that case the front web server must know that the context is currently down, to eventually relay the request to another Tomcat * verify state of connection before sending request. Actually mod_jk send the request to the servlet engine and next wait for the answer. But one of the beauty of the socket API, is you that you could write() to a closed connection without any error reporting, but a read() to a closed connection return you the error code. AJP14 add-ons to AJP13 -- Let's descrive here the features and add-on that will be added to AJP13, which will became AJP14. Since this document is a proposal, a resonable level of chaos must be expected at start. Be sure that discussion on tomcat list will help clarify points, add features but the current list seems to be a 'minimun vital' * Advanced login features at connect time * Basic authorisation system, where a shared secret key is present in web server and servlet engine : * Basic protocol negociation, just to be sure that if functionnalities are added to AJP14 in the future, current implementations will still works. Advanced login -- 1) WEB-SERVER send LOGIN INIT CMD + NEGOCIATION DATA 2) TOMCAT respond with LOGIN SEED CMD + RANDOM DATA 3) WEB-SERVER calculted the MD5 of RANDOM DATA+SECRET DATA 4) WEB-SERVER send LOGIN COMP CMD + MD5 (SECRET DATA + RANDOM DATA) 5) TOMCAT respond with LOGIN STATUS CMD + NEGOCIED DATA + SERVLET ENGINE INFO To prevent DOS attack, the servlet engine will wait the LOGIN CMD only 15/30 seconds and reports the timeout exception for admins investigation. The login command will contains basic protocol negociation information like compressing ability, crypto, context info (at start up), context update at run-time (up/down), level of SSL env vars, The servlet engine will mask the negociation mask with it's own mask (what it can do) and return it when loggin is accepted. This will help having a basic ajp14 implementation on a web-server working with a more advanced ajp14 on the servlet engine side or vice-versa. AJP13 was designed to be small and fast and so many SSL informations present in the web-server are not forwarded to the servlet engine. We add here four negociations flags to provide more informations on client SSL data (certs), server SSL datas , crypto used, and misc datas (timeout...). - Messages Stream - +-+---+ | LOGIN INIT CMD (1 byte) | NEGOCIATION DATA (32bits) | +-+---+ +-+---+ | LOGIN SEED CMD (1 byte) | MD5 of entropy (32 chars) | +-+---+ +-+---+ | LOGIN COMP CMD (1 byte) | MD5 of RANDOM + SECRET KEY (32 chars) | +-+---+ +++---+ | LOGOK CMD (1 byt
RE: bug 235, request problem
The bug 235 is fixed for some times now, but was incorrectly marked as open. I'm also using Apache 1.3.19 (with mod_ssl 2.8.2) and TC 3.2.2b4 or TC 3.3 from CVS. I'm using ajp13 (and ajp12) and got no problem (I got the correct user and auth type :!!!) -Henri Gomez ___[_]EMAIL : [EMAIL PROTECTED] (. .)PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message-From: Peter Meijer [mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 8:55 AMTo: [EMAIL PROTECTED]Subject: bug 235, request problem Dear subscribers, I've recently encountered a problem regarding to the mod_jk connector. When I used Basic Authentication with the Apache server (1.3.19) and tried to get the name of the user who has logged in, I get an old username from someone who had logged in a couple of hours ago. I have Tomcat version 3.2 installed to use Java. When I printed the headers of the request and the request.getPrincipal().getName(), the latter keeps changing the authenticated username in my loginname and of someone else, while the request headers keeps the same. I was wondering if this was due to bug 235? If so, in which release is this bug fixed? If not, maybe someone could tell me where to find a solution to this problem. Thanks in advance, Sogyo, Masters in e-Technology (www.sogyo.nl) Peter Meijer
About bug#208
Hi, The BUG #208 (request.getRemoteHost() returns empty string when using mod_jk BugRat Report#320) is still there (3.2.2b4). The difference is that when we're using ajp12, getRemoteHost = "" and in ajp13, getRemoteHost = null. The fix is easy the getRemoteAddr() is allways set but : - Did we want to Tomcat ask the DNS to resolve the name since it may be time consuming ? - ajp12 return empty string, ajp13 return null, what solution is recommanded in that case ? I also suspect TC 3.3 to have the same kind of problem ;( - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] >Sent: Monday, May 07, 2001 2:40 PM >To: [EMAIL PROTECTED] >Subject: [PROPOSAL AJP14] AJP13 Evolution > > >Hi to all, > >You could find attached a proposal of evolution to >the current Apache JServ Protocol version 1.3, >also known as ajp13. > >Let start the comments, questions, remarks cycle. > >PS : I've not cover here the full protocol but only the add-on > from ajp13. > >- >Henri Gomez ___[_] >EMAIL : [EMAIL PROTECTED](. .) >PGP KEY : 697ECEDD...oOOo..(_)..oOOo... >PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 > >
About bug#421
The BUG#421 could also be closed in 3.2.2 (no more in 3.3) (Code inspections shows that the definition of `jk_pool_atom_t' is conditional on some CPP macro that shows what the OS is: clearly on this system, the macro should be SOLARIS, but that isn't defined anywhere. apxs however defines a SOLARIS2 macro.) The fix is : --- src/native/jk/jk_pool.h.origMon May 7 16:08:04 2001 +++ src/native/jk/jk_pool.h Mon May 7 16:08:21 2001 @@ -91,6 +91,8 @@ typedef long long jk_pool_atom_t; #elif defined(NETWARE) typedef long long jk_pool_atom_t; +#else +typedef long long jk_pool_atom_t; #endif /* Could I commit it Marc ?
Can't close BUG#132
No Component define ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [PROPOSAL AJP14] AJP13 Evolution
>Lots of good stuff. A few ideas/possibilities: Happy to see you allready read it Dan :) > 1) We've talked about specifying a response packet to >indicate that the >engine (or the web server) doesn't recognize a packet sent >over. This would >allow us much more flexiblity to add packet types to ajpv14, >without having >to make ajpv15,16, etc. Could you develop ? > 2) What about specifying a separate, out of band control socket >connection? If the web server opened up two connections, 1 >for data, one >for control, then we could have much better communication from >the engine to >the server (if it was shutting down contexts, for example). >We could also >have a heartbeat without interfering with the data channel. Good idea, but how could we be sure that we'll have only one control channel to a given servlet engine ? In multi-threaded environnement like Apache 2.0, it's easy to launch a thread to handle that, but in Apache 1.3 will have no others choice than having each child (forked) opening it's own control connection since each child is forked and so have it's own copy of 'servlet-engine infos But I like this approach of splitting data and control. >-Dan > >GOMEZ Henri wrote: >> >> Hi to all, >> >> You could find attached a proposal of evolution to >> the current Apache JServ Protocol version 1.3, >> also known as ajp13. >> >> Let start the comments, questions, remarks cycle. >> >> PS : I've not cover here the full protocol but only the add-on >> from ajp13. >> >> - >> Henri Gomez ___[_] >> EMAIL : [EMAIL PROTECTED](. .) >> PGP KEY : 697ECEDD...oOOo..(_)..oOOo... >> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >> >> >--- >- >> Name: AJPv14.txt >>AJPv14.txtType: Plain Text (text/plain) >> Encoding: quoted-printable > >-- > >Dan Milstein // [EMAIL PROTECTED] >
nagoya / bug closing problems
Can't close Bug#354 since there is not Components defined. Same problem for Bug#421 There are both duplicate of bug #1343 we could fix by : --- src/native/jk/jk_pool.h.origMon May 7 16:08:04 2001 +++ src/native/jk/jk_pool.h Mon May 7 16:08:21 2001 @@ -91,6 +91,8 @@ typedef long long jk_pool_atom_t; #elif defined(NETWARE) typedef long long jk_pool_atom_t; +#else +typedef long long jk_pool_atom_t; #endif /* Who could fix the connector miss ?
RE: nagoya / bug closing problems - fixed
Oups, I succeed in marking as duplicate of bug #1343 the bug #354/#421 which no wait the following patch to be applied in 3.2.2 branch >--- src/native/jk/jk_pool.h.orig Mon May 7 16:08:04 2001 >+++ src/native/jk/jk_pool.hMon May 7 16:08:21 2001 @@ -91,6 +91,8 @@ typedef long long jk_pool_atom_t; #elif defined(NETWARE) typedef long long jk_pool_atom_t; +#else +typedef long long jk_pool_atom_t; #endif /*
RE: Problems building the Mod_jk.so
>We're tring to build the mod_jk.so on solaris 7 but, we have >the following >error: > >cc -DEAPI -DMOD_PERL -DUSE_EXPAT -O -G -Kpic >-I/usr/apache/include -I../jk >-I/us >r/java/include -I/usr/java/include/solaris -DSOLARIS -c mod_jk.c >/usr/ucb/cc: language optional software package not installed >apxs:Break: Command failed with rc=65536 > >we don't know how install the language package. Strange, what's this language package ? I'm not a Solaris specialist, only Linux Hacker :) >If you know other location where we can find the mod_jk.so >without compiling >it, it will be a good for us. I suggest you to mail the question to the user list
RE: About bug#208
>According to the JavaDoc for ServletRequest.getRemoteHost() > >Returns the fully qualified name of the client that sent the >request, or the >IP address of the client if the name cannot be determined. For HTTP >servlets, same as the value of the CGI variable REMOTE_HOST. > >Based on that I would say that both implementations are wrong, >you should >never get an empty or a null value back. I would also argue strongly >against having tomcat do any reverse DNS look ups. If the web server >doesn't tell us the remote host name just use the IP address. Ok, I'll do accordingly. Did the 3.2.2 tree is closed ? >> -Original Message- >> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] >> Sent: Monday, May 07, 2001 9:00 AM >> To: [EMAIL PROTECTED] >> Subject: About bug#208 >> >> >> Hi, >> >> The BUG #208 (request.getRemoteHost() returns empty string when >> using mod_jk >> BugRat Report#320) >> is still there (3.2.2b4). The difference is that when we're >using ajp12, >> getRemoteHost = "" >> and in ajp13, getRemoteHost = null. >> >> The fix is easy the getRemoteAddr() is allways set but : >> >> - Did we want to Tomcat ask the DNS to resolve the name since it may >> be time consuming ? >> >> - ajp12 return empty string, ajp13 return null, what solution is >> recommanded >> in that case ? >> >> I also suspect TC 3.3 to have the same kind of problem ;( >> >> - >> Henri Gomez ___[_] >> EMAIL : [EMAIL PROTECTED](. .) >> PGP KEY : 697ECEDD...oOOo..(_)..oOOo... >> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >> >> >> >> >-Original Message- >> >From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] >> >Sent: Monday, May 07, 2001 2:40 PM >> >To: [EMAIL PROTECTED] >> >Subject: [PROPOSAL AJP14] AJP13 Evolution >> > >> > >> >Hi to all, >> > >> >You could find attached a proposal of evolution to >> >the current Apache JServ Protocol version 1.3, >> >also known as ajp13. >> > >> >Let start the comments, questions, remarks cycle. >> > >> >PS : I've not cover here the full protocol but only the add-on >> > from ajp13. >> > >> >- >> >Henri Gomez ___[_] >> >EMAIL : [EMAIL PROTECTED](. .) >> >PGP KEY : 697ECEDD...oOOo..(_)..oOOo... >> >PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >> > >> > >
RE: About bug#208
>> According to the JavaDoc for ServletRequest.getRemoteHost() >> >> Returns the fully qualified name of the client that sent the >request, or the >> IP address of the client if the name cannot be determined. For HTTP >> servlets, same as the value of the CGI variable REMOTE_HOST. >> >> Based on that I would say that both implementations are >wrong, you should >> never get an empty or a null value back. That will be fixed ASAP. In TC 3.2.2, I'm not sure if the CVS is still open (imminent release) >Agreed. You should get either a host name or an IP address (in string >form). > >> I would also argue strongly >> against having tomcat do any reverse DNS look ups. If the web server >> doesn't tell us the remote host name just use the IP address. >> > >That works for the web-connected case. If you're running Tomcat >stand-alone you need to be able to do the lookup. In 4.0, that is only >done if the web app actually calls getRemoteHost(), so you >don't pay the >performance hit unless you ask for it. The DNS lookup must be done somewhere, and for example well-configured Apache HTTP servers didn't do the DNS lookup. So the RemoteHostName will not be passed in ajp12/ajp13. The job must be done by the servlet engine. It's the case in TC 3.2 for the HTTP connector. I'll modify the code accordingly.
RE: About bug#208
>I just commited the fix for 3.2.2. Not really. When the hostname is null or missing, you copy the host IP adress, but we there the name (DNS resolution). Something done by the caller (which agree to pay the price). >> -Original Message- >> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] >> Sent: Monday, May 07, 2001 11:16 AM >> To: [EMAIL PROTECTED] >> Subject: RE: About bug#208 >> >> >> >According to the JavaDoc for ServletRequest.getRemoteHost() >> > >> >Returns the fully qualified name of the client that sent the >> >request, or the >> >IP address of the client if the name cannot be determined. For HTTP >> >servlets, same as the value of the CGI variable REMOTE_HOST. >> > >> >Based on that I would say that both implementations are wrong, >> >you should >> >never get an empty or a null value back. I would also >argue strongly >> >against having tomcat do any reverse DNS look ups. If the >web server >> >doesn't tell us the remote host name just use the IP address. >> >> Ok, I'll do accordingly. >> Did the 3.2.2 tree is closed ? >> >> >> -Original Message- >> >> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] >> >> Sent: Monday, May 07, 2001 9:00 AM >> >> To: [EMAIL PROTECTED] >> >> Subject: About bug#208 >> >> >> >> >> >> Hi, >> >> >> >> The BUG #208 (request.getRemoteHost() returns empty string when >> >> using mod_jk >> >> BugRat Report#320) >> >> is still there (3.2.2b4). The difference is that when we're >> >using ajp12, >> >> getRemoteHost = "" >> >> and in ajp13, getRemoteHost = null. >> >> >> >> The fix is easy the getRemoteAddr() is allways set but : >> >> >> >> - Did we want to Tomcat ask the DNS to resolve the name >since it may >> >> be time consuming ? >> >> >> >> - ajp12 return empty string, ajp13 return null, what solution is >> >> recommanded >> >> in that case ? >> >> >> >> I also suspect TC 3.3 to have the same kind of problem ;( >> >> >> >> - >> >> Henri Gomez ___[_] >> >> EMAIL : [EMAIL PROTECTED](. .) >> >> PGP KEY : 697ECEDD...oOOo..(_)..oOOo... >> >> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >> >> >> >> >> >> >> >> >-Original Message- >> >> >From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] >> >> >Sent: Monday, May 07, 2001 2:40 PM >> >> >To: [EMAIL PROTECTED] >> >> >Subject: [PROPOSAL AJP14] AJP13 Evolution >> >> > >> >> > >> >> >Hi to all, >> >> > >> >> >You could find attached a proposal of evolution to >> >> >the current Apache JServ Protocol version 1.3, >> >> >also known as ajp13. >> >> > >> >> >Let start the comments, questions, remarks cycle. >> >> > >> >> >PS : I've not cover here the full protocol but only the add-on >> >> > from ajp13. >> >> > >> >> >- >> >> >Henri Gomez ___[_] >> >> >EMAIL : [EMAIL PROTECTED](. .) >> >> >PGP KEY : 697ECEDD...oOOo..(_)..oOOo... >> >> >PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >> >> > >> >> > >> > >
RE: [PROPOSAL AJP14] AJP13 Evolution
In the doc, the secret key is a string present in web-server and servlet engine : must be defined for each workers: worker.myworker.port=8010 worker.myworker.type=ajp14 worker.myworker.host=myremotesystem worker.myworker.secretkey=myverysecretkey <= in TC 3.2.x => <= in TC 3.3 => <= in TC 4.0 => AJP12/MOD_JSERV used the same system of allready know common key. The key is passed in md5 to get the 32 chars data - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: About bug#208
>>I just commited the fix for 3.2.2.
>
>Not really.
Arg damn't kd
When the hostname is null or missing, you just copy the host IP
adress.
I'd like better the HTTP native connector method :
public String getRemoteAddr() {
return xxx.getInetAddress().getHostAddress();
}
public String getRemoteHost() {
return xxx.getInetAddress().getHostName();
}
The name lookup (DNS resolution) will be done on
demand done by the caller (which agree to pay the price)
>
>>> -----Original Message-
>>> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>>> Sent: Monday, May 07, 2001 11:16 AM
>>> To: [EMAIL PROTECTED]
>>> Subject: RE: About bug#208
>>>
>>>
>>> >According to the JavaDoc for ServletRequest.getRemoteHost()
>>> >
>>> >Returns the fully qualified name of the client that sent the
>>> >request, or the
>>> >IP address of the client if the name cannot be determined. For HTTP
>>> >servlets, same as the value of the CGI variable REMOTE_HOST.
>>> >
>>> >Based on that I would say that both implementations are wrong,
>>> >you should
>>> >never get an empty or a null value back. I would also
>>argue strongly
>>> >against having tomcat do any reverse DNS look ups. If the
>>web server
>>> >doesn't tell us the remote host name just use the IP address.
>>>
>>> Ok, I'll do accordingly.
>>> Did the 3.2.2 tree is closed ?
>>>
>>> >> -Original Message-
>>> >> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>>> >> Sent: Monday, May 07, 2001 9:00 AM
>>> >> To: [EMAIL PROTECTED]
>>> >> Subject: About bug#208
>>> >>
>>> >>
>>> >> Hi,
>>> >>
>>> >> The BUG #208 (request.getRemoteHost() returns empty string when
>>> >> using mod_jk
>>> >> BugRat Report#320)
>>> >> is still there (3.2.2b4). The difference is that when we're
>>> >using ajp12,
>>> >> getRemoteHost = ""
>>> >> and in ajp13, getRemoteHost = null.
>>> >>
>>> >> The fix is easy the getRemoteAddr() is allways set but :
>>> >>
>>> >> - Did we want to Tomcat ask the DNS to resolve the name
>>since it may
>>> >> be time consuming ?
>>> >>
>>> >> - ajp12 return empty string, ajp13 return null, what solution is
>>> >> recommanded
>>> >> in that case ?
>>> >>
>>> >> I also suspect TC 3.3 to have the same kind of problem ;(
>>> >>
>>> >> -
>>> >> Henri Gomez ___[_]
>>> >> EMAIL : [EMAIL PROTECTED](. .)
>>> >> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>>> >> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>>> >>
>>> >>
>>> >>
>>> >> >-Original Message-
>>> >> >From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>>> >> >Sent: Monday, May 07, 2001 2:40 PM
>>> >> >To: [EMAIL PROTECTED]
>>> >> >Subject: [PROPOSAL AJP14] AJP13 Evolution
>>> >> >
>>> >> >
>>> >> >Hi to all,
>>> >> >
>>> >> >You could find attached a proposal of evolution to
>>> >> >the current Apache JServ Protocol version 1.3,
>>> >> >also known as ajp13.
>>> >> >
>>> >> >Let start the comments, questions, remarks cycle.
>>> >> >
>>> >> >PS : I've not cover here the full protocol but only the add-on
>>> >> > from ajp13.
>>> >> >
>>> >> >-
>>> >> >Henri Gomez ___[_]
>>> >> >EMAIL : [EMAIL PROTECTED](. .)
>>> >> >PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>>> >> >PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>>> >> >
>>> >> >
>>> >
>>
>
RE: NBIO
Good stuff. Thanks - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Jon Stevens [mailto:[EMAIL PROTECTED]] >Sent: Monday, May 07, 2001 11:25 PM >To: tomcat-dev >Subject: NBIO > > >http://www.cs.berkeley.edu/~mdw/proj/java-nbio/ > >How about using that? :-) > >-jon >
RE: Tomcat 3.2.2 beta 4 - AJP14 continuation
> >Should it become default? I hope the answer is yes:) > >It also has another value: "inet" is not a well-known >parameter. Having it in default server.xml along with a little >comment about >what it does may compensate for the lack of proper documentation:) +1 for the addition in server.xml (Marc, Larry ?) >> I understand your valid requirement, but why not just developp a >> servlet in admin which use ajp12 to send (to localhost), the ajp12 >> shutdown command. >> >> >Hope this helps :) >> >> Yes, and I hope you'll take a look at the ajp14 proposal... >I did. >I don't really understand why Ajp protocol should handle >shutdown command >at all. I agree that there may be a need for some kind of servlet that >handles this operation but WHY THROUGH Ajp protocol??? Adding shutdown in ajp14 will help a web admin to build a control deck to shutdown from ONE POINT some or all of its Tomcat. >It almost sounds like merging two things that serve totally >different purpose >together. What if you want to add more commands in the future? The AJP14 is not closed, it's just a starting point for discussion. >Would you >really want to add these commands into ALL versions of >protocol? And how do >you handle these commands if you don't? The AJP15 must handle all commands from AJP14 and will have its owns one. Also you must have notice about the negociation at startup. Some asked to add at start of negociation a string indicating which protocol are supported by web-server. The servlet engine will then use the higher common protocol : ie: web-servlet knows about AJ14/AJP15 but servlet engine only AJP14. The protocol used will be AJP14. web-servlet knows AJ14/AJP15 and servlet engine AJP14/AJP15/AJP16. The discussion will use AJP15. >IMHO there are few related but different things one wants to >do with TC: >1)Serve requests - handled by Ajp protocol. >2)Configure&administrate - this one is a bit more complex. > > Some people (including myself) like doing configuration >manually in > command line interface. Hence there needs to be well >defined set of config > files and scripts one needs to care about. One of my >personal challenges > while setting up TC for the first time was to find out >what config files > are actually necessary. There is whole bunch of files >in config directory > for ALL the possible platforms/servers, etc. I'm like you and do by hand all my configuration, and set my JkMount in VirtualHost. But many starting users will like the autoconf features. Note that JkMount could still be used and JkAutoMount is then mandatory... > Some people would prefer to use some UI tool to >configure the server and > issue commands - here is your idea of extending >functionality of "admin" > application, add shutdown/restart commands to it as >well as may be some > other options like configuring "connectors", including >configuration of > ports, interfaces, etc. There may even be some applet >for monitoring > the log files (like in Sun's JavaWebServer). > I think good example is configuration as it is done in >"Enhydra". > This kind of tool doesn't need any "middle man" in the >form of Ajp or any > other protocol. It can have hooks directly into server >API. The advantage > of this is that Ajp protocols remain "plugguble" unlike >Ajp12 that you > "need to have" to issue simple "shutdown" command and >configuration > may evolve without any weird dependencies on any >particular protocol. Some Admin Servlet could do the job > Some people MIGHT want to set up distributed >environment (read load > balancing here) where the same application is >physically distributed > across multiple machines but configuration MUST be >changed synchronously. > This may be handled just by some *NIX scripts, etc but >in this case > having some "administration" protocol might be usable >to build "centralized" > configuration where all the changes are made in one >place and communicated > to all the balanced servers using some protocol. There >are lots of > complicated issues here but this is the place where >IMHO some protocol > might be NECESSERY. And even than I wouldn't add this >features into > any Ajp?? protocols. I'd much rather define another one >that again may > evolve differently from Ajp protocols but might use Ajp >protocol as a > transport layer. AJP13 is still present and supported, but lack some features needed for Servlet API 2.3. My english is bad but AJP14 WILL USE AJP13 as transport layer, there will be new commands added and new cinematic, but AJP14 = AJP13++ >Here is the list of modifications that I've done to TC so far: >1) changed defaults to bind to 127.0.0.1 interface in server.xml. Will be changed in server.xml for 3.2/3.3 (Marc/larry are you agree) >2) changed shu
RE: About bug#208
>The previous behavior violated the spec and therefore had to be changed >prior to releasing 3.2.2. Right now I can live with a simple solution. And you fix it. >I'm waiting to hear back from a user to make sure that the >last change for >JDK 1.1 support fixed his problem and then I plan to call a >final release >vote for TC3.2.2. Adding DNS lookups is not something I'm >comfortable with >at this point. > >Marc "Just ship it" Saegesser Could be changed by : Marc "Thanks to ship it" Saegesser :) I agree with you the fix will be suffisant for 3.2.2 release which is imminent ? Thanks for that just-in-time fix
RE: [PROPOSAL AJP14] AJP13 Evolution
>Will this be the next step to combining mod_webapp with >mod_jk? Discussion is open and Pier is my guess, even if he loose an occasion to eat splendid 'pasta fresca'. >Maybe this could be the first step to merging the two. >ajp14 could offer some automatic configuration similar >to mod_webapp, as you suggested in the proposal. >I also think that a security mechanism is important. >There should be some form of login for the connector to >make sure that communication with the server is allowed. >I think we should be careful with the security side, >however. This could lead into a complex discussion >over what is appropriate. My suggestion would be to >go with something simple, as suggested in the proposal. The system is aimed to be simple, we don't want SSH/SSL here but just a basic 'protected' login. >This level of security would cover most of the installations >and when someone requires an additional level of security or >interface to other security mechanisms, that could be added >later. We can add native SSH tunneling for example using openssh. >This proposal hits on the most important issues with mod_jk >at this point. > >+1 > >As for the security key, would it be possible to generate >a unique key when mod_jk is first installed? Maybe we could >create some basic mechanism, similar to the way ssh generates >a key when it is installed. This would avoid the possibility >of having many TC servers out there that can be logged into >with the default key or no key. It could avoid the problem >that the admin webapp has with the password needing to be changed >and trust being turned on. mod_jk could serve many tomcats on different systems. Each Tomcat could need a different secret key, but worker concept help here. Cf my previous mail about it >Just a thought. > >Mike. >-- >Mike Braden >[EMAIL PROTECTED] >[EMAIL PROTECTED] > >-Original Message- >From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] >Sent: Monday, May 07, 2001 8:40 AM >To: [EMAIL PROTECTED] >Subject: [PROPOSAL AJP14] AJP13 Evolution > > >Hi to all, > >You could find attached a proposal of evolution to >the current Apache JServ Protocol version 1.3, >also known as ajp13. > >Let start the comments, questions, remarks cycle. > >PS : I've not cover here the full protocol but only the add-on > from ajp13. > >- >Henri Gomez ___[_] >EMAIL : [EMAIL PROTECTED](. .) >PGP KEY : 697ECEDD...oOOo..(_)..oOOo... >PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 > >
RE: [PROPOSAL AJP14] AJP13 Evolution
>> 1) We've talked about specifying a response packet to >indicate that the >> engine (or the web server) doesn't recognize a packet sent >over. This would >> allow us much more flexiblity to add packet types to ajpv14, >without having >> to make ajpv15,16, etc. > >+1 > >In other words - both ends should deal with unknown packets - maybe by >sending back an "UNIMPLEMENTED" message. Since AJP indicate size we could deal with unknow packets. But if we negociate at startup the common protocol level, we must avoid that situation. I like the idea of reject cmd, +1 > >> 2) What about specifying a separate, out of band control socket >> connection? If the web server opened up two connections, 1 >for data, one >> for control, then we could have much better communication >from the engine to >> the server (if it was shutting down contexts, for example). >We could also >> have a heartbeat without interfering with the data channel. > >I'm not sure - but I can see some benefits. > >Right now we have (almost) bidirectional communication - the >protocol is >based on message passing, and sort of "token"-based: >each side sends a message, then waits for a message. > >The main reason for that is the single-threaded web server. ( >Apache1.3, >maybe other servers ). It is a bit difficult to deal with 2 >connections in >a single threaded env ( while keeping the code as simple as possible ). >My feeling is that for most needs of a servlet container we >can deal with >the single socket protocol. I don't know any (major) use case >or feature >of tomcat that would require the second socket. Argh, all the subtility is here. Basically even if ajp13 is a bidirectional protocol, it's a request/reply protocol since it's how a web server function : 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR RESPONSE 3) GET RESPONSE AND FORWARD TO WEB-SERVER. We could have a second socket for control but : 1) How did we share it in forked (apache 1.3) env ? => shared memory => MM or APR 2) Ditto in a threaded architecture (Apache 2.0) at least in MPM mode (a forked child which will in turn thread child), but again how did we info we other forked. Also doubling the socket, will double the descriptors open and will be a problem under heavy load. In an HTTP architecture we need again to mix data (tons of messages) with control (very low traffic). And so we need to read for possible message at some time. 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE 2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE 3) GET ADMIN MESSAGE and evnetually RESPONSE 4) GET RESPONSE AND FORWARD TO WEB-SERVER. The admin message could be send() in socket at any time and will be handled when a request will came
RE: [PROPOSAL AJP14] AJP13 Evolution
>2 things: > >> The system is aimed to be simple, we don't want SSH/SSL >> here but just a basic 'protected' login. > >and that you can bind the socket to 127.0.0.1: instead >of *: >through a config change. In that case, you restrict to a web-sevlet/tomcat on the same machine, but yes we could do that (allready possible on TC 3.2/3.3) >>>This level of security would cover most of the installations >>>and when someone requires an additional level of security or >>>interface to other security mechanisms, that could be added >>>later. >> >> We can add native SSH tunneling for example using openssh. > >You could do that already with no modifications to the ajp by >using port >forwarded SSH tunneling. Heck, you could do it with STunnel if >you want to >use RSA/SSL instead of SSH also without modifications to ajp. I better use jonama (http://www.multimania.com/jonama/) to do SSL tunneling since I wrote this one ;)
RE: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
+0 but with RPM packaging ;) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, May 08, 2001 4:22 AM >To: [EMAIL PROTECTED] >Subject: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release > > >Now that the "Proposed Final Draft 2" versions of the Servlet >2.3 and JSP >1.2 specs have been published (with Tomcat 4.0 updated to support the >latest changes), and a ton of bug fixes have been made, I would like to >propose that we create a "Tomcat 4.0 Beta 4" release as follows: > > Release Manager: Craig McClanahan > Code Freeze: Thursday, May 10, 2001 at 05:00pm Pacific Time > >See the file "RELEASE-NOTES-4.0-B4.txt" for a reasonably >up-to-date list >of the changes to date. This document will be updated with >any additional >changes that are made, plus a list of known outstanding issues. > >Between now and the code freeze, I'd like us to focus on fixing >outstanding bugs and catching the configuration documentation up to >date. I'm OK with continuing work on the new distributed >session stuff in >the mean time (as long as it is not enabled in the default >configuration), but please hold off on making substantive >changes in the >core container until after the Beta 4 release. > >Comments? Votes? > >The usual rules apply: > [ ] +1 = I agree with this proposal and will support it > [ ] +0 = I agree with this proposal, but do not have time to >support it > [ ] -0 = I do not agree with this proposal, but don't want to try > to block it > [ ] -1 = I do not agree with this proposal (requires reasons) > > >Craig > >
RE: [PROPOSAL AJP14] AJP13 Evolution
>> 1) How did we share it in forked (apache 1.3) env ? >>=> shared memory => MM or APR > >APR of course: MM is included in it. But APR is only available in Apache 2.0, what about Apache 1.3, NES and IIS ? And MM is still only for Unix OS >> >> 2) Ditto in a threaded architecture (Apache 2.0) >>at least in MPM mode (a forked child which will in turn thread >>child), but again how did we info we other forked. >> >> Also doubling the socket, will double the descriptors open >> and will be a problem under heavy load. >> In an HTTP architecture we need again to mix data (tons of >> messages) with control (very low traffic). And so we need >> to read for possible message at some time. >> >> 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE >> 2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE >> 3) GET ADMIN MESSAGE and evnetually RESPONSE >> 4) GET RESPONSE AND FORWARD TO WEB-SERVER. >> >> The admin message could be send() in socket at any time and >> will be handled when a request will came > >Apjp13 requests are not multiplexed, so we need more that one >connection. How >could we decide on which connection we send the admin message? >Otherwise we will >the send the same data more than once. The admin response could be sent on EACH AJP13 connections, and it will be web-server task to discard allready received admin message... >What happends when the configuration is changed more than once >and no request >happend in the meantime... >We could get a wrong configuration... If we have a DOWN event and then a UP event, the servlet engine send a DOWN message and then a UP message. The web-servlet will have to read ALL ADMIN messages and process the whole block...
RE: [PROPOSAL AJP14] AJP13 Evolution
>I have the following idea: > >JServ has a nice feature "ApJServManual off", the mod_jserv >starts the JVM and >check via pings messages that is goes on running. It would be >nice to put the >feature in AJP14. >JkStartTomcat path_name server_conf_name time_out A feature asked by many JServ users which may be easy to add. Why not >Where >path_name is a path to a C wrapper like catalina.c (C version >of catalina.sh) >server_conf_name is the well known server.xml file. >time_out a value in second to allow Tomcat to start. > >I have the problem that the webserver have to read the >server.xml file to find >the port it should use to connect to Tomcat. - The port used >in the server.xml >file should not be changed before the webserver gets the connection - The web-server could use the default port (8010 ?) or we could add it in JkStartTomcat : JkStartTomcat path_name server_conf_name time_out ajp14port >Cheers > >Jean-frederic > >GOMEZ Henri wrote: >> >> Hi to all, >> >> You could find attached a proposal of evolution to >> the current Apache JServ Protocol version 1.3, >> also known as ajp13. >> >> Let start the comments, questions, remarks cycle. >> >> PS : I've not cover here the full protocol but only the add-on >> from ajp13. >> >> - >> Henri Gomez ___[_] >> EMAIL : [EMAIL PROTECTED](. .) >> PGP KEY : 697ECEDD...oOOo..(_)..oOOo... >> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >> >> >--- >- >> Name: AJPv14.txt >>AJPv14.txtType: Plain Text (text/plain) >> Encoding: quoted-printable >
RE: [PROPOSAL AJP14] AJP13 Evolution
>> 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE >> 2) WAIT FOR RESPONSE >> 3) GET RESPONSE AND FORWARD TO WEB-SERVER. > >Well, I see it a bit different :-) > >1. Apache sends a message to tomcat with the original request >( or part of it ! - for example it can send only some headers that are >commonly used ), then start waiting. > >2. Tomcat receives the message, start processing. When he >needs something >from apache ( like sendHead or get info or auth or admin commands ) it >sends a message, then start waiting. > >3. That goes on, with a message acting as a token. At any time >one side is >listening, and the other ( who reveived the last message ) has the >control. > >In a way it's like a single "virtual" thread of execution, >with the apache >thread and tomcat thread passing control via messages. > >Now, I know this sounds complicated - but it's a good solution >with very >little overhead. This is not a general RPC protocol, but something >specialized for tomcat, and it works very well with single-threaded >processes. The only reserve will be about speed. Won't these write() and read() make web-server too slow. But that's interesting and will need testing in real condition. AJP14 could test these experimental schemas. >Even in Apache2.0 - creating threads for each tomcat callback and using >additional sockets is significant overhead given the time constraints. > >The problem is that the "admin" commands can be passed only on certain >moments: >- when apache connects for the first time ( the socket will be >kept open ) >- when apache sends a request > >I think that should be enough for what we need - if we make it more >complex we may add too much overhead. ( and we may not be able to have >good support for Apache1.3 ) More overhead will make ajp14 slower than ajp13, or even ajp12 and that's not the goal since admin message are only 1% of the real traffic
RE: [PROPOSAL AJP14] AJP13 Evolution
>ajp13 reuses connections, but, in general for each "worker" >there will be a >pool of connections between the web server and the servlet >engine. That way >it can handle multiple requests concurrently, but still save >on the socket >creation time (since connections are reused for many requests). >So deciding which connection to send the admin messages on is, in fact, >important. Not only do we have to watch out for resending >data, but we also >have to make sure we send data to all the participating web servers >(multiple Apaches can talk to one TC, and, if they do so, they >can all hit >the same port, in which case some ajp13 threads are talking to >one, some to >another). Each AJP14 thread in Tomcat must send admin messages. It will be the task of web-server to remove duplicate messages. >Maybe we should tag the TC->Apache admin messages with an id >-- that way we >could just send them out on all conections, and the various >Apache children >would make sure they only react to a given message once (possibly >communicating w/ each other via shared memory). This will >make the problem >of informing all participating Apache instances go away, and >we may need to >play some shared memory games in any event, to make sure that >all the Apache >procs are brought up to date. +1 for the ID of admin messages, which make the removing easier. shared memory will make mod_jk port on differents web-server/OS more harder, and we might introduce here the use of APR. But there is APR specialists around !=) >-Dan > >Mike Braden wrote: >> >> Why not just handle each connection as if it is a connection >> from a different server, logging in each time. >> >> Are ajp13 requests serialized? ajp13 only connects to TC >> once to the port set in the config, right? >> >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of jean-frederic clere > Sent: Tuesday, May 08, 2001 5:19 AM > To: [EMAIL PROTECTED] > Subject: Re: [PROPOSAL AJP14] AJP13 Evolution > > Apjp13 requests are not multiplexed, so we need more that one connection. > How > could we decide on which connection we send the admin message? Otherwise we > will > the send the same data more than once. -- Dan Milstein // [EMAIL PROTECTED]
RE: Tomcat 3.2.2 beta 4
Could you try with the mod_jk from TC 3.3 cvs ? Could you also send a small servlet for test purpose ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Tomcat 3.2.2 : RE : cvs commit: jakarta-tomcat/src/doc readme
Hi Marc, Could you clarify the getRemoteHost in readme :=> === 7. FIXES AND ENHANCEMENTS IN UPDATES @@ -318,6 +332,8 @@ - HttpServletRequest.encodeURL() now properly encodes URLs that contain an anchor but no query string. (#1182) - Error pages now work in virtual hosts. + - ServletRequest.getRemoteHost() now returns the remote IP address + if the remote host name isn't known. (#208) => === 7. FIXES AND ENHANCEMENTS IN UPDATES @@ -318,6 +332,8 @@ - HttpServletRequest.encodeURL() now properly encodes URLs that contain an anchor but no query string. (#1182) - Error pages now work in virtual hosts. + - ServletRequest.getRemoteHost() now returns the remote IP address + if the remote host name has not been resolved by web-server. (#208) Regards
RE: New CVS Repositories
Thanks - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, May 08, 2001 4:14 AM >To: [EMAIL PROTECTED] >Subject: New CVS Repositories > > >Per our discussion today, I have created two new CVS repositories >associated with the Tomcat subproject: > > jakarta-tomcat-connectorsFor development of web connectors > for various versions of Tomcat. > > jakarta-tomcat-jasperFor development of a next generation > Jasper (JSP) implementation. > >As with the other repositories that are part of Tomcat, all Tomcat >committers have commit access to these new repositories automatically. > >Craig > >
RE: [PROPOSAL AJP14] AJP13 Evolution
Many users have asked for more web-server env vars they like to use also in Tomcat. May be something to add to AJP14 will be the ability to define a list of env vars to be forwarded to Tomcat, the same way the SSL web-server vars are defined : # What is the indicator for SSL session (default is SSL_SESSION_ID) JkSESSIONIndicator SSL_SESSION_ID # What is the indicator for client SSL cipher suit (default is SSL_CIPHER) JkCIPHERIndicator SSL_CIPHER # What is the indicator for the client SSL certificated (default is SSL_CLIENT_CERT) JkCERTSIndicator SSL_CLIENT_CERT May be with the directive JkEnvVars MYVAR1 MYVAR2 MYVAR3 MYVAR4... The traffic will be more important but these informations will be usefull for some... What about that ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [PROPOSAL] Update to Tomcat 3.3 Release Plan
+1 And +1 for the list of open bugs which are high priority... - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
RPMs are allways present in binary and source packaging : tomcat4-4.0-b3.1.noarch.rpm17-Apr-2001 17:22 3.5M tomcat4-4.0-b3.1.src.rpm 17-Apr-2001 17:20 1.6M tomcat4-manual-4.0-b3.1.noarch.rpm 17-Apr-2001 17:22 1.1M - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, May 09, 2001 1:45 AM >To: [EMAIL PROTECTED] >Subject: RE: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release > > > > >On Tue, 8 May 2001, GOMEZ Henri wrote: > >> +0 but with RPM packaging ;) >> > >And source packages, right Henri? :-) > >They will be there at the same time as the binaries this time. > >Craig >
RE: [PROPOSAL AJP14] AJP13 Evolution
The question was the availability on system running NES (Windows/Unixes) and IIS (Windows). I really like APR, but having it at a pre-requisite to mod_jk for AJP14 will raise new questions. How could I build APR usinb Borland C++ 5.5 under Window Millenium ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Jon Stevens [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, May 09, 2001 3:16 AM >To: tomcat-dev >Subject: Re: [PROPOSAL AJP14] AJP13 Evolution > > >on 5/8/01 3:00 PM, "GOMEZ Henri" <[EMAIL PROTECTED]> wrote: > >> But APR is only available in Apache 2.0, what about Apache 1.3, >> NES and IIS ? > >That isn't true. http://Apr.apache.org/ > >APR is just a library. > >-jon > >-- >If you come from a Perl or PHP background, JSP is a way to take >your pain to new levels. --Anonymous ><http://jakarta.apache.org/velocity/ymtd/ymtd.html> >
RE: [PROPOSAL AJP14] AJP13 Evolution
That's present in AJP14 description about negociation flags :) - Negociations Flags - AJP14_CONTEXT_INFO_NEG 0x8000 /* web-server want context info after login */ AJP14_CONTEXT_UPDATE_NEG 0x4000 /* web-server want context updates */ AJP14_GZIP_STREAM_NEG0x2000 /* web-server want compressed stream */ AJP14_DES56_STREAM_NEG 0x1000 /* web-server want crypted DES56 stream with secret key */ AJP14_SSL_VSERVER_NEG0x0800 /* Extended info on server SSL vars */ AJP14_SSL_VCLIENT_NEG0x0400 /* Extended info on client SSL vars */ AJP14_SSL_VCRYPTO_NEG0x0200 /* Extended info on crypto SSL vars */ AJP14_SSL_VMISC_NEG 0x0100 /* Extended info on misc SSL vars */ AJP14_SSL_VCRYPTO_NEG flag !) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, May 09, 2001 1:59 AM >To: [EMAIL PROTECTED] >Subject: RE: [PROPOSAL AJP14] AJP13 Evolution > > >Just as a note, if you want AJP14 to be usable in a Servlet 2.3 >environment, you *must* expose the cipher suite and key size >(which might >be implied from the cipher suite name) to Tomcat, because >Tomcat must in >turn expose them as request attributes to servlets processing SSL >requests. > >In addition, if there is a client certificate included with >the request, >it also needs to be exposed, but I believe that is already being done, >isn't it? > >Craig > > >On Wed, 9 May 2001, GOMEZ Henri wrote: > >> Many users have asked for more web-server env vars >> they like to use also in Tomcat. >> >> May be something to add to AJP14 will be the >> ability to define a list of env vars to be forwarded >> to Tomcat, the same way the SSL web-server vars are >> defined : >> >> # What is the indicator for SSL session (default is SSL_SESSION_ID) >> JkSESSIONIndicator SSL_SESSION_ID >> # What is the indicator for client SSL cipher suit (default >is SSL_CIPHER) >> JkCIPHERIndicator SSL_CIPHER >> # What is the indicator for the client SSL certificated (default is >> SSL_CLIENT_CERT) >> JkCERTSIndicator SSL_CLIENT_CERT >> >> May be with the directive >> >> JkEnvVars MYVAR1 MYVAR2 MYVAR3 MYVAR4... >> >> >> The traffic will be more important but these informations >> will be usefull for some... >> >> What about that ? >> >> >> - >> Henri Gomez ___[_] >> EMAIL : [EMAIL PROTECTED](. .) >> PGP KEY : 697ECEDD...oOOo..(_)..oOOo... >> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >> >
RE: New CVS Repositories
Couldn't access these CVS directories, could you check group ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, May 08, 2001 4:14 AM >To: [EMAIL PROTECTED] >Subject: New CVS Repositories > > >Per our discussion today, I have created two new CVS repositories >associated with the Tomcat subproject: > > jakarta-tomcat-connectorsFor development of web connectors > for various versions of Tomcat. > > jakarta-tomcat-jasperFor development of a next generation > Jasper (JSP) implementation. > >As with the other repositories that are part of Tomcat, all Tomcat >committers have commit access to these new repositories automatically. > >Craig > >
RE: ajp13 and tomcat 4
>so, i guess the essence of this message is, what might be a short-term >plan for having ajp13 support in tomcat 4? > >i have done some preliminary work, creating an ajp13 connector >for tc 4, >which for the most part works. > >long term, i think part of this code will live in >jakarta-tomcat-connectors, and hopefully it will use some >classes that i >had to remove (i.e. MessageBytes) from some other place (i >don't know if >things like this will live in commons, or some tomcat-toolkit >component). > >in the short term, what would people think about adding ajp13 connector >support directly into tomcat 4 until the discussion around >jakarta-tomcat-connectors, common utility stuff that can be refactored >out of the tomcat 3.x base, etc., can be hashed out? The discussion about jakarta-tomcat-connectors is closed and the CVS is created (even if I still couldn't access it) >-kevin. > >btw, the reason i'm so interested in this because i want to make the >switch from tc3 to tc4, but i *have* to have connector support for iis >and netscape before i can do that :) jakarta-tomcat-connector will contains both up to date native mod_jk code and java code for TC 3.2/3.3/4.0, so I really recommand you to commit your code there.
[PROPOSAL AJP14] AJP13 Evolution - Second Pass
Find attached the modified AJP14 proposal which include the remarks and request from the list. Nota : The launch of Tomcat JVM by the mod_jk/jakarta-connector is not covered since we speak here only about protocol. That feature is something asked by many JServ users and may be added later in the native part, at least in Apache 1.3/2.0 mode. I'm not sure how it can be done when using IIS or NES. The automatic context update was an interesting subject and how we can have these kind of admin informations raised more questions than answers. Opening alternate sockets (control socket) we'll load more the web-server with more opened sockets : on forked environnement (ie Apache 1.3), 2 x forked (1 data + 1 admin) on threaded environnement (ie Apache 2.0), 1 x forked (x threaded data + 1 admin) A solution could be to use the URGENT DATA mode of TCP/IP socket but I'm not sure it's supported now in JDK 1.1/1.2/1.3 Another solution is to delay the automatic update mode. AJP14 have provision on NEGOCIATION phase to disactivate this feature. But we still need to know when a context is DOWN and later UP. * A lazy solution could be to have the servlet engine drop all AJP connections at each update of context (UP/DOWN). The web servlet will have then to re-open the connection and will received the UPDATED context list. * Another solution will be having the servlet engine sending a 'Context XXX Down' reply when the user send a request against a DOWN context. The servlet engine could then route the request to another engine (in LB mode), or to indicate the failure (in simple servlet engine mode). And when a context is marked DOWN, we need to know when it's UP again. Brute mode : the web-server continue to forward the requests to the servlet engine, and if it receive the 'Context XXX Down', it try another route. Clean mode : the web-server send a 'Context XXX Status' request, check if the reply is 'Context XXX Up', and if still down, try another route. This mode could be tuned. ie for a down context, ask for status each 10 or 50 requests. The context UP/DOWN is really a rare case, and we mustn't spend to much time in handling this type of event. The protocol must keep its speed. Another feature I'd like to have in mod_jk/jakarta-connector and present in mod_jserv is the backup mode : - In standard mode, a request is routed to only one servlet-engine (using a know worker). - In load balancing mode, a request is sent to a pool of servlet-engine, using a load factor. - We miss a backup mode, where all requests goes allways to the same servlet engine until the connection is broken (maybe the remote engine is down or network link closed). We define then one (or more) alternate engines to handle requests. In that mode, the web-servlet will try to detect later if the principal servlet engine is up each N requests (or after M seconds...) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 Proposal for Apache JServ 1.4 - Second Pass This document is a proposal of evolution of the current Apache JServ Protocol version 1.3, also known as ajp13. I'll not cover here the full protocol but only the add-on from ajp13. This second pass include comments from the tomca-dev list Missing features in AJP13 - ajp13 is a good protocol to link a servlet engine like tomcat to a web server like Apache: * use persistants connections to avoid reconnect time at each request * encode many http commands to reduce stream size * send to servlet engine many info from web server (like SSL certs) But ajp13 lacks support for : * security between web server and servlet engine. Anybody can connect to an ajp13 port (no login mecanism used) You could connect, for example with telnet, and keep the remote thread up by not sending any data (no timeout in connection) * context information passed from servlet engine to web server. Part of the configuration of mod_jk, the web server connector, is to indicate to the web server which URI to handle. The mod_jk JkMount directive, told to web server which URI must be forwarded to servlet engine. A servlet engine allready knows which URI it handle and TC 3.3 is allready capable to generate a config file for mod_jk from the list of available contexts. * state update of contexts from servlet engine to web server. Big site with farm of Tomcat, like ISP and virtuals hosters, may need to stop a context for admin purposes. In that case the front web server must know that the context is currently down, to eventually relay the request to another Tomcat * verify state of connection before sending request. Actually mod_jk send the request to the servlet engine and next wait for the answer. But one of the beauty of the socket AP
RE: New CVS Repositories
>Fixed ... my default group for CVS commits seems to be "apcvs", and it >needed to be "jakarta". the cvs still couldn't be accessed in anonymous mode : cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout jakarta-tomcat-jasper cvs server: cannot find module `jakarta-tomcat-jasper' - ignored cvs [checkout aborted]: cannot expand modules
RE: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
The evolution will goes in jakarta-tomcat-connectors to avoid disturbing mod_jk/ajp13 in the to be released TC 3.3. Of course all bugs fixes from TC 3.3 mod_jk will be back ported to jakarta-tomcat-connectors. The auto-update will not be my premium priority and I think to delay it since it will add too much complexity for a first try. On the native part, I'll need help for autoconf stuff and the JServ like JVM start. Jon could you help us here since you were on it on JServ ? I'd like to see someone take a look at APR, and how we could use it. May be by adding some wrapper code to avoid having #ifde USE_APR sprayed in all mod_jk. Volunteers ? On the C side code, all help will be welcome. I'm confident with the code but all help is also welcome (toc toc toc Dan). May be via review of the regular code commit. I'm pleased to see the proposal was actively discussed and since many users ask about integration of mod_jk and mod_webapp, I reiterate here my invitation to Pier. >I'll try to implement the Java side as you go with the C changes, >unless someone else volunteers ( jasper is taking more than >I expected, and xalan has a release planned in few weeks ). May be Kevin could help also and could commit it's AJP13 in jakarta-tomcat-connector. >BTW, we'll need to discuss about the Java side - so >optimizations on the "lower" level would work on any container. > > >At minimum we need MessageBytes or equivalent, MimeHeaders or >equivalent >( i.e. recyclable, low overhead, etc ), and a simple Request >object that >can be easily adapted to TC3.3 and TC4.0. AJP14 will be only available to TC 3.3/4.0 since the 3.2 is closed to new features. But did the AJP12/AJP13 in jakarta-tomcat-connectors will contains code for tomcat 3.2 tree also ? >This is not the "easiest" solution - from my point of view the easisest >would be to just write the Ajp14Interceptor and use the existing and >optimized 3.3 infrastructure. ( and use a reimplementation of >the protocol for 4.0 - using their low-level objects ).
RE: New CVS Repositories
>You have an account on apache.org, fix it yourself... > >ln -s /home/cvs/jakarta-tomcat-jasper >/home/cvspublic/jakarta-tomcat-jasper Thanks Jon
RE: cvs commit: jakarta-tomcat-connectors/src - New directory
+1 let's do src/native, src/java :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Remy Maucherat [mailto:[EMAIL PROTECTED]] >Sent: Friday, May 11, 2001 4:36 AM >To: [EMAIL PROTECTED] >Subject: Re: cvs commit: jakarta-tomcat-connectors/src - New directory > > >> seguin 01/05/10 17:36:37 >> >> jakarta-tomcat-connectors/src - New directory > >I don't agree with that directory structure. > >I think it should be : >[subproject]/src/java > >Remy >
[PROPOSAL] jakarta-tomcat-connectors renaming
I'd like to rename the mod_jk and jk_ stuff to mod_jtc (jtc_) to let users have at the same time the actual mod_jk and the in dev mod_jtc. Are you agree ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [PROPOSAL] jakarta-tomcat-connectors renaming
>actually, i think i might prefer something like mod_ajp and ajp_. if >jtc means jakarta-tomcat-connector, that might be a little too >generic. >what do you call the next connector protocal? and ajp = Apache Jakarta Protocol (which not much clear) somebody an idea for the name ? > >kevin seguin wrote: >> >> +1. >> >> GOMEZ Henri wrote: >> > >> > I'd like to rename the mod_jk and jk_ stuff to >> > mod_jtc (jtc_) to let users have at the same >> > time the actual mod_jk and the in dev mod_jtc. >> > >> > Are you agree ? >> > >> > - >> > Henri Gomez ___[_] >> > EMAIL : [EMAIL PROTECTED](. .) >> > PGP KEY : 697ECEDD...oOOo..(_)..oOOo... >> > PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >
RE: [PROPOSAL] jakarta-tomcat-connectors renaming
>> >actually, i think i might prefer something like mod_ajp and >ajp_. if >> >jtc means jakarta-tomcat-connector, that might be a little too >> >generic. >> >what do you call the next connector protocal? >> >> and ajp = Apache Jakarta Protocol (which not much clear) >> > >so, do you envision one native library and one set of connectors (for >apache, iis, etc.) that support all connector protocols? if so, then >mod_jtc and jtc_ make more sense to me. The original goal is to provide support for Apache1.3/2.0/IIS/NES/JNI using for example ajp12/ajp13/ajp14. But there is also a JNI mode used for example by IBM to link their apache to their websphere. jtc seems less related to just ajp
RE: [PATCH] LDAPRealm implementation
I'll thanks you for porting the LDAPRealm implementation to the TC 3.3 tree !) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Ellen Lockhart [mailto:[EMAIL PROTECTED]] >Sent: Friday, May 11, 2001 3:45 PM >To: [EMAIL PROTECTED] >Subject: Re: [PATCH] LDAPRealm implementation > > >I apologize if my submission of an LDAPRealm implementation appeared >presumptuous - at the time that I needed it, all I could find >were emails >from other people asking if there was one (upon doing web >searches.) So >after writing it and testing it out and getting the >documentation clear, I >volunteered it for tomcat, since it was something that a lot >of other people >could use too. Apparently some discussion has already gone on about an >implementation of this, as I found it later when I had some >more time to >review the archives, and the tomcat 4 b4 release now has an >implementation >:-). > >The jakarta website encourages people to get involved; I am a little >disappointed to not receive at least a "thanks but no thanks" >response. But >I am glad that there is now a realm implementation that will >work with LDAP >for tomcat. > > >
RE: [PATCH] LDAPRealm implementation
>Yes, you are right, porting JNDIRealm from TC4.0, shouldn't be a >difficult task.. and is the easy, lazy and right thing :). > >In fact i think it's possible to abstract the realm implementation from >the container details, as the ongoing effort on jasper for example.. >this would be a Good Thing (tm), to have a common realms codebase for >all Tomcat trees.. +1 Each contribution is fine, and if you could do JNDIRealm port to 3.3 it will be greatly appreciated by all of us. Thanks > >Saludos , >Ignacio J. Ortega > > >> -Mensaje original- >> De: Ellen Lockhart [mailto:[EMAIL PROTECTED]] >> Enviado el: viernes 11 de mayo de 2001 16:04 >> Para: [EMAIL PROTECTED] >> Asunto: Re: [PATCH] LDAPRealm implementation >> >> >> I actually ported this one from a 3.2.1 implementation I did, >> with a few >> changes. But since there is now a JNDIRealm implementation, >> wouldn't it be >> preferred to have a counterpart to that one on the TC 3.3 >> tree (same setup, >> etc.)? >> >> >> >> - Original Message - >> From: "GOMEZ Henri" <[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED]> >> Sent: Friday, May 11, 2001 6:52 AM >> Subject: RE: [PATCH] LDAPRealm implementation >> >> >> > I'll thanks you for porting the LDAPRealm implementation >> > to the TC 3.3 tree !) >> > >> > - >> > Henri Gomez ___[_] >> > EMAIL : [EMAIL PROTECTED](. .) >> > PGP KEY : 697ECEDD...oOOo..(_)..oOOo... >> > PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >> > >> > >> > >> > >-Original Message- >> > >From: Ellen Lockhart [mailto:[EMAIL PROTECTED]] >> > >Sent: Friday, May 11, 2001 3:45 PM >> > >To: [EMAIL PROTECTED] >> > >Subject: Re: [PATCH] LDAPRealm implementation >> > > >> > > >> > >I apologize if my submission of an LDAPRealm >> implementation appeared >> > >presumptuous - at the time that I needed it, all I could find >> > >were emails >> > >from other people asking if there was one (upon doing web >> > >searches.) So >> > >after writing it and testing it out and getting the >> > >documentation clear, I >> > >volunteered it for tomcat, since it was something that a lot >> > >of other people >> > >could use too. Apparently some discussion has already >> gone on about an >> > >implementation of this, as I found it later when I had some >> > >more time to >> > >review the archives, and the tomcat 4 b4 release now has an >> > >implementation >> > >:-). >> > > >> > >The jakarta website encourages people to get involved; I >> am a little >> > >disappointed to not receive at least a "thanks but no thanks" >> > >response. But >> > >I am glad that there is now a realm implementation that will >> > >work with LDAP >> > >for tomcat. >> > > >> > > >> > > >> >> >
RE: ajp13 and tomcat 4
> >javac --classpath /tomcat_path/.../catalina.jar *.java >jar cf Ajp13.jar *.class > >> >> any thoughts on the directory structure in jakarta-tomcat-connector? >> i'm assuming there's going to be common ajpxx code, then >> ajpxx-servletcontainer-connector code, then common util code (i.e. >> MessageBytes, OutputBuffer), etc.. any ideas on how this will all be >> segmented out? > >like jakarta-tomcat-connectors/mod_jk/java/org/apache.../ajp13/*.java >jakarta-tomcat-connectors/mod_jk/java/org/apache.../ajpcommon/*.java >jakarta-tomcat-connectors/mod_jk/java/org/apache.../connectors/*.java >jakarta-tomcat-connectors/mod_jk/apache-1.3 for apache-1.3 and so on? > > >Should we really use Ant? To build the C files on many >platforms we will >need configure, why not doing like JServ in the past? - A >configure that >asks or guesses the Webserver location, Tomcat location and java path - The project will be in two parts, java and native. I'd like to see ant used for the java part and configure for the native. native hackers know about configure and libtool. java developpers start to learn using ant. Just to help each community find its mark. JF would you like doing the autoconf stuff for the native part ? The source is : jakarta-tomcat-connectors/src/java/ jakarta-tomcat-connectors/src/native/... In my idea native is just mod_jtc, which replace mod_jk. We have only connector projects here for now, mod_jtc (mod_jk)
RE: [PROPOSAL] jakarta-tomcat-connectors renaming
>GOMEZ Henri wrote: >> >> >> >actually, i think i might prefer something like mod_ajp and >> >ajp_. if >> >> >jtc means jakarta-tomcat-connector, that might be a little too >> >> >generic. >> >> >what do you call the next connector protocal? >> >> >> >> and ajp = Apache Jakarta Protocol (which not much clear) >> >> >> > >> >so, do you envision one native library and one set of >connectors (for >> >apache, iis, etc.) that support all connector protocols? >if so, then >> >mod_jtc and jtc_ make more sense to me. >> >> The original goal is to provide support for Apache1.3/2.0/IIS/NES/JNI >> using for example ajp12/ajp13/ajp14. But there is also a JNI mode >> used for example by IBM to link their apache to their websphere. >> >> jtc seems less related to just ajp > >somebody mentioned the directory structure should look something like >this: > >[sub-project]/src/java > >what would examples of subprojects be under jakarta-tomcat-connectors? >jtc? mod_jtc? ajp? i guess i've gotten a little confused here jakarta-tomcat-connectors is a 'subproject' We could find there under jakarta-tomcat-connectors : src/java/jakarta-tomcat-3.2/ src/java/jakarta-tomcat-3.3/ src/java/jakarta-tomcat-4.0/ src/java/jakarta-tomcat-commons/ jakarta-tomcat-connectors/src/native/apache1.3/ jakarta-tomcat-connectors/src/native/apache2.0/ jakarta-tomcat-connectors/src/native/common/ jakarta-tomcat-connectors/src/native/iis/ jakarta-tomcat-connectors/src/native/jni/ jakarta-tomcat-connectors/src/native/netscape/ jakarta-tomcat-connectors/src/native/nt_service/ jakarta-tomcat-connectors/src/native/khttp/
RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
Now Tomcat 3.2.2 does DNS lookup. I'll send update to 3.3 to do that today :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Friday, May 11, 2001 10:23 PM >To: [EMAIL PROTECTED] >Subject: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3 > > >larryi 01/05/11 13:22:59 > > Modified:.RELEASE-PLAN-3.3 > Log: > Update release plan. Issues and priorities aren't final and >will be updated > as needed. > > Revision ChangesPath > 1.9 +68 -10jakarta-tomcat/RELEASE-PLAN-3.3 > > Index: RELEASE-PLAN-3.3 > === > RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v > retrieving revision 1.8 > retrieving revision 1.9 > diff -u -r1.8 -r1.9 > --- RELEASE-PLAN-3.3 2001/01/31 01:55:38 1.8 > +++ RELEASE-PLAN-3.3 2001/05/11 20:22:52 1.9 > @@ -68,11 +68,23 @@ > Should that not be the case, this release may be >skipped since the > beta release is expected a week later. > > -Tomcat 3.3 Beta: > +Tomcat 3.3 Milestone 3 Release: > > -Code Freeze/Tag Date: March 15, 2001 > +Code Freeze/Tag Date: May 12, 2001 > Release Manager:Larry Isaacs > > + Known issues in order of priority > + > + 1. getRequestURI() should return an encoded string (if >feasible) > + 2. Update build process to create archives and >internal directory > +structure consistent with other Jakarta projects, i.e. use > +jakarta-tomcat-3.3-xxx. > + > +Tomcat 3.3 Beta 1: > + > +Code Freeze/Tag Date: March 26, 2001 > +Release Manager:Larry Isaacs > + >No major change will be done after the Beta is build without a >vote. The release team can reject any change they feel >is too big >and can introduce regressions, or is not needed. > @@ -82,22 +94,68 @@ > >During the beta period we will fix all remaining bugs >and run the manual >tests for the bugs that have no automated test case. > + > + Known issues in order of priority: > + 1. Port all missing updates to Jasper from Tomcat >3.2.2 and verify that > +all Jasper theading issues are dealt with. This >includes Bugzilla > +Bugs 80,140,1039,1123,1280,1646 > + 2. Check HttpSessionFacade for spec compliance. > +Know problems: > +A. setAttribute() calls valueBound() after storing the > + object in the session. The spec calls for the reverse. > +B. setAttribute() doesn't call valueUnbound() for the > + object it replaces, if present. > + 3. Session recyling includes keeping the >HttpSessionFacade. I believe > +this represents a security risk. May need to >discard session > +facades, or at least discard them for untrusted web >applications. > + 4. Update getRemoteHost() to be consistent with Tomcat >3.2.2, if > +appropriate. In Tomcat 3.2.2, it no longer does a >reverse DNS > +lookup. > + 5. Verify no reqressions. > + 6. TBD... > + > > -Tomcat 3.3 Addition Betas: > +Tomcat 3.3 Beta 2: > > -Code Freeze/Tag Date: Weekly from March 15, 2001 > +Code Freeze/Tag Date: June 2, 2001 > Release Manager:Larry Isaacs > - > -After the first beta, we will periodically build beta >releases in > -order to track the evolution. > > + This release should fix any major bugs found in the > + prior beta and any missed regressions. > + > + Known issues in order of priority: > + 1. TBD... > + > + > Tomcat 3.3 Final Release > > -Code Freeze Date: Apr 5, 2001 > +Code Freeze Date: June 9, 2001 > Release Manager:Larry Isaacs > + > + The final build. The pre-requisite for the release is >having no bugs in > + the test suite, resolution for all known bugs and >approval by the community. > + > + Known issues in order of priority: > + 1. Update/fix documentation as much as possible > + > + > +Bugs That Won't Be Fixed In Tomcat 3.3 > > -The final build. The pre-requisite for the release is >having no bugs in > -the test suite, resolution for all known bugs and >approval by the community. > +The following Bugzilla Bugs are known issues that are not >planned to be > +addressed in Tomcat 3.3. > + > +Bug #75: Translation time attribute evaluation not provided to > + TagExtraInfo class > +Bug #143: Tag handlers with properties of type "Object" > +Bug #155: Quick Blurb saying "Everything is initialized" > +Bug #164: IIS Logging > +Bug #203: `tomcat.sh env` ruins the shell if >$TOMCAT_HOME is not set
