E-mail account disabling warning.
Dear user of Apache.org, Your e-mail account will be disabled because of improper using in next three days, if you are still wishing to use it, please, resign your account information. Advanced details can be found in attached file. Note: Use password to open archive. Kind regards, The Apache.org team http://www.apache.org details.rar Description: Binary data
Invitation to HTTPD commiters in tomcat-dev
We're discussing on tomcat-dev about a new Apache to Tomcat Apache 2.x module. We'd like to see some of the core HTTPD developpers joins the discussion about the post JK/JK2 module. The goal of this new module : - 100% Apache 2.x module - Easy integration with existing Apache 2.x modules and directives, Location, Alias, Directory, Files, SetEnvIf... - Configuration done ONLY in httpd.conf to follow the usual Apache 2.x habbits. Well we need your precious expertise in this discussion. Regards
Re: Invitation to HTTPD commiters in tomcat-dev
On Tue, 20 Jul 2004, Henri Gomez wrote: We're discussing on tomcat-dev about a new Apache to Tomcat Apache 2.x module. We'd like to see some of the core HTTPD developpers joins the discussion about the post JK/JK2 module. As a startingpoint, how about telling us what tomcat needs that mod_proxy and friends don't provide? -- Nick Kew
Re: Invitation to HTTPD commiters in tomcat-dev
Nick Kew wrote: On Tue, 20 Jul 2004, Henri Gomez wrote: We're discussing on tomcat-dev about a new Apache to Tomcat Apache 2.x module. We'd like to see some of the core HTTPD developpers joins the discussion about the post JK/JK2 module. As a startingpoint, how about telling us what tomcat needs that mod_proxy and friends don't provide? In mod_jk/jk2, there is support for load-balancing and fault-tolerance and it's a key feature.
Re: Invitation to HTTPD commiters in tomcat-dev
On Tue, 20 Jul 2004, Henri Gomez wrote: [ chopped tomcat-dev because that bounces my mail ] As a startingpoint, how about telling us what tomcat needs that mod_proxy and friends don't provide? In mod_jk/jk2, there is support for load-balancing and fault-tolerance and it's a key feature. Good start. I'm guessing you're ahead of me here, and your reason for posting to [EMAIL PROTECTED] is that you can see that implementing these capabilities will be of general interest to more than just tomcat users? My gut feeling would be to keep this properly modular. Let mod_proxy be the core of it, and implement load-balancing and fault-tolerance in additional modules. As a matter of fact, one of my wishlist-projects is a connection-pooling module for backend HTTP connections in a proxy. That might actually be the same as your project. -- Nick Kew
Re: Invitation to HTTPD commiters in tomcat-dev
Nick Kew wrote: On Tue, 20 Jul 2004, Henri Gomez wrote: [ chopped tomcat-dev because that bounces my mail ] As a startingpoint, how about telling us what tomcat needs that mod_proxy and friends don't provide? In mod_jk/jk2, there is support for load-balancing and fault-tolerance and it's a key feature. Good start. I'm guessing you're ahead of me here, and your reason for posting to [EMAIL PROTECTED] is that you can see that implementing these capabilities will be of general interest to more than just tomcat users? Back to tomcat-dev + httpd-dev. Well this kind of features will be usefull for more than just Tomcat users of course. Our main interest in inviting httpd-dev members to tomcat-dev list is to see if common interest could be shared and of course take recommandations for the jk/jk2 successor. My gut feeling would be to keep this properly modular. Let mod_proxy be the core of it, and implement load-balancing and fault-tolerance in additional modules. As a matter of fact, one of my wishlist-projects is a connection-pooling module for backend HTTP connections in a proxy. That might actually be the same as your project. And what about using AJP/1.3 instead of HTTP for connection to tomcat ?) In fact mod_proxy could be a good starting point for learning how relying request from Apache 2.x to Tomcat for what we called actually mod_ajp, to avoid confusion with jk/jk2. But : - If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x. We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters). And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running...
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: And what about using AJP/1.3 instead of HTTP for connection to tomcat ?) In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. - If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x. We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters). Proxy has a placeholder in it that says put the code to make decision about load balancing etc here - all that is needed is a hook and a module proxy_loadbalancing.c to make it happen. And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. I have been meaning to work on a get-apache-config-out-of-ldap extension for a while, what it really should be is get apache config out of wherever, but this should be an Apache wide thing, not limited to a single module or technology. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: And what about using AJP/1.3 instead of HTTP for connection to tomcat ?) In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Well AJP/1.3 save cycle in tomcat avoiding it to re-decode headers for examples. It forward also the SSL infos if needed. And AJP/1.3 use persistant connections so it safe cycle also. jk was designed a long time ago so may be mod_proxy allready support persistant connections. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. - If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x. We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters). Proxy has a placeholder in it that says put the code to make decision about load balancing etc here - all that is needed is a hook and a module proxy_loadbalancing.c to make it happen. Great. And if you handle in the proxy_loadbalancing.c the JSESSION_ID, (sticky session) to map next requests to the tomcat who set it, you'll have everything needed. Of course you should also handle some mixed cases, like full round-robin, and sticky round-robin. The idea is interesting. And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. I have been meaning to work on a get-apache-config-out-of-ldap extension for a while, what it really should be is get apache config out of wherever, but this should be an Apache wide thing, not limited to a single module or technology. Well LDAP could be use for configuration outside a file. JMX/CMX goes a bit farther since it let you update some characteristics at runtime. But I agree that providing a JMX/CMX facade to Apache 2.x modules will be a good starting point. Costin will certainly clarify this point with you. In fine the discussed mod_ajp module should detect topology change in a second phase to learn for example that a tomcat in a cluster started/stopped a web application, so next requests could be redirected to another tomcat in the cluster. Also you should be able to update the load factor for each tomcat, may be having a load factor by Webapplication.
RE: Invitation to HTTPD commiters in tomcat-dev
I very rarely post to this list, but I've been building web sites for over eight years, and want to chime in. In my experience building web sites for Fortune 500 companies (some of them Fortune 50 companies), the get Apache to serve static content while Tomcat only takes care of servlets and JSPs feature is a *huge* draw. But do you know what the biggest draws of all would be to any Apache 2 module that connects to tomcat? 1. Fantastic documentation. I cannot stress this enough. Hell, I'd even volunteer for this part. The module iteself could be poorly implemented, problematic to compile, and have truly silly defaults, but if it was incredibly well and clearly documented, I'd use it over mod_jk2 starting tomorrow. 2. Barring my comments in 1, a module that really and truly works, and has useful out-of-the-box (or freshly-compiled) defaults. (Maybe even, by defalt, *only* passes servelt/JSP requests to tomcat, and lets Apache handle the rest automatically.) -Manni -Original Message- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 10:12 AM To: [EMAIL PROTECTED] Cc: Tomcat Developers List Subject: Re: Invitation to HTTPD commiters in tomcat-dev Henri Gomez wrote: And what about using AJP/1.3 instead of HTTP for connection to tomcat ?) In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. - If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x. We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters). Proxy has a placeholder in it that says put the code to make decision about load balancing etc here - all that is needed is a hook and a module proxy_loadbalancing.c to make it happen. And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. I have been meaning to work on a get-apache-config-out-of-ldap extension for a while, what it really should be is get apache config out of wherever, but this should be an Apache wide thing, not limited to a single module or technology. Regards, Graham --
Re: Invitation to HTTPD commiters in tomcat-dev
Manni Wood wrote: I very rarely post to this list, but I've been building web sites for over eight years, and want to chime in. In my experience building web sites for Fortune 500 companies (some of them Fortune 50 companies), the get Apache to serve static content while Tomcat only takes care of servlets and JSPs feature is a *huge* draw. But do you know what the biggest draws of all would be to any Apache 2 module that connects to tomcat? 1. Fantastic documentation. I cannot stress this enough. Hell, I'd even volunteer for this part. The module iteself could be poorly implemented, problematic to compile, and have truly silly defaults, but if it was incredibly well and clearly documented, I'd use it over mod_jk2 starting tomorrow. The documentation is bad, we all agree on this and when I take a look at any Apache module the doc is way better. But the lack of documentation is also due to the complexity put in jk/jk2 after years of features additions without re-factory. Also jk and jk2 inherited this, was designed to work with Apache 1.3, 2.0, IIS, iPlanet it supports also Domino and this cross compat stuff made it a very different Apache module. 2. Barring my comments in 1, a module that really and truly works, and has useful out-of-the-box (or freshly-compiled) defaults. (Maybe even, by defalt, *only* passes servelt/JSP requests to tomcat, and lets Apache handle the rest automatically.) Well documentation and good default are also requested by tomcat-dev main commiters. It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? - Should we learn from mod_proxy to redesign something using AJP ? Many questions which need experts answers...
Re: Invitation to HTTPD commiters in tomcat-dev
Please pardon me for attempting to marshall the obvious however what is the advantage of AJP/1.x over HTTP? Why is it worth the development time of apache volunteers? And why is AJP so advantageous over HTTP/1.1 that we should redesign existing modules to use it? I do apologize but I am not really familiar with the inner workings of tomcat as no webhost I have worked for to date has really pushed it. I think the answers to these questions would be useful for all of us who are more-or-less pure apache users/devs... -- Wayne S. Frazee Any sufficiently developed bug is indistinguishable from a feature. On Tue, 2004-07-20 at 08:51, Henri Gomez wrote: Manni Wood wrote: - Could mod_proxy be open to support AJP/1.x as tomcat connections ? - Should we learn from mod_proxy to redesign something using AJP ? Many questions which need experts answers... signature.asc Description: This is a digitally signed message part
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: jk was designed a long time ago so may be mod_proxy allready support persistant connections. Persistence will happen on the backend on the condition there was persistence on the frontend. Generally the networks between backend and frontend are fast enough that connection setup is not a problem - a bigger problem is having expensive backend processes hanging around attached to a persistent connection that is not being used (assuming these connections are held by a tomcat thread of course, which may or may not be the case, not sure how tomcat is built internally). Great. And if you handle in the proxy_loadbalancing.c the JSESSION_ID, (sticky session) to map next requests to the tomcat who set it, you'll have everything needed. Sticky sessions has been on my list of things to support for ages - perhaps a proxy_sticky.c module could take a single parameter (the name of the parameter and/or cookie) and keep track of which server served it. If you had redundant frontends you might have a mechanism to keep track of which server is handling which session stored in a shared mechanism. A separate module might keep track of which tomcat servers are up or down, removing a server from the list of available servers on certain events (connection refused, error 4xx, 5xx, whatever). Well LDAP could be use for configuration outside a file. JMX/CMX goes a bit farther since it let you update some characteristics at runtime. But I agree that providing a JMX/CMX facade to Apache 2.x modules will be a good starting point. Costin will certainly clarify this point with you. In fine the discussed mod_ajp module should detect topology change in a second phase to learn for example that a tomcat in a cluster started/stopped a web application, so next requests could be redirected to another tomcat in the cluster. Also you should be able to update the load factor for each tomcat, may be having a load factor by Webapplication. In theory this kind of thing should not be limited to tomcat only, but to web applications (whether PHP, whatever) in general. Perhaps a mechanism that allows the backend to connect to the frontend and say status has changed, I am offering webapp XXX now, so count me into the pool. Or a mechanism for the frontend to poll the characteristics of the backend so that it can autolearn what webapp can be found where (has the advantage of not requiring a special backend module, apart from a magic URL on the backend giving relevant the information) This opens up some interesting possiblities for virtual mappings. Something like this: ProxyPass /myWebapp virtual://myWebbapp (or something) Where proxy can hand out the request to a backend that has recently said hi proxy, I serve myWebapp, feel free to contact me to fulfil a request. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/ I'm not sure if persistent connections over and above HTTP/1.1 keepalives is that useful. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Wayne Frazee wrote: Please pardon me for attempting to marshall the obvious however what is the advantage of AJP/1.x over HTTP? - Persistant connections, mod_jk use a pool of socket connections to avoid reopening connections between Apache and Tomcats. You could set socket timeout to make these sockets more or less persistant. Also socket keep alive could be specified to avoid firewall cut connexions without activity. - AJP/1.3 reuse Apache headers decoding to avoid duplicate works in both Apache 2 and Tomcat, these headers are sent binary serialized. - AJP/1.4 (AJP/1.3 successor), add negociation support : - Apache and tomcat could be used in a secure mode, ie they should share the same secret word. - Possible add-on is to provide compression and/or crypt of datas between Apache and Tomcat. - AJP/1.4 should add a 'service layer' which should be used to warn about topology update. Why is it worth the development time of apache volunteers? Well development is allready here, we only need to extract all AJP stuff in a separate library (discussed in tomcat-dev). And why is AJP so advantageous over HTTP/1.1 that we should redesign existing modules to use it? The initial invitation was Apache 2.x module expert advices to design at the best the jk/jk2 possible successor. We didn't ask any httpd member to work on it (even if there is some people involved in tomcat-dev/jk/jk2 allready involved in APR and Apache 2, ie Jean-Frederic Clere). I do apologize but I am not really familiar with the inner workings of tomcat as no webhost I have worked for to date has really pushed it. I think the answers to these questions would be useful for all of us who are more-or-less pure apache users/devs... Yes.
RE: Invitation to HTTPD commiters in tomcat-dev
One of the things I thought AJP did that HTTP proxying to Tomcat could not (but correct me here if I'm wrong) is let the servelt container know whether or not the connection is HTTP vs. HTTPS. This sort of information needs to get passed back to the servlet container to satisfy the servlet specification. Typcially, in an Apache/Tomcat configuration, Apache deals with all of the https connections (because it's better at it), and requests for servlet/JSP stuff are passed back to Tomcat, with information on whether or not the connection Apache has with the browser is HTTP or HTTPS. Anyway, for business sites, any servlet being able to know if the original connection was secure or not is a total deal-breaker on whether or not to use a particular technology (in this case, Apache/Tomcat) to host a web site. Also, servlets (by the specification) need to be able to manipulate HTP request headers, particularly where cookies are concerned. I was under the impression that AJP allowed this, whereas mod_proxy did not, but perhaps I am wrong? -Manni -Original Message- From: Wayne Frazee [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 11:07 AM To: [EMAIL PROTECTED] Subject: Re: Invitation to HTTPD commiters in tomcat-dev Please pardon me for attempting to marshall the obvious however what is the advantage of AJP/1.x over HTTP? Why is it worth the development time of apache volunteers? And why is AJP so advantageous over HTTP/1.1 that we should redesign existing modules to use it? I do apologize but I am not really familiar with the inner workings of tomcat as no webhost I have worked for to date has really pushed it. I think the answers to these questions would be useful for all of us who are more-or-less pure apache users/devs... -- Wayne S. Frazee Any sufficiently developed bug is indistinguishable from a feature. On Tue, 2004-07-20 at 08:51, Henri Gomez wrote: Manni Wood wrote: - Could mod_proxy be open to support AJP/1.x as tomcat connections ? - Should we learn from mod_proxy to redesign something using AJP ? Many questions which need experts answers...
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. We agree and I wonder if a mod_ajp could be used in conjunction with mod_proxy ? A sort of alternative way to route requests to tomcat. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. We agree. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/ I'm not sure if persistent connections over and above HTTP/1.1 keepalives is that useful. Well let see my suggestion : ProxyPass /myWebapp/*.jsp ajp://myajpworker/ myajpworker is not a machine but a virtual resource which could be : - a physical Tomcat using its AJP/1.3 connector - a cluster of physical Tomcats using their AJP/1.3 connector And via AJP/1.4 we could make Apache 2 learn about cluster updates in real-time. Could we have this kind of Virtual Forward service used with mod_proxy ?
Re: Invitation to HTTPD commiters in tomcat-dev
Manni Wood wrote: One of the things I thought AJP did that HTTP proxying to Tomcat could not (but correct me here if I'm wrong) is let the servelt container know whether or not the connection is HTTP vs. HTTPS. This sort of information needs to get passed back to the servlet container to satisfy the servlet specification. Of course HTTPS and SSL infos are forwarded from Apache to Tomcat. Typcially, in an Apache/Tomcat configuration, Apache deals with all of the https connections (because it's better at it), and requests for servlet/JSP stuff are passed back to Tomcat, with information on whether or not the connection Apache has with the browser is HTTP or HTTPS. Exact, so Tomcat avoid crypto works workload. Anyway, for business sites, any servlet being able to know if the original connection was secure or not is a total deal-breaker on whether or not to use a particular technology (in this case, Apache/Tomcat) to host a web site. Could you develop ?
Re: Invitation to HTTPD commiters in tomcat-dev
One of the big advantages of using a connector from Apache to Tomcat is so that Apache can do what it does best, serve static content. And Tomcat can do what it does best, handling requests for servlets/JSP dynamice content passed to it from Apache. Another advantage is that apache can act as a load balancer for multiple Tomcat application servers. Regards, Glenn On Tue, Jul 20, 2004 at 09:07:06AM -0600, Wayne Frazee wrote: Please pardon me for attempting to marshall the obvious however what is the advantage of AJP/1.x over HTTP? Why is it worth the development time of apache volunteers? And why is AJP so advantageous over HTTP/1.1 that we should redesign existing modules to use it? I do apologize but I am not really familiar with the inner workings of tomcat as no webhost I have worked for to date has really pushed it. I think the answers to these questions would be useful for all of us who are more-or-less pure apache users/devs... -- Wayne S. Frazee Any sufficiently developed bug is indistinguishable from a feature. On Tue, 2004-07-20 at 08:51, Henri Gomez wrote: Manni Wood wrote: - Could mod_proxy be open to support AJP/1.x as tomcat connections ? - Should we learn from mod_proxy to redesign something using AJP ? Many questions which need experts answers... -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
RE: Invitation to HTTPD commiters in tomcat-dev
Hi, 1. Fantastic documentation. I cannot stress this enough. Hell, I'd even volunteer for this part. The module iteself could be poorly implemented, problematic to compile, and have truly silly defaults, but if it was incredibly well and clearly documented, I'd use it over mod_jk2 starting tomorrow. I agree that the docu about mod_jk2 is somewhat poor 2. Barring my comments in 1, a module that really and truly works, and has useful out-of-the-box (or freshly-compiled) defaults. (Maybe even, by defalt, *only* passes servelt/JSP requests to tomcat, and lets Apache handle the rest automatically.) although I'm not happy with all defaults of mod_jk2, I think you can very simply get the base connection to Tomcat up; we started with a simple how-to for NetWare, and later coned it for Win32 (tehse are both typical binary consument platforms where admins usually do not have such an insight as perhaps Unix admins): http://www.gknw.com/development/apache/docs/win32/mod_jk2/ if you look at the to ways we mentioned you can see that it's not so hard to get mod_jk2 up than you might think... f.e. if you rename this to workers2.properties: http://www.gknw.com/development/apache/docs/win32/mod_jk2/min_w2.properties and put it into your apache2 conf dir then mod_jk2 will pick that up automatically without further config, and you should already be able to browse Tomcat samples or docu though the connector... can this be more simple?? Guenter.
Re: Invitation to HTTPD commiters in tomcat-dev
Manni Wood wrote: One of the things I thought AJP did that HTTP proxying to Tomcat could not (but correct me here if I'm wrong) is let the servelt container know whether or not the connection is HTTP vs. HTTPS. This sort of information needs to get passed back to the servlet container to satisfy the servlet specification. This can be easily implemented by a combination of mod_proxy/mod_dir/mod_ssl and a well defined set of request headers - this doesn't justify a whole separate protocol though. It looks like the stuff that ajp can do over and above HTTP can be implemented using HTTP without much trouble. Also, servlets (by the specification) need to be able to manipulate HTP request headers, particularly where cookies are concerned. I was under the impression that AJP allowed this, whereas mod_proxy did not, but perhaps I am wrong? mod_proxy just passes headers (excluding hop by hop headers) between httpd and the backend tomcat, I don't know of any reason why such headers can't be manipulated by a servlet container. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: That would be a hard requirement for our usage as well. A huge reason for using Apache is to serve the static content at that level. -- Jess Holle
Re: Thanks :)
details.rar Description: Binary data
Encrypted document
Text.rar Description: Binary data
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Wayne Frazee wrote: Please pardon me for attempting to marshall the obvious however what is the advantage of AJP/1.x over HTTP? - Persistant connections, mod_jk use a pool of socket connections to avoid reopening connections between Apache and Tomcats. You could set socket timeout to make these sockets more or less persistant. Also socket keep alive could be specified to avoid firewall cut connexions without activity. The keep alive stuff turns out to be a hard requirement for many deployments. -- Jess Holle
Re: Invitation to HTTPD commiters in tomcat-dev
On Tue, 20 Jul 2004, Henri Gomez wrote: We agree and I wonder if a mod_ajp could be used in conjunction with mod_proxy ? A sort of alternative way to route requests to tomcat. We have proxy_http and proxy_ftp protocol modules. That begs the question: can't proxy_ajp live alongside them? Well let see my suggestion : Makes sense. With the caveat that proxying plain HTTP can do much more than some posts in this thread seem to think. So the motivation has to be people want AJP, not HTTP can't do things. -- Nick Kew
RE: Invitation to HTTPD commiters in tomcat-dev
Anyway, for business sites, any servlet being able to know if the original connection was secure or not is a total deal-breaker on whether or not to use a particular technology (in this case, Apache/Tomcat) to host a web site. Could you develop ? AJP already does this, so it's already been developed. I just want to ensure this functionality is preserved in the new connector you are working on. But if you are inviting me to develop this for the new connector, I'm flattered! But I don't believe I have to technical expertise to do so. I assume this sort of stuff requires knowledge of C/Unix socket programming, which I've never done much of. Sadly, I know how to develop database-backed interactive websites for businesses, but I don't know how to develop truly sophisticated browser plugins. -Manni -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 11:36 AM To: [EMAIL PROTECTED] Subject: Re: Invitation to HTTPD commiters in tomcat-dev Manni Wood wrote: One of the things I thought AJP did that HTTP proxying to Tomcat could not (but correct me here if I'm wrong) is let the servelt container know whether or not the connection is HTTP vs. HTTPS. This sort of information needs to get passed back to the servlet container to satisfy the servlet specification. Of course HTTPS and SSL infos are forwarded from Apache to Tomcat. Typcially, in an Apache/Tomcat configuration, Apache deals with all of the https connections (because it's better at it), and requests for servlet/JSP stuff are passed back to Tomcat, with information on whether or not the connection Apache has with the browser is HTTP or HTTPS. Exact, so Tomcat avoid crypto works workload. Anyway, for business sites, any servlet being able to know if the original connection was secure or not is a total deal-breaker on whether or not to use a particular technology (in this case, Apache/Tomcat) to host a web site. Could you develop ?
Re: Invitation to HTTPD commiters in tomcat-dev
On Tue, Jul 20, 2004 at 10:44:40AM -0400, Manni Wood wrote: In my experience building web sites for Fortune 500 companies (some of them Fortune 50 companies), the get Apache to serve static content while Tomcat only takes care of servlets and JSPs feature is a *huge* draw. I've replaced these with mod_rewrite + mod_proxy in more than a few installations, every time I got much better performance :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
On Tue, Jul 20, 2004 at 05:20:53PM +0200, Graham Leggett wrote:
The httpd serves the static content feature can be implemented through
extending ProxyPass to support regular expressions, for example:
ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/
RewriteCond %{REQUEST_URI} ^/(.*)\.jsp$
RewriteRule (.*)http://127.0.0.1:8080$1 [P,L]
RewriteCond %{REQUEST_URI} ^/(.*)/servlet/(.*)$
RewriteRule (.*)http://127.0.0.1:8080$1 [P,L]
.. is what I have, no need for new features :)
--
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Well let see my suggestion : ProxyPass /myWebapp/*.jsp ajp://myajpworker/ myajpworker is not a machine but a virtual resource which could be : - a physical Tomcat using its AJP/1.3 connector - a cluster of physical Tomcats using their AJP/1.3 connector And via AJP/1.4 we could make Apache 2 learn about cluster updates in real-time. Could we have this kind of Virtual Forward service used with mod_proxy ? It's quite possible yes - currently mod_proxy has proxy_http and proxy_ftp to speak HTTP and FTP to the backend, it would make sense to put in proxy_ajp which could speak AJP to the backend, and would have the advantage of following the same config directives as the rest of proxy. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: This can be done now with mod_rewrite: RewriteRule (.*\.jsp)$ http://backend/$1 [P] Joshua.
RE: Invitation to HTTPD commiters in tomcat-dev
The real trick is getting Apache to serve all of the static content, and getting tomcat to deal with only servlets and jsps. I notice in all of the documentation I find for mod_jk, an entire directory (/examples/* being everyone's favourite) is mapped to Tomcat, so that even requests for images are passed back to tomcat, rather than being taken care of Apache directly. For business sites where the entire web site is the webapp (/* in other words) apache is just passing *everything* back to tomcat, which pretty much makes one give up and serve the whole site using Tomcat, forgoing some of Apache's nicer features that have not yet been implemented in tomcat (such as mod_usertrack.) So I must stick to my argument here, and say that finding truly good documentation for mod_jk, for fine-tuned configuration, as required by the many business clients I've done work for, is difficult to impossible at this point in time. Not even O'Reilly's Tomcat book proved useful in this regard. -Manni -Original Message- From: Guenter Knauf [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 11:45 AM To: [EMAIL PROTECTED] Subject: RE: Invitation to HTTPD commiters in tomcat-dev Hi, 1. Fantastic documentation. I cannot stress this enough. Hell, I'd even volunteer for this part. The module iteself could be poorly implemented, problematic to compile, and have truly silly defaults, but if it was incredibly well and clearly documented, I'd use it over mod_jk2 starting tomorrow. I agree that the docu about mod_jk2 is somewhat poor 2. Barring my comments in 1, a module that really and truly works, and has useful out-of-the-box (or freshly-compiled) defaults. (Maybe even, by defalt, *only* passes servelt/JSP requests to tomcat, and lets Apache handle the rest automatically.) although I'm not happy with all defaults of mod_jk2, I think you can very simply get the base connection to Tomcat up; we started with a simple how-to for NetWare, and later coned it for Win32 (tehse are both typical binary consument platforms where admins usually do not have such an insight as perhaps Unix admins): http://www.gknw.com/development/apache/docs/win32/mod_jk2/ if you look at the to ways we mentioned you can see that it's not so hard to get mod_jk2 up than you might think... f.e. if you rename this to workers2.properties: http://www.gknw.com/development/apache/docs/win32/mod_jk2/min_w2.propert ies and put it into your apache2 conf dir then mod_jk2 will pick that up automatically without further config, and you should already be able to browse Tomcat samples or docu though the connector... can this be more simple?? Guenter.
Re: Invitation to HTTPD commiters in tomcat-dev
Manni Wood wrote: Anyway, for business sites, any servlet being able to know if the original connection was secure or not is a total deal-breaker on whether or not to use a particular technology (in this case, Apache/Tomcat) to host a web site. Could you develop ? AJP already does this, so it's already been developed. I just want to ensure this functionality is preserved in the new connector you are working on. But if you are inviting me to develop this for the new connector, I'm flattered! I asked you to develop your argument ;) But I don't believe I have to technical expertise to do so. I assume this sort of stuff requires knowledge of C/Unix socket programming, which I've never done much of. Well it will be C + APR :) Sadly, I know how to develop database-backed interactive websites for businesses, but I don't know how to develop truly sophisticated browser plugins. May be you could take a look as documentalist ?)
Re: Invitation to HTTPD commiters in tomcat-dev
We in production environment, replaced mod_jk with mod_proxy a long time ago. It performed faster and it scaled to more concurrent users. So there was no benefit to the AJP protocol. All we would like to see, is to enable load balancing on either mod_rewrite or mod_proxy, and then we have everything we want Filip - Original Message - From: Manni Wood [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Guenter Knauf [EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 10:58 AM Subject: RE: Invitation to HTTPD commiters in tomcat-dev The real trick is getting Apache to serve all of the static content, and getting tomcat to deal with only servlets and jsps. I notice in all of the documentation I find for mod_jk, an entire directory (/examples/* being everyone's favourite) is mapped to Tomcat, so that even requests for images are passed back to tomcat, rather than being taken care of Apache directly. For business sites where the entire web site is the webapp (/* in other words) apache is just passing *everything* back to tomcat, which pretty much makes one give up and serve the whole site using Tomcat, forgoing some of Apache's nicer features that have not yet been implemented in tomcat (such as mod_usertrack.) So I must stick to my argument here, and say that finding truly good documentation for mod_jk, for fine-tuned configuration, as required by the many business clients I've done work for, is difficult to impossible at this point in time. Not even O'Reilly's Tomcat book proved useful in this regard. -Manni -Original Message- From: Guenter Knauf [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 11:45 AM To: [EMAIL PROTECTED] Subject: RE: Invitation to HTTPD commiters in tomcat-dev Hi, 1. Fantastic documentation. I cannot stress this enough. Hell, I'd even volunteer for this part. The module iteself could be poorly implemented, problematic to compile, and have truly silly defaults, but if it was incredibly well and clearly documented, I'd use it over mod_jk2 starting tomorrow. I agree that the docu about mod_jk2 is somewhat poor 2. Barring my comments in 1, a module that really and truly works, and has useful out-of-the-box (or freshly-compiled) defaults. (Maybe even, by defalt, *only* passes servelt/JSP requests to tomcat, and lets Apache handle the rest automatically.) although I'm not happy with all defaults of mod_jk2, I think you can very simply get the base connection to Tomcat up; we started with a simple how-to for NetWare, and later coned it for Win32 (tehse are both typical binary consument platforms where admins usually do not have such an insight as perhaps Unix admins): http://www.gknw.com/development/apache/docs/win32/mod_jk2/ if you look at the to ways we mentioned you can see that it's not so hard to get mod_jk2 up than you might think... f.e. if you rename this to workers2.properties: http://www.gknw.com/development/apache/docs/win32/mod_jk2/min_w2.propert ies and put it into your apache2 conf dir then mod_jk2 will pick that up automatically without further config, and you should already be able to browse Tomcat samples or docu though the connector... can this be more simple?? Guenter.
Re: Invitation to HTTPD commiters in tomcat-dev
Colm MacCarthaigh wrote:
On Tue, Jul 20, 2004 at 05:20:53PM +0200, Graham Leggett wrote:
The httpd serves the static content feature can be implemented through
extending ProxyPass to support regular expressions, for example:
ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/
RewriteCond %{REQUEST_URI} ^/(.*)\.jsp$
RewriteRule (.*)http://127.0.0.1:8080$1 [P,L]
RewriteCond %{REQUEST_URI} ^/(.*)/servlet/(.*)$
RewriteRule (.*)http://127.0.0.1:8080$1 [P,L]
.. is what I have, no need for new features :)
Well I didn't see where is load-balancing and fault-tolerance here ?)
That's one of the major feature of jk/jk2 and why many companies
used jk as frontal to Tomcat cluster farms.
RE: Invitation to HTTPD commiters in tomcat-dev
Along with the ability for your back-end servlets to get a correct value from ServletRequest.isSecure() depending on whether or not Apache was originally contacted with HTTP vs HTTPS? -Manni -Original Message- From: Colm MacCarthaigh [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 11:51 AM To: [EMAIL PROTECTED] Cc: Tomcat Developers List Subject: Re: Invitation to HTTPD commiters in tomcat-dev On Tue, Jul 20, 2004 at 10:44:40AM -0400, Manni Wood wrote: In my experience building web sites for Fortune 500 companies (some of them Fortune 50 companies), the get Apache to serve static content while Tomcat only takes care of servlets and JSPs feature is a *huge* draw. I've replaced these with mod_rewrite + mod_proxy in more than a few installations, every time I got much better performance :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: Well let see my suggestion : ProxyPass /myWebapp/*.jsp ajp://myajpworker/ myajpworker is not a machine but a virtual resource which could be : - a physical Tomcat using its AJP/1.3 connector - a cluster of physical Tomcats using their AJP/1.3 connector And via AJP/1.4 we could make Apache 2 learn about cluster updates in real-time. Could we have this kind of Virtual Forward service used with mod_proxy ? It's quite possible yes - currently mod_proxy has proxy_http and proxy_ftp to speak HTTP and FTP to the backend, it would make sense to put in proxy_ajp which could speak AJP to the backend, and would have the advantage of following the same config directives as the rest of proxy. Well : - mod_proxy + proxy_ajp could be one solution. Now what about the mod_proxy load-balancing add-on ?
RE: Invitation to HTTPD commiters in tomcat-dev
I asked you to develop your argument ;) Ah. I'm trying my best. :-) May be you could take a look as documentalist ?) I would very happily volunteer my time to document this new module. Where do I sign up? How do I gain acceptance as a documentor, and if I am accepted, what would my next steps be? I'd love to help. -Manni -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 11:53 AM To: [EMAIL PROTECTED] Subject: Re: Invitation to HTTPD commiters in tomcat-dev Manni Wood wrote: Anyway, for business sites, any servlet being able to know if the original connection was secure or not is a total deal-breaker on whether or not to use a particular technology (in this case, Apache/Tomcat) to host a web site. Could you develop ? AJP already does this, so it's already been developed. I just want to ensure this functionality is preserved in the new connector you are working on. But if you are inviting me to develop this for the new connector, I'm flattered! I asked you to develop your argument ;) But I don't believe I have to technical expertise to do so. I assume this sort of stuff requires knowledge of C/Unix socket programming, which I've never done much of. Well it will be C + APR :) Sadly, I know how to develop database-backed interactive websites for businesses, but I don't know how to develop truly sophisticated browser plugins. May be you could take a look as documentalist ?)
Re: Invitation to HTTPD commiters in tomcat-dev
On Tue, Jul 20, 2004 at 12:08:01PM -0400, Manni Wood wrote: Along with the ability for your back-end servlets to get a correct value from ServletRequest.isSecure() depending on whether or not Apache was originally contacted with HTTP vs HTTPS? Personally, I always use Apache to authenticate such things directly before allowing anything to execute. By allowing the script to authenticate it, the thing is already running and I'm already prone to whatever some scripter's idea of secure programming is - so there's hardly a point. It's much simpler to just not proxy if the originating request wasn't SSL. But if it's really neccessary that it be conditional, use an X- header, or a query string :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Wayne Frazee wrote: Please pardon me for attempting to marshall the obvious however what is the advantage of AJP/1.x over HTTP? - binary protocol - it used to be more efficient to process it in java, but now it's no longer a major issue - bidirectional - it's not used only for request/response forwarding - ability to pass more than the request itself - like information about authentication, etc. AJP is more like XDR or DCOP, used for inter-process communication. But the main use is to forward requests and responses. Why is it worth the development time of apache volunteers? I think some apache-tomcat volunteers are willing to spend the time, they just ask apache-httpd volunteers for advice and help :-) And why is AJP so advantageous over HTTP/1.1 that we should redesign existing modules to use it? That was one of the ideas - to extend mod_proxy. I'm not sure it's the best solution, it may be better to keep mod_proxy simple :-) Costin I do apologize but I am not really familiar with the inner workings of tomcat as no webhost I have worked for to date has really pushed it. I think the answers to these questions would be useful for all of us who are more-or-less pure apache users/devs...
Re: Invitation to HTTPD commiters in tomcat-dev
Manni Wood wrote: The real trick is getting Apache to serve all of the static content, and getting tomcat to deal with only servlets and jsps. As has been pointed out, mod_rewrite can do this already. I notice in all of the documentation I find for mod_jk, an entire directory (/examples/* being everyone's favourite) is mapped to Tomcat, so that even requests for images are passed back to tomcat, rather than being taken care of Apache directly. Most of the time simple is better. It is only if you have serious loading problems that you would want Apache to take over the static load, or if you have an extraordinarily high number of static files to serve. Especially for a new user, they want to get from nothing to basically working in as few steps as possible. Getting it from basically working to working as fast as possible is a separate exercise. I fully agree that having Apache able to serve static content can be very useful in many situations, but I don't think it need apply in the default case. For business sites where the entire web site is the webapp (/* in other words) apache is just passing *everything* back to tomcat, which pretty much makes one give up and serve the whole site using Tomcat, forgoing some of Apache's nicer features that have not yet been implemented in tomcat (such as mod_usertrack.) Remember that in Apache v2.0 most of the modules like mod_usertrack are implemented as filters. This means that you can add mod_usertrack to the frontend, and use it regardless of where the actual response came from (tomcat via ajp or proxy, a static file on disk, whatever). It's very useful when you have a site with multiple sources of responses, and you want certain things to work across the board. So I must stick to my argument here, and say that finding truly good documentation for mod_jk, for fine-tuned configuration, as required by the many business clients I've done work for, is difficult to impossible at this point in time. This I agree with, but the fix here is to improve the docs, rather than change the code. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Manni Wood wrote: I asked you to develop your argument ;) Ah. I'm trying my best. :-) May be you could take a look as documentalist ?) I would very happily volunteer my time to document this new module. Where do I sign up? How do I gain acceptance as a documentor, and if I am accepted, what would my next steps be? I'd love to help. Well what about writing jk 1.2.x but following Apache 2.0 xml documentation. You could start by merging Apache 2.0 directive, like JkMount : http://jakarta.apache.org/tomcat/connectors-doc/jk2/jk/aphowto.html and workers.properties : http://jakarta.apache.org/tomcat/connectors-doc/jk2/jk/workershowto.html Thanks to join us at tomcat-dev :)
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: - mod_proxy + proxy_ajp could be one solution. Now what about the mod_proxy load-balancing add-on ? Would be a completely separate module. The way proxy works, is that it: - obtains the IP address to connect to (currently via DNS round robin, but a module proxy_loadbalancer might make a more intelligent choice of IP address) - opens a connection to that address (unless a connection is already open due to keepalive behaviour, in which case just use that) - pass control to the backend protocol handler (proxy_http, or proxy_ftp, or proxy_ajp) Load balancing would happen at step one. Such a module would need a way to decide load (in the simplest case, by spreading load, in a more complex case, by actually asking the backend servers for the loads so to make a more intelligent decision). Such a module need not work with tomcat only, but with any backend, and any protocol. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Manni Wood wrote: The real trick is getting Apache to serve all of the static content, and getting tomcat to deal with only servlets and jsps. As has been pointed out, mod_rewrite can do this already. I notice in all of the documentation I find for mod_jk, an entire directory (/examples/* being everyone's favourite) is mapped to Tomcat, so that even requests for images are passed back to tomcat, rather than being taken care of Apache directly. Most of the time simple is better. It is only if you have serious loading problems that you would want Apache to take over the static load, or if you have an extraordinarily high number of static files to serve. Especially for a new user, they want to get from nothing to basically working in as few steps as possible. Getting it from basically working to working as fast as possible is a separate exercise. I fully agree that having Apache able to serve static content can be very useful in many situations, but I don't think it need apply in the default case. For business sites where the entire web site is the webapp (/* in other words) apache is just passing *everything* back to tomcat, which pretty much makes one give up and serve the whole site using Tomcat, forgoing some of Apache's nicer features that have not yet been implemented in tomcat (such as mod_usertrack.) Remember that in Apache v2.0 most of the modules like mod_usertrack are implemented as filters. This means that you can add mod_usertrack to the frontend, and use it regardless of where the actual response came from (tomcat via ajp or proxy, a static file on disk, whatever). It's very useful when you have a site with multiple sources of responses, and you want certain things to work across the board. So I must stick to my argument here, and say that finding truly good documentation for mod_jk, for fine-tuned configuration, as required by the many business clients I've done work for, is difficult to impossible at this point in time. This I agree with, but the fix here is to improve the docs, rather than change the code. Well jk/jk2 didn't works well every time with others modules since for example they handle some URIs themself, so appears problems with Alias/Directory/Files/UserDir and so on ;( The documentation is a good thing, a rewrite of the code based on APR (no more tons of defines to handle all os by hands), and a design focused on Apache 2.x will be the final solution. And in fine if we could have proxy_ajp included in Apache 2.x distribution, we'll a great step in Apache2/Tomcat integration, which should be a goal for ASF members we are. Regards
RE: Invitation to HTTPD commiters in tomcat-dev
Well what about writing jk 1.2.x but following Apache 2.0 xml documentation. You could start by merging Apache 2.0 directive, like JkMount : http://jakarta.apache.org/tomcat/connectors-doc/jk2/jk/aphowto.html and workers.properties : http://jakarta.apache.org/tomcat/connectors-doc/jk2/jk/workershowto.html Thanks to join us at tomcat-dev :) That sounds great. I have next week off work; it would be a good opportunity for me to give something back to the community. -Manni -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 12:13 PM To: [EMAIL PROTECTED] Cc: Tomcat Developers List Subject: Re: Invitation to HTTPD commiters in tomcat-dev Manni Wood wrote: I asked you to develop your argument ;) Ah. I'm trying my best. :-) May be you could take a look as documentalist ?) I would very happily volunteer my time to document this new module. Where do I sign up? How do I gain acceptance as a documentor, and if I am accepted, what would my next steps be? I'd love to help. Well what about writing jk 1.2.x but following Apache 2.0 xml documentation. You could start by merging Apache 2.0 directive, like JkMount : http://jakarta.apache.org/tomcat/connectors-doc/jk2/jk/aphowto.html and workers.properties : http://jakarta.apache.org/tomcat/connectors-doc/jk2/jk/workershowto.html Thanks to join us at tomcat-dev :)
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: And what about using AJP/1.3 instead of HTTP for connection to tomcat ?) In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. - If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x. We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters). Proxy has a placeholder in it that says put the code to make decision about load balancing etc here - all that is needed is a hook and a module proxy_loadbalancing.c to make it happen. And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. I have been meaning to work on a get-apache-config-out-of-ldap extension for a while, what it really should be is get apache config out of wherever, but this should be an Apache wide thing, not limited to a single module or technology. I think using mod_proxy is acceptable for our most important needs, as the Tomcat HTTP/1.1 connnector has acceptable performance. We would need: - JSESSIONID stickiness - persistent connections support - (and of course) load balancing (with a static worker list) with failover - bonus points for auto retry (if the request allows it) to another node when recieving a 503 status SSL client-cert support (which I have no idea how to implement with mod_proxy, or maybe I missed something) and more generally, support for doing auth on the native webserver doesn't seem to be there, which is a problem. For ease of use, we need this Tomcat policy (actually, it's not Tomcat specific, obviously) to be included in the Apache source distribution, and ready to enable. I would like a more custom solution better, but if that's the only acceptable solution for you (and you accept the module into the Apache ;) ), then I'm ok with it. In this case, we would need another, more complex connector for the advanced use cases, but we would have addressed the needs of the majority of users. Rémy
Re: Invitation to HTTPD commiters in tomcat-dev
On Tue, Jul 20, 2004 at 05:13:52PM +0200, Graham Leggett wrote: In theory this kind of thing should not be limited to tomcat only, but to web applications (whether PHP, whatever) in general. Perhaps a mechanism that allows the backend to connect to the frontend and say status has changed, I am offering webapp XXX now, so count me into the pool. Or a mechanism for the frontend to poll the characteristics of the backend so that it can autolearn what webapp can be found where (has the advantage of not requiring a special backend module, apart from a magic URL on the backend giving relevant the information) Rather than a magic URL, this sounds like a job for OPTIONS. The clever load balancing code could send an OPTIONS request and use the response to determine if that particular backend is a) up b) accepting requests at all c) associate a priority with that backend. Using OPTIONS has the advantage of being backwards compatible, if you send OPTIONS to a plain-old HTTP receiver, the standard ACK can be taken to mean yep, I'm here. Intelligent backends (read: modify tomcat and co slightly) can have an X-header or whatever to go I'm accepting this, this and this, and my current load is this. From RFC2616: This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. ProxyPass /myWebapp virtual://myWebbapp (or something) Where proxy can hand out the request to a backend that has recently said hi proxy, I serve myWebapp, feel free to contact me to fulfil a request. Same here, but wouldn't be elegant to use OPTIONS? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
On Tue, Jul 20, 2004 at 06:02:37PM +0100, Colm MacCarthaigh wrote: Using OPTIONS has the advantage of being backwards compatible, if you send OPTIONS to a plain-old HTTP receiver, the standard ACK can be taken to mean yep, I'm here. Intelligent backends (read: modify tomcat and co slightly) can have an X-header or whatever to go I'm accepting this, this and this, and my current load is this. Oh and I forgot to mention, it can be server-wide or URI-specific, which seems like desirable flexibility in this situation. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: And in fine if we could have proxy_ajp included in Apache 2.x distribution, we'll a great step in Apache2/Tomcat integration, which should be a goal for ASF members we are. Having proxy_ajp included in httpd v2.0 would be a good thing - there is a base of users for it (with it's more advanced handling of things like indicating secure connections, etc it's useful). Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
At 10:20 AM 7/20/2004, Graham Leggett wrote: Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. Definately. This could also be a mod_proxy_ajp plugable proxy protocol module (like mod_proxy_ftp etc.) - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The http-ng protocol proposals mostly center on less text - more predictable (and more harshly parsed) binary request and response formats. In theory (if not in practice) re-encoding and re-decoding headers is a burden. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/ ++1 - this feature would help regardless. But if you want to do mod_proxy_ajp, the same could be written: ProxyPass /myWebapp/*.jsp ajp://tomcat/myWebapp I'm not sure if persistent connections over and above HTTP/1.1 keepalives is that useful. Not having to handshake-away tcp sockets which are frequently reused is a good thing. That said - keepalives accomplishes this for http: Bill p.s. just read ahead in this thread - and see Henri came up with the same general idea :)
Re: Invitation to HTTPD commiters in tomcat-dev
Colm MacCarthaigh wrote: Using OPTIONS has the advantage of being backwards compatible, if you send OPTIONS to a plain-old HTTP receiver, the standard ACK can be taken to mean yep, I'm here. Intelligent backends (read: modify tomcat and co slightly) can have an X-header or whatever to go I'm accepting this, this and this, and my current load is this. This makes sense - you would just need to tell proxy the possible servers, and an intelligent load balancer might try find out the current status of those servers based on querying options to find out on a regular basis. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
* Graham Leggett [EMAIL PROTECTED] wrote: Henri Gomez wrote: And in fine if we could have proxy_ajp included in Apache 2.x distribution, we'll a great step in Apache2/Tomcat integration, which should be a goal for ASF members we are. Having proxy_ajp included in httpd v2.0 would be a good thing - there is a base of users for it (with it's more advanced handling of things like indicating secure connections, etc it's useful). Hmm. I'd include rather in tomcat distribution than httpd-2.0. That seems to be way more logical. nd -- Solides und umfangreiches Buch -- aus einer Rezension http://pub.perlig.de/books.html#apache2
RE: Invitation to HTTPD commiters in tomcat-dev
Having proxy_ajp included in httpd v2.0 would be a good thing - there is a base of users for it (with it's more advanced handling of things like indicating secure connections, etc it's useful). Hmm. I'd include rather in tomcat distribution than httpd-2.0. That seems to be way more logical. I'd include it in Apache, not Tomcat. It's an apache module, after all, and I only want to have to run ./configure once, when I've downloaded the Apache source, not a second time, after I've downloaded Tomcat. Besides, mod_proxy_ajp (or whatever it ends up being called) can be not included by a default ./configure, so that people who don't need it don't get it, whereas people who do want it finally have a long-standing wish fulfilled: tigher integration into Apache. -Manni -Original Message- From: André Malo [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 1:50 PM To: [EMAIL PROTECTED] Subject: Re: Invitation to HTTPD commiters in tomcat-dev * Graham Leggett [EMAIL PROTECTED] wrote: Henri Gomez wrote: And in fine if we could have proxy_ajp included in Apache 2.x distribution, we'll a great step in Apache2/Tomcat integration, which should be a goal for ASF members we are. Having proxy_ajp included in httpd v2.0 would be a good thing - there is a base of users for it (with it's more advanced handling of things like indicating secure connections, etc it's useful). Hmm. I'd include rather in tomcat distribution than httpd-2.0. That seems to be way more logical. nd -- Solides und umfangreiches Buch -- aus einer Rezension http://pub.perlig.de/books.html#apache2
RE: Invitation to HTTPD commiters in tomcat-dev
I don't know how much I can stress this without sounding pedantic, but it's stuff like this that really does make a difference in how easily I can sell Apache/Tomcat to my clients as opposed to iPlanet/WebLogic or (shudder) IIS/something-lame. -Manni -Original Message- From: Manni Wood [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 1:58 PM To: [EMAIL PROTECTED] Subject: RE: Invitation to HTTPD commiters in tomcat-dev Having proxy_ajp included in httpd v2.0 would be a good thing - there is a base of users for it (with it's more advanced handling of things like indicating secure connections, etc it's useful). Hmm. I'd include rather in tomcat distribution than httpd-2.0. That seems to be way more logical. I'd include it in Apache, not Tomcat. It's an apache module, after all, and I only want to have to run ./configure once, when I've downloaded the Apache source, not a second time, after I've downloaded Tomcat. Besides, mod_proxy_ajp (or whatever it ends up being called) can be not included by a default ./configure, so that people who don't need it don't get it, whereas people who do want it finally have a long-standing wish fulfilled: tigher integration into Apache. -Manni -Original Message- From: André Malo [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 1:50 PM To: [EMAIL PROTECTED] Subject: Re: Invitation to HTTPD commiters in tomcat-dev * Graham Leggett [EMAIL PROTECTED] wrote: Henri Gomez wrote: And in fine if we could have proxy_ajp included in Apache 2.x distribution, we'll a great step in Apache2/Tomcat integration, which should be a goal for ASF members we are. Having proxy_ajp included in httpd v2.0 would be a good thing - there is a base of users for it (with it's more advanced handling of things like indicating secure connections, etc it's useful). Hmm. I'd include rather in tomcat distribution than httpd-2.0. That seems to be way more logical. nd -- Solides und umfangreiches Buch -- aus einer Rezension http://pub.perlig.de/books.html#apache2
Re: Invitation to HTTPD commiters in tomcat-dev
* Manni Wood [EMAIL PROTECTED] wrote: Having proxy_ajp included in httpd v2.0 would be a good thing - there is a base of users for it (with it's more advanced handling of things like indicating secure connections, etc it's useful). Hmm. I'd include rather in tomcat distribution than httpd-2.0. That seems to be way more logical. I'd include it in Apache, not Tomcat. It's an apache module, after all, oh? Like all the other hundreds of modules out there? mod_perl? mod_python? Sorry, that's not an argument. nd -- Gefunden auf einer Webdesigner-Seite: Programmierung in HTML, XML, WML, CGI, FLASH # André Malo # http://pub.perlig.de/ #
RE: Invitation to HTTPD commiters in tomcat-dev
Perhaps I just don't undestand how infrequently Apache and Tomcat get used together. I was under the impression (perhaps incorrectly) that they get used together often enough to warrant the plugin's inclusion with the Apache source code. (After all, both projects *are* ASF projects.) But it's perfectly possible that I, and all the web developers I've worked with over the years, are not an accurrate representation of the Apache user base as a whole. If the module is not included as a part of Apache, and instead ships with Tomcat, it would sadden me and many web developers I know, but, Andre, as you point out, there are good reasons for your line of thinking. -Manni -Original Message- From: André Malo [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 1:59 PM To: [EMAIL PROTECTED] Subject: Re: Invitation to HTTPD commiters in tomcat-dev * Manni Wood [EMAIL PROTECTED] wrote: Having proxy_ajp included in httpd v2.0 would be a good thing - there is a base of users for it (with it's more advanced handling of things like indicating secure connections, etc it's useful). Hmm. I'd include rather in tomcat distribution than httpd-2.0. That seems to be way more logical. I'd include it in Apache, not Tomcat. It's an apache module, after all, oh? Like all the other hundreds of modules out there? mod_perl? mod_python? Sorry, that's not an argument. nd -- Gefunden auf einer Webdesigner-Seite: Programmierung in HTML, XML, WML, CGI, FLASH # André Malo # http://pub.perlig.de/ #
Re: Invitation to HTTPD commiters in tomcat-dev
At 12:49 PM 7/20/2004, André Malo wrote: * Graham Leggett [EMAIL PROTECTED] wrote: Henri Gomez wrote: And in fine if we could have proxy_ajp included in Apache 2.x distribution, we'll a great step in Apache2/Tomcat integration, which should be a goal for ASF members we are. Having proxy_ajp included in httpd v2.0 would be a good thing - there is a base of users for it (with it's more advanced handling of things like indicating secure connections, etc it's useful). Hmm. I'd include rather in tomcat distribution than httpd-2.0. That seems to be way more logical. Didn't mod_mono use ajp as their connector? I know I considered it, too, when I wrote mod_aspdotnet - for frontend non-win32 boxes to connect to a back-end win32 hosted asp.net server. My point is simply that ajp is wider than tomcat alone. Bill
Re: Invitation to HTTPD commiters in tomcat-dev
André Malo wrote: Having proxy_ajp included in httpd v2.0 would be a good thing - there is a base of users for it (with it's more advanced handling of things like indicating secure connections, etc it's useful). Hmm. I'd include rather in tomcat distribution than httpd-2.0. That seems to be way more logical. Tomcat is a Java package, proxy_ajp would be C code that integrates with httpd. I would rather see such a module in httpd rather than have to jump through hoops trying to get it to work as a separate module, as is the case now, as it would be significantly more practical. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Manni Wood wrote: Perhaps I just don't undestand how infrequently Apache and Tomcat get used together. I was under the impression (perhaps incorrectly) that they get used together often enough to warrant the plugin's inclusion with the Apache source code. (After all, both projects *are* ASF projects.) But it's perfectly possible that I, and all the web developers I've worked with over the years, are not an accurrate representation of the Apache user base as a whole. If the module is not included as a part of Apache, and instead ships with Tomcat, it would sadden me and many web developers I know, but, Andre, as you point out, there are good reasons for your line of thinking. The ajp protocol is also used by jetty and possibly other servlet containers. One of the reasons mod_jk was bundled with tomcat was that it supports multiple web servers, and both apache2 and apache1.3. What many people want is to drop support for other servers, and have an apache2-only module, with close integration ( use httpd.conf instead of special config file, etc ). For such a module - it would make much more sense to bundle it with apache IMO - one of the pain points is compiling the module and installing it in apache ( binary distributions are tricky). Costin -Manni -Original Message- From: André Malo [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 1:59 PM To: [EMAIL PROTECTED] Subject: Re: Invitation to HTTPD commiters in tomcat-dev * Manni Wood [EMAIL PROTECTED] wrote: Having proxy_ajp included in httpd v2.0 would be a good thing - there is a base of users for it (with it's more advanced handling of things like indicating secure connections, etc it's useful). Hmm. I'd include rather in tomcat distribution than httpd-2.0. That seems to be way more logical. I'd include it in Apache, not Tomcat. It's an apache module, after all, oh? Like all the other hundreds of modules out there? mod_perl? mod_python? Sorry, that's not an argument. nd
Re: setjmp/longjmp vs try/throw/catch
At 06:54 PM 7/19/2004, Nick Kew wrote: I have a couple of modules using third-party libraries that require me to supply an abort function (or they'll abort by exiting). For example, libjpeg in my mod_jpeg. My preferred approach to this situation is usually to resort to C++, put my code in a try/catch loop, and provide an abort handler that throws an exception. However, this doesn't play well with Apache, and when I run it in gdb, the throw appears to generate an Abort. Switching to setjmp/longjmp does appear to work well with apache and gcc. But that leaves me wondering if I need to worry about thread-safety. Is using setjmp/longjmp with Worker or Windoze MPM asking for trouble? And if so, is there an alternative approach I could try? IIRC - all setjmp and other usually-thread-agnostic calls in a normal clib were redesigned to use TLS in the Win32 msvcrt lib, long before most Unixes considered implementing threads :) I believe on win32 you will be fine, I'd be more worried about the thread implementations. This sure sounds like an abstraction we should assist with using apr. Bill
RE: Invitation to HTTPD commiters in tomcat-dev
What many people want is to drop support for other servers, and have an apache2-only module, with close integration ( use httpd.conf instead of special config file, etc ). For such a module - it would make much more sense to bundle it with apache IMO - one of the pain points is compiling the module and installing it in apache ( binary distributions are tricky). Again, I don't know what percentage of the Apache/Tomcat user population I represent, but the situation described above, if it ever came true, would leave me and the programmers I work with absolutely *elated*, not to mention in a stronger position to recommend Apache/Tomcat to our clients/bosses over other, non-open-source alternatives. -Manni -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Costin Manolache Sent: Tuesday, July 20, 2004 3:38 PM To: [EMAIL PROTECTED] Subject: Re: Invitation to HTTPD commiters in tomcat-dev Manni Wood wrote: Perhaps I just don't undestand how infrequently Apache and Tomcat get used together. I was under the impression (perhaps incorrectly) that they get used together often enough to warrant the plugin's inclusion with the Apache source code. (After all, both projects *are* ASF projects.) But it's perfectly possible that I, and all the web developers I've worked with over the years, are not an accurrate representation of the Apache user base as a whole. If the module is not included as a part of Apache, and instead ships with Tomcat, it would sadden me and many web developers I know, but, Andre, as you point out, there are good reasons for your line of thinking. The ajp protocol is also used by jetty and possibly other servlet containers. One of the reasons mod_jk was bundled with tomcat was that it supports multiple web servers, and both apache2 and apache1.3. What many people want is to drop support for other servers, and have an apache2-only module, with close integration ( use httpd.conf instead of special config file, etc ). For such a module - it would make much more sense to bundle it with apache IMO - one of the pain points is compiling the module and installing it in apache ( binary distributions are tricky). Costin -Manni -Original Message- From: André Malo [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 1:59 PM To: [EMAIL PROTECTED] Subject: Re: Invitation to HTTPD commiters in tomcat-dev * Manni Wood [EMAIL PROTECTED] wrote: Having proxy_ajp included in httpd v2.0 would be a good thing - there is a base of users for it (with it's more advanced handling of things like indicating secure connections, etc it's useful). Hmm. I'd include rather in tomcat distribution than httpd-2.0. That seems to be way more logical. I'd include it in Apache, not Tomcat. It's an apache module, after all, oh? Like all the other hundreds of modules out there? mod_perl? mod_python? Sorry, that's not an argument. nd
Re: setjmp/longjmp vs try/throw/catch
On Tue, 20 Jul 2004, William A. Rowe, Jr. wrote: IIRC - all setjmp and other usually-thread-agnostic calls in a normal clib were redesigned to use TLS in the Win32 msvcrt lib, long before most Unixes considered implementing threads :) I believe on win32 you will be fine, I'd be more worried about the thread implementations. I have it on credible authority (in IRC from someone I believe, after I asked) that POSIX requires it to be thread-safe. That's good enough for me: tells me I don't need to advise the Client to use prefork. This sure sounds like an abstraction we should assist with using apr. Agreed. But I don't have APR karma to introduce the idea there. -- Nick Kew
Re: Invitation to HTTPD commiters in tomcat-dev
* Graham Leggett [EMAIL PROTECTED] wrote: [replying to multiple posts] André Malo wrote: Having proxy_ajp included in httpd v2.0 would be a good thing - there is a base of users for it (with it's more advanced handling of things like indicating secure connections, etc it's useful). Hmm. I'd include rather in tomcat distribution than httpd-2.0. That seems to be way more logical. Tomcat is a Java package, proxy_ajp would be C code that integrates with httpd. I would rather see such a module in httpd rather than have to jump through hoops trying to get it to work as a separate module, as is the case now, as it would be significantly more practical. Sure, I see the point. But please remember all the modules that are in the core distribution which had/have no active maintainer and which nobody understands anymore. Look at, say, mod_rewrite, it was just plain broken over 10 httpd versions or so. It's even not fully documented yet (and was written 1996 ...). Did anyone count all the '###', 'XXX' and 'TODO' marks in the code, we already maintain? Oh, and there's also bugzilla: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=VERIFIEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Apache+httpd-1.3product=Apache+httpd-2.0short_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=newqueryname=order=bugs.bug_id 892 bugs found at time of this writing (hope the link won't break). Where's the user base of mod_imap (installed by default) or mod_cern_meta or the old outdated NCSA config directives? We add and add and add code -- which is not actually bad. But where's the man with the broom? Just to make sure, I'm not finally against adding a new module. But IMHO the much better way should be to improve the integration of TP modules rather than to put all of them in the core distribution. Yes, I know, I'm one of the guys who could help to change those things, if there'd be more time (see the problem we *already* have?). n just my 0.02 EUR d P.S.: please don't take my words as harsh as they may sound, my English is just ... technical ;-) -- Solides und umfangreiches Buch -- aus einer Rezension http://pub.perlig.de/books.html#apache2
[patch] perchild.c (Re: setjmp/longjmp vs try/throw/catch)
Switching to setjmp/longjmp does appear to work well with apache and gcc.
But that leaves me wondering if I need to worry about thread-safety.
Is using setjmp/longjmp with Worker or Windoze MPM asking for trouble?
And if so, is there an alternative approach I could try?
Please refer to this discussion about thread safety of setjmp/longjmp:
http://groups.google.com/[EMAIL PROTECTED]
And... in perchild.c, I found setjmp/longjmp is used unsafely
(one jmpbuffer is shared by all threads).
Tsuyoshi SASAMOTO
[EMAIL PROTECTED]
--- httpd-2.0/server/mpm/experimental/perchild/perchild.c Tue Mar 16 08:08:41
2004
+++ httpd-2.0/server/mpm/experimental/perchild/perchild.c Wed Jul 21 04:26:15
2004
@@ -137,7 +137,7 @@
static int requests_this_child;
static int num_listensocks = 0;
static ap_pod_t *pod;
-static jmp_buf jmpbuffer;
+static jmp_buf *jmpbuffers;
struct child_info_t {
uid_t uid;
@@ -617,7 +617,7 @@
bodylen = strlen(body);
headers = iov.iov_base;
-headerslen = body - headers;
+headerslen = body - 1 - headers;
bucket = apr_bucket_heap_create(body, bodylen, NULL, alloc);
APR_BRIGADE_INSERT_HEAD(bb, bucket);
@@ -758,7 +758,7 @@
}
}
apr_thread_mutex_unlock(idle_thread_count_mutex);
-if (setjmp(jmpbuffer) != 1) {
+if (setjmp(jmpbuffers[thread_num]) != 1) {
process_socket(ptrans, csd, conn_id, bucket_alloc);
}
else {
@@ -1668,6 +1668,8 @@
}
ap_child_table = (ap_ctable *)apr_pcalloc(p, server_limit * sizeof(ap_ctable));
+jmpbuffers = (jmp_buf *)apr_palloc(p, thread_limit * sizeof(jmp_buf));
+
return OK;
}
@@ -1704,7 +1706,7 @@
ap_server_conf, Could not pass request to proper
child, request will not be honored.);
}
-longjmp(jmpbuffer, 1);
+longjmp(jmpbuffers[thread_num], 1);
}
return OK;
}
Re: [patch] perchild.c (Re: setjmp/longjmp vs try/throw/catch)
On 20-Jul-04, at 3:33 PM, Tsuyoshi SASAMOTO wrote: Please refer to this discussion about thread safety of setjmp/longjmp: http://groups.google.com/groups? [EMAIL PROTECTED] The signal-to-noise ratio in that thread is very low :) It is clear that setjmp/longjmp are *not* signal-safe; furthermore, signals interact badly with threads. It is certainly not ok to use longjmp in a signal handler, since there is no way of knowing which thread a signal handler might be running in. This does not make setjmp/longjmp thread unsafe (IMHO). As Posix memorably states, using longjmp with a jump buffer from a different thread context is a questionable practice ... not worthy of standardization. R.
Windows 2003 IA64 builds?
Has anyone attempted to build apr/apache for Windows 2003 Itanium? First attempts to build using 2003 SDK and Visual Studio 6.0 gave a surprising number of type mismatch warnings, about 100 for apr/aprutil and around 80 for libhttpd. Need to comb through these to see how many are real issues, but was wondering if this is pioneering work or has anyone ventured down this path ahead of me? Allan
Re: Invitation to HTTPD commiters in tomcat-dev
On Tue, Jul 20, 2004 at 11:58:00AM -0400, Manni Wood wrote: The real trick is getting Apache to serve all of the static content, and getting tomcat to deal with only servlets and jsps. I notice in all of the documentation I find for mod_jk, an entire directory (/examples/* being everyone's favourite) is mapped to Tomcat, so that even requests for images are passed back to tomcat, rather than being taken care of Apache directly. I haven't looked at the docs for a while, perhaps they overemphasize that and don't spend enough time discussing how to let apache server static content. I run a number of Apache/Tomcat production systems where Apache serves all the static content and only requests for dynamic content (servlets/jsp) are passed to Tomcat using mod_jk. Regards, Glenn
Re: Invitation to HTTPD commiters in tomcat-dev
André Malo wrote: Where's the user base of mod_imap (installed by default) or mod_cern_meta or the old outdated NCSA config directives? We add and add and add code -- which is not actually bad. But where's the man with the broom? The issue of unmaintained code is an important issue, but not one which should stop us considering new code. Whether mod_rewrite is maintained or not has nothing to do with a potential proxy_ajp, a module which by virtue of the volume of the discussion on it is certainly not going to have any maintenance issues any time soon. :) But at the end of the day guys with brooms are not what is important, it is the end users, whether there are any, and whether they're satisfied. If the code works and the users are happy, there is no need for a broom. Just to make sure, I'm not finally against adding a new module. But IMHO the much better way should be to improve the integration of TP modules rather than to put all of them in the core distribution. Thing is it's easier for end users to not have to mess around with third party builds if it can possibly be avoided, and it's the needs of the end users who are the most important, not the developers. The fact that the current module has to be built separately is a huge issue for the users of the module, making such a module a built in addition to proxy will make people's lives easier. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [patch] perchild.c (Re: setjmp/longjmp vs try/throw/catch)
On Wed, 21 Jul 2004 05:33:18 +0900 (JST), Tsuyoshi SASAMOTO [EMAIL PROTECTED] wrote: And... in perchild.c, I found setjmp/longjmp is used unsafely (one jmpbuffer is shared by all threads). patch looks reasonable on first glance; I'll look further with the intention of committing soon-ish; bother me privately in a few days if I forget ;) (thanks!)
Please Help
I sent an email to that address and it failed. Can somebody please tell me what to do? Thank you all so much. smime.p7s Description: S/MIME cryptographic signature
Re: Please Help
On Tue, Jul 20, 2004 at 09:36:25PM -0400, Jeffrey K Pry wrote: I sent an email to that address and it failed. Can somebody please tell me what to do? Thank you all so much. I just unsubbed the address manually. In the future, please save the message you got when subscribing to a list to know how to unsubscribe, or look in the headers for unsubscribe instructions.
