Re: [OT] Issue with cgi/perl webpage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Felipe, On 11/22/13, 10:29 AM, Felipe wrote: Interesting, so do container-based systems such as Tomcat rely heavely on httpd? No, but it's quite common to see httpd used to front a Tomcat-based application. This is a good strategy when you need complicated deployments with different JVMs running different applications (or maybe just multiple JVMs running the same application, for fail-over and load-balancing). I've read that many people use Tomcat just for webapp deployment and use apache to handle static pages, among other things, but is it reasonable to use Tomcat to handle static pages, or is it solely for webapp server? Tomcat does a great job as a static web server, but to get better performance from the default you should: 1. Enable APR (connectors will auto-detect and use) if you use HTTPS or 2. Switch to the NIO connector if you don't use HTTPS APR's OpenSSL-based TLS implementation turns out to be faster than other combinations of code. NIO and APR are about evenly-matched when it comes to throughput and scalability, though I would bet on NIO all other things being equal. I'm actually interested in using Tomcat for a personal project. It is using an Arduino Uno microcontroller (an AVR microcoontroller, specifically Atmel's ATMEGA 328), I would like to use the arduino as a server that could handle requests by way of a web interface control panel. I think this is would be an appropiate scenario to use JSP and Tomcat. A JVM will not likely be a great choice on that platform. Modest processor and low memory? Sounds like a disaster for a server-quality JVM. You could look at an embedded JVM, but running Tomcat on top of that isn't likely to pay off. Initially I would create a simple webapp that has prompt (where a user can input a command that the arduino will then act on) and display analog reading's (so as to monitor). This kind of thing can be done with a simple Bash script, and use a lot less memory. Be aware that what you are doing is (intentionally) opening a huge security hole in your setup. I'm just no sure how to go about hosting tomcat, I'm pretty sure it is not possible to run on the arduino, but maybe using port forwarding or web socket to have Tomcat on a laptop or maybe a rasberry pi. Would this be a feasible method? Probably not. If you were going to do all that, what's the point in running Tomcat at all? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSk1pJAAoJEBzwKT+lPKRYUXgP/3e4+xfJIAieTw8U9ohtvLfZ Jjl65dwjlhCRH26imhqIK9MK3w9ox+odGpjSlMM+cUPYgiIGZhxbFtUvLOigdkW4 0ENutvSzXg/mLdrDVM035IjRJMSXyIjk4Av2Wc+kJOeSyNEKREClN9Kgjojx2y44 8GoaoZCNhXgI76JfqBIgwidxrLhECS7Y5UIWzuDI0bsW0x6r1B5VhZdQBnpp2t9g 6Eb3BmfA8fE4hZYjkimKEvPCdryB/+lFuDgf5dBMIUVAemMK1fl+yn4hCaL9MKbY DJnJeEM7Keu9KaYY4hQxQg9do/y7CNWMTqIfpB0/L2fYEu4HriNItQm0sATJ8XYB Kjkd7TP0NU1lyhQLI7ikbkDDA/48oYBS0GkvN3F1TNYENyRuNW9fzUNMEPp6cXvd HH5vPGn4NerJpdXq5wV6m0zVXCuOyl9uUDuP0LRHzx9fkA991RcxYqR4m21kHugD Qi31kvw3klUJfPls7oRAY0LQJ2E3+sjGbtPccvCo4reQoxh1w7BcRxRKxwh63nKE Cb4ITADi3qITfPRmRIHUVlDk/YD5/c2jZXxWU8Ecw4UwD9Aa9PsYzjwD2hkPBgGx mvcTA4q0Lep8MZg+Il2/2sN0wAvMBRY8eu6fkDpFMrkDzEkYEa8jbx0znQYDeJBx 7CmJMGl2LBOcIJu1s55h =vBKG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Issue with cgi/perl webpage
Felipe wrote: Interesting, so do container-based systems such as Tomcat rely heavely on httpd? Not necessarily. Read on. I've read that many people use Tomcat just for webapp deployment and use apache to handle static pages, among other things, but is it reasonable to use Tomcat to handle static pages, or is it solely for webapp server? By design, Tomcat is primarily a java servlet container, meaning that its primary design goal is to provide an environment to run java servlets efficiently. But it is rarely so that applications would consist only of java servlets, so there exists also within Tomcat a default servlet, which is invoked by Tomcat to serve any request which cannot clearly be assigned to any other servlet, and which consequently does serves most static content (html pages, stylesheets, images, ..). And it just so happens that this default servlet is very efficient too, so that in the end Tomcat can perfectly be used as a generic webserver to serve both static content, along with the results of servlets execution. There also exists a cgi-bin servlet which can run cgi-bin scripts and programs. But this cgi-bin servlet is not really optimised for any particular kind of cgi-bin programs/scripts, and that is where other webservers may beat tomcat in terms of efficiency. For example, if you are talking about cgi-bin scripts written in Perl or PHP : there exist special add-on modules for the Apache httpd webserver, which can optimise the running of scripts written in such languages (usually by pre-compiling them and keeping the compiled version in some cache memory)(*). Such add-on modules do not exist for tomcat, and thus if a main part of an application would consist of such scripts, it would be more efficient in an overall sense to use a front-end webserver like Apache httpd, to run these parts of the application, and then have Apache httpd delegate to a tomcat back-end what is destined for java servlets. When you reflect about this, it is exactly the same in reverse : Apache httpd could also run cgi-bin scripts written in Java. It would just have to start a JVM at each invocation, to compile and run the java script. Of course, that would be very inefficient, which is why for running java servlets it is better to use tomcat (or another java servlet container). There is nothing /in the principle/ that would prevent someone from writing a special java perl cgi-bin servlet for tomcat, which would duplicate the functionality of some of what the mod_perl module does for Apache httpd, and make it very efficient to run perl cgi-bin scripts under tomcat (**). It just hasn't been done yet, the main reason being probably : why do it ? (when it is easy to configure Apache httpd as a front-end to tomcat, and do it there using mod_perl). (*) See http://perl.apache.org (**) and similarly, one could think about a mod_java add-on module for Apache httpd - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Issue with cgi/perl webpage
Interesting, so do container-based systems such as Tomcat rely heavely on httpd? I've read that many people use Tomcat just for webapp deployment and use apache to handle static pages, among other things, but is it reasonable to use Tomcat to handle static pages, or is it solely for webapp server? Thanks Neven, I was able to get the cgi script working, I'm in the process of dissecting and writing the steps to have tomcat host the cgi-script for my professor, we talked and he saw that apache was what was meant to be used but he encouraged my efforts in using Tomcat instead. Even if it isn't the logical way to the exercise. There's a possibility that they might use the this as an example of Tomcat's cgi support. I'm actually interested in using Tomcat for a personal project. It is using an Arduino Uno microcontroller (an AVR microcoontroller, specifically Atmel's ATMEGA 328), I would like to use the arduino as a server that could handle requests by way of a web interface control panel. I think this is would be an appropiate scenario to use JSP and Tomcat. Initially I would create a simple webapp that has prompt (where a user can input a command that the arduino will then act on) and display analog reading's (so as to monitor). I'm just no sure how to go about hosting tomcat, I'm pretty sure it is not possible to run on the arduino, but maybe using port forwarding or web socket to have Tomcat on a laptop or maybe a rasberry pi. Would this be a feasible method? On Thu, Nov 21, 2013 at 8:36 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Neven, On 11/20/13, 11:48 AM, Neven Cvetkovic wrote: Ultimately, CGI is a very old technology that had its own share of performance (and security) problems. Usually, CGI scripts were replaced with superior Java Servlet technology (or some other better technology) and hence the need for Tomcat application server (servlet container). Hopefully, the rest of the mailing list members share my sentiments about the CGI :) - -0 The only thing that really makes CGI outdated is that CGI itself didn't have an API... or if you could call it an API, it was very basic. It basically said you get the query string in a big blob and you can read standard input if you want to get the entity body. Then everyone set to work writing their own custom parsing routines. I remember copy/pasting stuff in Perl way back in 1994 and now having any idea what the code actually did. These days, you can pretty much write a Perl script and say use CGI; and it's just magic, safe, etc. CGI has come a long way. The last remaining problem is really that of performance: the CGI model launches a new process for each request (even though you can cheat a bit using things like mod_perl, etc.) and so there is a performance hit right there. If you want to keep information between requests, you have no choice but to write it to some form of non-volatile storage (as far as the application is concerned). RDBMS, flat file, etc. More recent systems (I hesitate to say modern because it implies that they are better simply because they are newer, and that the older methodologies are simply worse by definition) are supported by much more complicated software, APIs, etc. Note that container-based systems like Tomcat have their own performance problems: they have to manage all the stuff that they are ... well, required to support. If you peel-away all of the stuff that Apache httpd provides *aside* from the Common Gateway Interface, you are left with a server that primarily pumps bytes back and forth between the client and the script. Tomcat has all kinds of moving parts that make it possible to do nice things, but those moving parts have a cost. (It's worth noting that I believe such costs are worth it. That's why I live in the container-based world instead of writing Perl- or PHP-based applications.) Want to deploy a single Hello, World! CGI script? No problem. Just drop #!/bin/sh\n\necho Hello, World! into a .cgi file in your document root and tell Apache httpd it's okay to run it. Want to deploy a single Hello, World! script on Tomcat? Well, first you have to know where the auto-deployment directory is (hint: it's not a document root), and then you have to create a directory in there, and then drop a .jsp file in there. The good news is that Hello, World! is a valid JSP file without any of the fluff you need to make a shell script run. But the small amount of orientation required just to get the point of dropping text into a file can be confusing. Once the almighty container is involved, there is pressure to make it do more things. Sessions. Replication. Websockets. These are all very good and very useful things, but it further complicates the scenario. It's just a tough world to jump into with little to no planning. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (Darwin)
Re: [OT] Issue with cgi/perl webpage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Neven, On 11/20/13, 11:48 AM, Neven Cvetkovic wrote: Ultimately, CGI is a very old technology that had its own share of performance (and security) problems. Usually, CGI scripts were replaced with superior Java Servlet technology (or some other better technology) and hence the need for Tomcat application server (servlet container). Hopefully, the rest of the mailing list members share my sentiments about the CGI :) - -0 The only thing that really makes CGI outdated is that CGI itself didn't have an API... or if you could call it an API, it was very basic. It basically said you get the query string in a big blob and you can read standard input if you want to get the entity body. Then everyone set to work writing their own custom parsing routines. I remember copy/pasting stuff in Perl way back in 1994 and now having any idea what the code actually did. These days, you can pretty much write a Perl script and say use CGI; and it's just magic, safe, etc. CGI has come a long way. The last remaining problem is really that of performance: the CGI model launches a new process for each request (even though you can cheat a bit using things like mod_perl, etc.) and so there is a performance hit right there. If you want to keep information between requests, you have no choice but to write it to some form of non-volatile storage (as far as the application is concerned). RDBMS, flat file, etc. More recent systems (I hesitate to say modern because it implies that they are better simply because they are newer, and that the older methodologies are simply worse by definition) are supported by much more complicated software, APIs, etc. Note that container-based systems like Tomcat have their own performance problems: they have to manage all the stuff that they are ... well, required to support. If you peel-away all of the stuff that Apache httpd provides *aside* from the Common Gateway Interface, you are left with a server that primarily pumps bytes back and forth between the client and the script. Tomcat has all kinds of moving parts that make it possible to do nice things, but those moving parts have a cost. (It's worth noting that I believe such costs are worth it. That's why I live in the container-based world instead of writing Perl- or PHP-based applications.) Want to deploy a single Hello, World! CGI script? No problem. Just drop #!/bin/sh\n\necho Hello, World! into a .cgi file in your document root and tell Apache httpd it's okay to run it. Want to deploy a single Hello, World! script on Tomcat? Well, first you have to know where the auto-deployment directory is (hint: it's not a document root), and then you have to create a directory in there, and then drop a .jsp file in there. The good news is that Hello, World! is a valid JSP file without any of the fluff you need to make a shell script run. But the small amount of orientation required just to get the point of dropping text into a file can be confusing. Once the almighty container is involved, there is pressure to make it do more things. Sessions. Replication. Websockets. These are all very good and very useful things, but it further complicates the scenario. It's just a tough world to jump into with little to no planning. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSjrUUAAoJEBzwKT+lPKRYdcsQAIWqzHUbSimrUmXcYw9KH0zs fkZCQvi3Hqon1afyun6fU+NT8Ta0YkOYKW8gEiWvrogcZtMl1Q/oxOKSWZvPG8g1 8nPyDbACRL2715VUKuWgCTfABuQnHYOjFuakqAfZsXcVigxfpwWyw8eS7KfwpaDv vr/ZwqDv2ThQs63rk2rO5HW9o65nk2+XX4RBaUAw6lRZ7AfKMH5upR5Qwe231aKR DBF6GsuoWGeyONPXyGGIcrjLeizg1pOf1m0W3cTTIgI6UBNFUez+hZHGpFxbkrNE FX3onEVfrjlaxfSFmDx4ytDyOo973fhMALrasvIUSPqdKhjvIFHTYarZHRrOxex1 /L+YWnth7xAWTHPz+SzM7YWzRTDfWeOMq9PCx8wdoV88BJ35tQerxowdvbo+fPJN S+Y+zw2iZwlyN8bVfwVpG81my8SEtFgrxhyPZMTqDK8RppL1QlC+aemQHiafTwoH 78+JP1HRR/tgYM9WXsDmOhIFgZp2pjATvuklqc5gw7BWX6J9UF8LjqEAmgwj5/KI JlcMgCLH91WvjU/7p0jFnTMGHalL8Bz4L4KFp9OwA4gwkvjZQF1q1MbEGU/GVHP+ z2hJHeC4ugXk9zzO9imlUMZhC/pNGkwc/5leSMaHhwd0uZMatKh3sM4LLmoptiDP 0/kSWWI/zKK0USODk240 =21G3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org