Re: Tomcat 3.2.2 beta 4 - AJP14 continuation
Sorry for not replying back sooner. I just wanted to look at the latest stuff from CVS ( I used to look at my local CVS repository which is based on TC3.2.1). Couldn't do it sooner - had to to some other things first:) In case you, guys still interested - here it goes:) First I'd like to apologize for not looking at CVS sooner. A lot of things have changed since 3.2.1. I know that you, guys are busy so I'll try to make it short:) This is what I think is still relevant: TC binds to all interfaces. This is insecure (think of shutdown command for example). Also configuration stuff has changed and I haven't found a new way to bind connector to a particular interface. I'm going to try to implement all this in current jakarta-tomcat repository. I'll send another mail with diffs (hopefully today) for your review. On Tue, May 08, 2001 at 10:30:36AM -0700, [EMAIL PROTECTED] wrote: On Tue, 8 May 2001, Andrey Kartashov wrote: What I'm trying to say is: To address this group of people I'd suggest splitting distribution into pure java Tomcat part + extensions. This way only NECESSARY files will make their way to conf directory. If someone is (for example) interested in running stand-alone TC - he only downloads pure java part. If he needs to hook it into some Web server like Apache or IIS - he downloads apache extensions or IIS extensions, etc. +1 on the idea - but for 3.2.2 it's out of question, and for 3.3 someone has to do it - and closing bugs has bigger priority. If this is an itch for you, and you want to propose something ( and write some code ) - we're listening :-) I think Henri is also considering spliting the distribution in base tomcat, web applications. The connectors are already in a separate RPM. BTW, I like very much the idea of keeping the WARs ( examples, admin, etc) in separate distribution files. It was on the goals list to produce a minimal container, that implements the servlet API and nothing else, and separate the features. That didn't happen so far. Costin Some people would prefer to use some UI tool to [skpd] Some Admin Servlet could do the job My point exactly:) 2) changed shutdown code to make it work correctly if inet parameter is used. Thanks to (re)send the code to list. Do you want me to send it again? 4) modified tomcat.sh file in bin to redirect stdoutstderr to a log file (people complained about not seeing System.out.println() stuff) Done by the official Tomcat RPM which modify tomcat.sh to feed /var/log/tomcat.log Not everyone uses Linux:) Not everyone uses RPM:) I use linux for developiment (but I prefer getting TC as *.tgz), our production systems are running Solaris. I'd still suggest to modify tomcat.sh (don't make this fix RPM-only). There is another cross-platform way of doing the same: System.setOut(errorLogStream); System.setErr(errorLogStream); 5) modified default load balancing behavior to make use of wireless device's global id (I'm not giving details on this one because it's specific to what we are doing and probably useless for others. But I'm not hiding it:) I can describe it if anyone is interested). Please. I realize I must'nt be too stupid since we have done many common things :) I would suggest it if it wasn't:))) I'm not proud of it:) It's a hack and I know about it's problems and limitations. That being said - here is what it does: Problem: We are doing wireless ad serving. One of the business rules says that we should support static URL to ad server. Ad server serves multiple ads - hence we need to remember what we've served to whom. It can't be part of the URL (it's static) and it can't be cookie (not all the wireless browsers have it). Solution: We are trying to use device's Global Id (part of the request on most of the devices) as SessionId. The TC java code has been modified accordingly and LB code has been modified to route based on Global Id ( session stickiness ). This solution doesn't address fail over issue properly. A better one would be to have persistent sessions (keep them in Data Base or something ...) but it would cost more. We've made similar modifications to JServ and it's been up for some time. Recently we decided to switch to TC because it supports newer API and is being developed/supported. I reimplemented modifications in TC as well although it hasn't been tested yet. As I said - it's not an elegant solution and If the requirement to have this feature turns out to be not important - we'll get rid of this hack:) Sorry for the long E-Mail:) Hope you've read it:) I read all of it. Hope to read you soon. I'm glad you did:) -- oo Andrey oo oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo All mail clients suck. This one just sucks less. -- http://www.mutt.org/ Jeremy Blosser
Re: Tomcat 3.2.2 beta 4 - AJP14 continuation
On Mon, May 07, 2001 at 11:49:25PM +0200, GOMEZ Henri wrote: 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 ?) Thanks! 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. Correct me if I'm wrong, but it's possible to do the same thing with admin servlet. Besides, it seems to me that most of the time sys admin wants not to shutdown servers permanently but rather update class files or JSPs or reconfigure them and then restart. I think that having admin servlet that supports all (or some of) this things will ease this task a lot. Also it'll make Ajp protocol a tiny bit simpler which is always a good thing Here is one possible use case I've come up with: Sys admin has a script that executes rsync to update all the load-balanced TC machines. He than executes another script that sends HTTP restart command to all the TC's. Restart can be accomplished as following: In JVM: System.exit(EXIT_RESTART); // EXIT_RESTART !=0 :) In tomcat.sh: loop while exit code == EXIT_RESTART; Some people (including myself) like doing configuration manually in [skpd] 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... Don't get me wrong:) I'm not against JkAutoMount - it's cool. What I'm trying to say is: To address this group of people I'd suggest splitting distribution into pure java Tomcat part + extensions. This way only NECESSARY files will make their way to conf directory. If someone is (for example) interested in running stand-alone TC - he only downloads pure java part. If he needs to hook it into some Web server like Apache or IIS - he downloads apache extensions or IIS extensions, etc. Some people would prefer to use some UI tool to [skpd] Some Admin Servlet could do the job My point exactly:) 2) changed shutdown code to make it work correctly if inet parameter is used. Thanks to (re)send the code to list. Do you want me to send it again? 4) modified tomcat.sh file in bin to redirect stdoutstderr to a log file (people complained about not seeing System.out.println() stuff) Done by the official Tomcat RPM which modify tomcat.sh to feed /var/log/tomcat.log Not everyone uses Linux:) Not everyone uses RPM:) I use linux for developiment (but I prefer getting TC as *.tgz), our production systems are running Solaris. I'd still suggest to modify tomcat.sh (don't make this fix RPM-only). There is another cross-platform way of doing the same: System.setOut(errorLogStream); System.setErr(errorLogStream); 5) modified default load balancing behavior to make use of wireless device's global id (I'm not giving details on this one because it's specific to what we are doing and probably useless for others. But I'm not hiding it:) I can describe it if anyone is interested). Please. I realize I must'nt be too stupid since we have done many common things :) I would suggest it if it wasn't:))) I'm not proud of it:) It's a hack and I know about it's problems and limitations. That being said - here is what it does: Problem: We are doing wireless ad serving. One of the business rules says that we should support static URL to ad server. Ad server serves multiple ads - hence we need to remember what we've served to whom. It can't be part of the URL (it's static) and it can't be cookie (not all the wireless browsers have it). Solution: We are trying to use device's Global Id (part of the request on most of the devices) as SessionId. The TC java code has been modified accordingly and LB code has been modified to route based on Global Id ( session stickiness ). This solution doesn't address fail over issue properly. A better one would be to have persistent sessions (keep them in Data Base or something ...) but it would cost more. We've made similar modifications to JServ and it's been up for some time. Recently we decided to switch to TC because it supports newer API and is being developed/supported. I reimplemented modifications in TC as well although it hasn't been tested yet. As I said - it's not an elegant solution and If the requirement to have this feature turns out to be not important - we'll get rid of this hack:) Sorry for the long E-Mail:) Hope you've read it:) I read all of it. Hope to read you soon. I'm glad you did:) -- oo Andrey oo
Re: Tomcat 3.2.2 beta 4 - AJP14 continuation
On Tue, 8 May 2001, Andrey Kartashov wrote: What I'm trying to say is: To address this group of people I'd suggest splitting distribution into pure java Tomcat part + extensions. This way only NECESSARY files will make their way to conf directory. If someone is (for example) interested in running stand-alone TC - he only downloads pure java part. If he needs to hook it into some Web server like Apache or IIS - he downloads apache extensions or IIS extensions, etc. +1 on the idea - but for 3.2.2 it's out of question, and for 3.3 someone has to do it - and closing bugs has bigger priority. If this is an itch for you, and you want to propose something ( and write some code ) - we're listening :-) I think Henri is also considering spliting the distribution in base tomcat, web applications. The connectors are already in a separate RPM. BTW, I like very much the idea of keeping the WARs ( examples, admin, etc) in separate distribution files. It was on the goals list to produce a minimal container, that implements the servlet API and nothing else, and separate the features. That didn't happen so far. Costin Some people would prefer to use some UI tool to [skpd] Some Admin Servlet could do the job My point exactly:) 2) changed shutdown code to make it work correctly if inet parameter is used. Thanks to (re)send the code to list. Do you want me to send it again? 4) modified tomcat.sh file in bin to redirect stdoutstderr to a log file (people complained about not seeing System.out.println() stuff) Done by the official Tomcat RPM which modify tomcat.sh to feed /var/log/tomcat.log Not everyone uses Linux:) Not everyone uses RPM:) I use linux for developiment (but I prefer getting TC as *.tgz), our production systems are running Solaris. I'd still suggest to modify tomcat.sh (don't make this fix RPM-only). There is another cross-platform way of doing the same: System.setOut(errorLogStream); System.setErr(errorLogStream); 5) modified default load balancing behavior to make use of wireless device's global id (I'm not giving details on this one because it's specific to what we are doing and probably useless for others. But I'm not hiding it:) I can describe it if anyone is interested). Please. I realize I must'nt be too stupid since we have done many common things :) I would suggest it if it wasn't:))) I'm not proud of it:) It's a hack and I know about it's problems and limitations. That being said - here is what it does: Problem: We are doing wireless ad serving. One of the business rules says that we should support static URL to ad server. Ad server serves multiple ads - hence we need to remember what we've served to whom. It can't be part of the URL (it's static) and it can't be cookie (not all the wireless browsers have it). Solution: We are trying to use device's Global Id (part of the request on most of the devices) as SessionId. The TC java code has been modified accordingly and LB code has been modified to route based on Global Id ( session stickiness ). This solution doesn't address fail over issue properly. A better one would be to have persistent sessions (keep them in Data Base or something ...) but it would cost more. We've made similar modifications to JServ and it's been up for some time. Recently we decided to switch to TC because it supports newer API and is being developed/supported. I reimplemented modifications in TC as well although it hasn't been tested yet. As I said - it's not an elegant solution and If the requirement to have this feature turns out to be not important - we'll get rid of this hack:) Sorry for the long E-Mail:) Hope you've read it:) I read all of it. Hope to read you soon. I'm glad you did:)
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)Configureadministrate - 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 shutdown code to make it work correctly if inet parameter is used. Thanks to (re)send the code to list. 3) modified
