Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Make sense of course. And if proxy_loadbalance and proxy_sticky are somewhat configurable, it will be to the benefits all of Apache 2 users, dependless HTTP/FTP/AJP. BTW, could we expect to be able to use in proxy_ajp URL like ajp://VIRTUALNAME, where VIRTUALNAME could be the name of an AJP cluster backend ? Also could we expect the handling of failure via mod_proxy + proxy_xxx , ie: when a tomcat respond 503 or 400, to be able to switch to another tomcat in the cluster. It's a mandatory feature for now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: Graham Leggett wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. I'm sure that the 'normalization' would lead to nowhere. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. HTTP is a statles protocol, and our concept is to have a constant connection pool to the well known application server. So, unlike HTTP protocol we are embedding the remote application server, and it just happens that we are doing it using the same TCP/IP protocol for that. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. Quite contraty, this is the main reason. We already have jk2 that can be used even for proxying HTTP requests. Are you wiling to write the http protocol for mod_jk2? The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. Again, application server != http server. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Agreed, pehaps some day they will convolve to the single module, but right now I don't see the point for it, especialy when the mod_proxy is well established module. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Well, that's how you see it. IMO trying again to squize the apache2-Tomcat module inside some already present solution would again lead to nowhere, and finally rise the questions like we are rising today. Not sure since mod_proxy will associate to a ajp://VIRTUALNAME, and in such case it's up to proxy_ajp to decide to : - keep the socket open - handle a pool of socket - fall back to another AJP instance in the cluster. So I think it could be done - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Costin Manolache wrote: But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. I think this is a good idea. Solve the general load balancer case first, then you will soon see whether HTTP works for everybody, or whether there is still a need for AJP. If there is a need, then someone will develop the AJP part of the module, but as the AJP module need not cocern itself with load balancing (that function being handled for it) it will be a far simpler module all round. Well we have a stable jk 1.2.6 to be released by the end of the week. So next step should be to add LB functionalities (with sticky JSSESSION support) in mod_proxy = Graham ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Costin Manolache wrote: Henri Gomez wrote: You must keep in mind that tomcat5 is no longer server.xml centric ! It can use separate config files in different directories, if it is embedded it can use the embedor's config, etc. And httpd.conf is static - you can't modify it. We support using httpd.conf for performance-versus-flexibility or for native auth - if you want to use the apache mapper and auth instead of jk mapper and tomcat auth. Well httpd.conf is static but nothing prevent from doing : Location /examples AjpWorker myworker /Location = All /examples goes to myworker, which could be a simple tomcat or a cluster. but the idea behind is to make updates to this 'myworker' from the behind, JMX or AJP13++/AJP14 link. And what if /examples context is removed ? Well = 404 Since myworker didn't have examples webapp, the resource is missing and unless you're in a cluster configuration, you should return a 404 error. Or a new context is dynamically added ? If a new context is added, you couldn't know it at httpd.conf edit time. Many cases here : - You didn't map it. - You map it to the worker but in such case you have to triple URI mapping, one in Apache 2, another in mod_ajp, and of course a third in tomcat, and using 3 mapping was something you asked us to avoid yesterday ;) What about /examples/protected/ which may need to be authenticated - if we really want to support play nice with other apache modules, then we need to support authentication using apache modules. Then what if the webapp is reloaded with a different protected uri ? /examples/protected/ should use the Apache auth as any other 'native' Apache URL isn't it ? In such case we should exclude it from direct mod_ajp processing, it should case later in the hooks process. That's the main problem with jk/jk2 today, since we can be part of the various modules chain with JkMount for example :( So IMO any jk config MUST be JMX-like. May be. Of course we should have somewhere in the new module the configuration tree in whatever native format we could imagine, apr_map maybe or apr_xml_tree if existing. File format is not important - dynamic changes and updates are the important issue. - the configuration should be in Apache's config file, rather than some complex properties file +1 See above. Apache config file is clearly better than any arbitrary static jk-specific config file. And it does provide close integration - including auth* using any of apache modules, and anything you can dream of in terms of apache modules. However - it is very static, and I doubt this will change soon. Even with apache2, if you change the config ( add a webapp ) you need to restart apache ( which may be interesting if multithreaded and some module is using sessions). Not necessary. Nothing prevent us from doing something like this : Location /*.jsp AjpWorker myworker /Location Location /servlet/* AjpWorker myworker /Location And if the mod_xxx is able to discover the webapp attached to myworker, you got them redirected to the correct worker. And you lose the real integration into apache - which is the ability to use other modules. It was a simple example, and today the real integration with apache is pretty bad in jk/jk2, that's why I'd like to use something as simple as EnvVars to determine if an URL should be mapped by mod_ajp. There is way too many hooks handled by jk/jk2 today, more than complex modules like proxy or rewrite and it could be a reason why jk/jk2 didn't works well with Location/Directory/Alias and others Apache 2 directive... My point is that we have 2 use cases, one is strong integration, where you want to use apache modules, and the other is dynamic, where you want to deal with a server where apps are often deployed or changed. Well we could do the both : - strong integration using hard-coded settings in httpd.conf - dynamic integration using a sort of AjpMount Dynamic Worker1 but in such case you have to handle a specific URI mapping in mod_ajp. You just can't support both use cases with the same solution - if you try, it's a lose-lose situation. I agree, that's why we should first work on strong integration, at least for URL to worker part. Nothing prevent us for instance to be able to update worker (direct or cluster) caracteristics dynamically, put mapping is hardcoded. The real important feature in jk2 is the JMX emulation - I know almost nobody uses it :-). Well the code is too complex in jk2, and that's also why we need some cleanups. I agree. However starting from scratch without having a flexible design that takes into account the dynamicity of tomcat is bound to result in another chunk of complex code ( after some time ), or something inflexible ( mod_webapp ? ). mod_webapp was a good idea, which came too soon (APR mandatory before Apache 2 release)... Without having a common codebase and API that can be used outside Apache2? I like apache2, but keeping the options open
Re: Some JK2 ideas v.3
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: I think you're mixing the Java side with the native side. I think the Java side should obviously use JMX to monitor what's going on with Tomcat. However, the native side will just recieve proprietary messages. We have to keep the native side as small and simple as possible to get into the HTTPD codebase. No, I'm only talking about the C side. Let's call it C-JMX. Instead of yet-another small and simple connector that grows out of control, it may be better to learn a lesson from java and apply it in C. Jk and Jk2 ( and mod_jserv ) all started small and simple, then got more and more features and fixes. If we start with just add custom proprietary messages for every feature we want to implement - the code will soon become very complex. Most of the messages are not in the critical path, so using a JMX model of get/set/event is reasonable. Monitoring and controlling the native code from java is IMO quite usefull and important by itself. Even Apache supports limited monitoring ( SNMP, mod_status, etc ). Ok. We'll see if I'm more convinced when you show your code ;) For now, I'm siding with Henri and his proposed solution. I'd like to heard some Apache 2 specialists here, may be some core HTTPD developpers since after all we're discussing an Apache 2.x module. I'll send an invitation to them in httpd-dev... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Mladen Turk wrote:
Costin Manolache wrote
I can understand the jk2 object oriented C is considered
too complex.
True.
But I certainly can't agree on a design that is not modular
and doesn't support this basic requirement. We already have
mod_jserv and mod_webapp
- and a long history of rewrite from scratch to make it simpler
turning into far more complex code.
But we don't wish to write something modular and unlimitedly extendable.
Just the load-balancing-ajp13+ over tcp/ip connector, for Apache2.
Having that in mind, we have APR, and 'almost' a finite set of requirements,
without the need to 'think modular' or 'think cross-webserver'.
Lot of the code would be reusable, but it would mean that making a mod_jni
connector would mean to make a completely different project without some
common directory holding shareable code.
Also making any additional 'features' to the connector (like 'discovery'
etc.) would have to be made as such, and enabled during compile time, so
that the basic functionality remains as is. This means that we don't compile
everything and then use the config to either enable or disable features, but
rather make something like 'mpm concept' selectable at compile time.
Seriously - if you take away the JMX and support for other
servers - why not just use mod_jserv ?
No one prevents you of making mod_jmx that will allow entire Apache2 to be
maintainable trough JMX console, not only our module :).
A great idea, but probably something which should be a whole new module,
mod_jmx or mod_cmx (C Management Extension). I'm sure the HTTPD team
will be more than pleased to discuss this.
Regarding other servers you meant IIS (other are less then couple of
percent) probably (apache13 users can use jk). I would like to make the
'real' IIS6 filter that will go in the NT kernel's http.sys, have dynamic
thread pool and MMC snap-in, but that is something completely different. Few
things like config tree, ajp protocol and transport can be reused cause now
we have the APR that generalizes the OS layer.
If you wish to write a good Apache2 module or IIS filter, they have to be
different projects. Also being usable from admins point of view requires
that the apache module is configurable trough httpd.conf, and IIS trough
GUI. None of them uses JMX to configure the webserver thought.
I have on my dash-board for a long time a project that will make a TC as a
main web server, having Apache as a 'slave' for additional PHP and Perl
support, but that also is something completely different and questionably
usable.
After all mod_jk and
jk2 got complex because of additional requirements and
features that we wanted to implement - if we drop them then
we can just go back and use mod_jserv.
Think that the main problem is that we don't understand the JK2 code any
more, and that the modularity combined with crosswebserver became an
obstacle rather then a feature.
Yes, that's a perfect resume of the current situation.
I don't have problem with writing clean C to make something
JMX/CMXizable but it appears to add some complexity.
Just take a look at the actual code in jk2 :(
...
int JK_METHOD jk2_channel_setAttribute(jk_env_t *env,
jk_bean_t *mbean,
char *name, void *valueP)
{
jk_channel_t *ch = (jk_channel_t *)mbean-object;
char *value = valueP;
if (strcmp(debug, name) == 0) {
ch-mbean-debug = atoi(value);
}
else if (strcmp(disabled, name) == 0) {
ch-mbean-disabled = atoi(value);
if (ch-worker != NULL)
ch-worker-mbean-disabled = ch-mbean-disabled;
}
else {
if (ch-worker != NULL) {
return ch-worker-mbean-setAttribute(env, ch-worker-mbean,
name, valueP);
}
return JK_ERR;
}
return JK_OK;
}
...
The problem with C is there is no introspection helper so we have
to do many things by hand and it tend to 'offuscate' the real code.
I'd rather like simple C way:
int ajp_channel_setDebug(jk_channel_t * channel, int debuglevel);
int ajp_channel_setState(jk_channel_t * channel, int state);
int ajp_channel_open(jk_channel_t * channel);
int ajp_channel_close(jk_channel_t * channel);
int ajp_channel_read(jk_channel_t * channel, apr_pool_t * buf);
int ajp_channel_write(jk_channel_t * channel, apr_pool_t * buf);
int ajp_channel_hasInput(jk_channel_t * channel);
That's one of the reason I suggested a specific Apache 2.x module,
to follow the HTTPD dev team habbits which are still plain C.
May be a pre-requisite to go farther will be to discuss with them
what should be a CBean ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.6 release ? - session tracking cookie
Bill Barker wrote: - Original Message - From: Sandy McArthur [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 19, 2004 9:15 PM Subject: Re: mod_jk 1.2.6 release ? - session tracking cookie On Jul 19, 2004, at 8:43 AM, Henri Gomez wrote: And since I couldn't delay the release to long, we need a quick reply, so thanks to take a look at it. We've setup a current CVS checkout of mod_jk at http://sp27en1.nerdc.ufl.edu/login.do which is load balancing to our webmail cluster. If you constantly reload the page you'll see it's setting a new JSESSIONID cookie on every request. Could you send us you workers.properties ? Yup. Sending the cookie almost always fails to stick. Sending the jsessionid via URL-rewriting always sticks. So it does look like there is a bug with the lb cookie parsing. I can't see by looking at the code what it is however :(. I can probably find a machine that I can hook up with the HEAD code and lb to see what is going wrong, but I can't promise when. If you feel like putting more work into this, adding 'fprintf(stderr,...)' statements should go to the Apache error_log. I've got such settings here, with 2 TC 3.3.2. Where did you want me put fprint ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Henri Gomez wrote: Mladen Turk wrote: The AJP13 protocol will have to be enhanced (or better enabled) to use the 'Service channel' and 'Data Filter'. It is not necessary to define all Service channel modes like server topology, or server readiness, neither to define all the Data Filter modes like cryptography or compression. I was thinking of something like 'extensions' to the protocol, meaning that one can extend the protocol to some desired level. Yes. My initial idea for AJP/1.4 wass to mix on the same wire request forwaring which is the core functionnality of AJP/1.3 with system messaging. - Service channel is a channel to send/received update between Apache and Tomcats : - Negociation between Apache and Tomcat. * Should we use an authentification scheme between Apache and Tomcat (ajp1.3 make that Tomcat trust any Web server caming via AJP13). * Should we compress the requests/replies * Should we crypt the requests/replies. - Web Applications state updates : * a Web Application is added * a Web Application is removed - Updates in cluster configurations : * worker1 was handling 25% of total load, now it could handle 35%. * worker2 in cluster is down for maintenance * Apache 2 could use worker3 for this cluster, it could reach it at IP/PORT Ideally since we could have a cluster of Apache WebServer linked to a cluster of Tomcat ServletEngines, and that member could enter or exit these 2 clusters we should have something using Multicast (ideally a native JavaGroups) for both side. With such the configuration in both Web and Tomcat clusters will be to enter a Service Channel where all members will get all the services messages and handle them accordingly ? What about multicast support in APR ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Mladen Turk wrote: -Original Message- From: Henri Gomez Ideally since we could have a cluster of Apache WebServer linked to a cluster of Tomcat ServletEngines, and that member could enter or exit these 2 clusters we should have something using Multicast (ideally a native JavaGroups) for both side. Wow, you've push it to the limit :) With such the configuration in both Web and Tomcat clusters will be to enter a Service Channel where all members will get all the services messages and handle them accordingly ? What about multicast support in APR ? Each node would need both server and client listeners, so they can exchange service messages. But I'm not sure that I wish to see that in the core itself. It brings an extra complexity that is needed in 'not-an-everyday usage'. Something like should either be a different project or at least manageable at compile time. No this settings will be for mod_ajp 2.x :) We should focus now on mod_ajp 1.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [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? - 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Costin Manolache wrote: Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. I think AJP has advantages, but if the HTTPd folks only accept a simple solution based on mod_proxy, then so be it, it'll be our entry level connector. The discussion is still open :) BTW, we could imagine that even AJP/1.4 topology update could came from HTTP/1.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: Invitation to HTTPD commiters in tomcat-dev]
---BeginMessage--- 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 ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time for JkMountExclude in jk 1.2.x ?
Glenn Nielsen wrote: Have you looked at using JkAutoAlias ? What do you means ? JkAutoAlias automatically detected Alias/Directory and excluded them from JkMount * ? On Tue, Jul 13, 2004 at 12:27:41PM +0200, Henri Gomez wrote: Hi to all, As many I'm puzzled in jk 1.2.x in some case : VirtualHost *:80 ServerName test101.mysys DocumentRoot /www/sys101/htdocs JkMount /* test-101 /VirtualHost VirtualHost *:80 ServerName test102.mysys DocumentRoot /www/sys102/htdocs JkMount /* test-102 /VirtualHost No imagine I want to have /home in test102.mysys mapped no more to tomcat but to local directory. VirtualHost *:80 ServerName test102.mysys DocumentRoot /www/sys102/htdocs JkMount /* test-102 Alias /home/ /www/sys102/home/ Directory /www/sys102/home Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all /Directory /VirtualHost There is no way to get http://test102.mysys/home goes to /www/sys102/home local directory. What about adding support for JkMountExclude : VirtualHost *:80 ServerName test102.mysys DocumentRoot /www/sys102/htdocs JkMount /* test-102 JkMountExclude /home/* Alias /home/ /www/sys102/home/ Directory /www/sys102/home Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all /Directory /VirtualHost These will prevent JkMount to forward /home/* to tomcat worker test-102. Thanks to comments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [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 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: Henri Gomez wrote: 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. Or maybe just a channel for passing config data ( but leave request passing to mod_proxy ) ? I.e. the only thing that will remain in mod_ajp will be the autoconf and monitoring. - 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 Can we simplify this ? Let's drop the word worker too :-) The request is passed to a servlet container that may consist of one or multiple instances. Agreed, remove the old terms. The proposal about mod_proxy + proxy_ajp could be something fine isn't it. And proxy_ajp could map to a dynamically updated ajp resource ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: Invitation to HTTPD commiters in tomcat-dev]
---BeginMessage--- 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 ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Mladen Turk wrote: -Original Message- From: Remy Maucherat - it should be simpler than JK 1 or 2 That's the general idea - it should have a name which doesn't confuse folks :) APR_JAVA as static core lib + mod_javalink? For example I wish to make a WIN2003 http.sys kernel module. - No JNI in this module IMO: I think it would be better to have another separate module dedicated to JNI (and trying to use, for example, the in memory protocol handler or similar techniques) if there's interest, rather than add complexity to this module, which has very different needs As said in the initial post. The JNI has to be a separate project, as well as any other 'bizarre' communication rather then TCP/IP Agreed for JNI for jk, I'd rather like to see a return of the old mod_java. TCP/IP and Unix socket could share about 95% of code but we could start with TCP/IP only. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.6 release ? - session tracking cookie
Sandy McArthur wrote: Thinking on it more, I think I'm full of it and I was confusing the symptoms of two problems that were happening at the same time. Disregard my comments below until I can double check myself. Sandy On Jul 15, 2004, at 6:01 PM, Sandy McArthur wrote: On Jul 15, 2004, at 3:05 AM, Henri Gomez wrote: Could you take the latest code in CVS and check to see if it solve your problem ? We took the new get_cookie() implementation from CVS and replaced the one in our mod_jk 1.2.5 package and all hell broke loose. The jvmroute of the JSESSIONID cookie weren't being respected and users coudn't do anything in our load balanced setup because they were getting new JSESSIONID cookies on each request. We reverted very quickly so I didn't get a good chance to debug it. Tomorrow we'll test mod_jk from CVS to make sure it wasn't a problem with the new get_cookie() in the 1.2.5 version. I've manually followed the new get_cookie() code and it looks right to me but I'm nervous about it for now. I'd like to know if anyone else has had success with the new get_cookie() in a load balanced setup. I'm waiting for your reply to tag and make jk 1.2.6 release. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas
Cavan Morris wrote: Andy Armstrong wrote: I have concrete examples of people giving up on Tomcat altogether for no other reason than the fact that they couldn't get JK configured. By comparison the rest of the task of configuring Tomcat is a walk in the park. Please let's not be so up ourselves that we forget that it's nice for people to actually be able to use the software. As a lurker on this list I can give myself and everyone I've ever worked with as concrete examples of some people that have given up on 4.1+ tomcat because of JK configuration. I can count at least 12 projects I have worked on, or am working on, that are still on Tomcat 4.0.6 with mod_webapp because we could never get JK to do what we wanted. That is, mount this webapp at that URI in one line and be done with it. All the other JK features are great but 90% of the configurations are going to be like the one I just described and no one can figure out how to do it. Could you send us your configuration for all these projects and we'll give you httpd.conf / workers.properties settings. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Remy Maucherat wrote: My turn :) Sorry, I won't help code it (well, maybe a little for the Java part); so I don't know if I have a say in any decision, but I though I should participate as well. - it should be simpler than JK 1 or 2 Of course. - it should have a name which doesn't confuse folks :) mod_whatever, I was thinking for something like mod_coyote or mod_jtc. - Apache 2.x specific using APR (with the goal being the inclusion in the Apache distribution as a default module: no more compilation problems, etc); for other servers, I think we should keep the current JK - it should try to optimize keepalive if possible for performance No idea, should take a look more in Apache 2.x :) - it should support quality of service (messages to notify that a webapp is being serviced on one node, etc) Simple extensions to ajp13 / ajp14. We should first determine if Apache2 will have to monitor a service/system links to the various tomcats (in cluster configuration) to learn about real-time topology. - (nice to have) it should be possible to configure the cluster dynamically See previous comment. - there should be a clear documentation for which connector to use (I'm not talking about specific needs, but general case: one server - standalone HTTP/1.1, cluster - mod_newthing) oki - the configuration should be in Apache's config file, rather than some complex properties file +1 - it should have good defaults (I like good defaults :) ) Well we should at least know a default worker. - it should work well with other modules (I guess if somehow it is accepted into the Apache codebase, it will be required) That's why we should focus on Apache 2 only module. - I think the protocol should be an extension of AJP/1.3 I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it could be a good candidate. In my idea we should start to write an APR based AJP/1.4 library, which could be first used outside Apache 2 server for test and benchs purposes. Also we should start with something working with both TC 3.3.x, 4.1.x and 5.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Mladen Turk wrote: -Original Message- From: Henri Gomez We should first determine if Apache2 will have to monitor a service/system links to the various tomcats (in cluster configuration) to learn about real-time topology. In fact, that is why I've pursued the .xml config over the current one. The main idea is to _internally_ have config tree (right now we don't have that). So that internal configuration tree will be populated either using directives in the native httpd.conf or reading server.xml stream from TC or from file. Of course we should have somewhere in the new module the configuration tree in whatever native format we could imagine, apr_map maybe or apr_xml_tree if existing. - the configuration should be in Apache's config file, rather than some complex properties file +1 The general idea is to connect to TC and get the URI/VHOST topology, but we still need the 'intervene' directives for connector specific ones. How to make them simpler to use the JK and JK2? Perhaps using something like: CoyoteWorker workerA ...directives /CoyoteWorker I agreed for this on worker configuration in httpd.conf. And then: Files *.jsp CoyoteUsesWorker workerA /Files ok. We should also be able to handle : Location /myspecialurl CoyoteUsesWorker workerA /Files Something very familiar to Apache admins. - it should work well with other modules (I guess if somehow it is accepted into the Apache codebase, it will be required) That's why we should focus on Apache 2 only module. Not sure I'm in favor of that (unless you meant dropping 1.3 module by that). Of course, I want a module designed for Apache 2.x (2.0/2.1). Apache 1.3 could live with jk 1.2.x. IIS/NES/DOMINO could use jk 1.2 or jk2. No more code complexity to handle all the web-servers around, we should focus on Apache 2.x. For example majors Linux distributions are now using Apache 2 instead of Apache 1.3. So Apache 2.x will be more and more used. Without having a common codebase and API that can be used outside Apache2? We should discuss what will be in the API, some will be only APR dependant, but of course many will be dependant of Apache 2.x, for examples Apache requests. But we could see simple call, like : int xxx_forward_simple_request( xxx_worker_t *, apr_pool_t * req_uri, apr_pool_t * reply_data); int xxx_forward_simple_post_request( xxx_worker_t *, apr_pool_t * req_uri, apr_pool_t * post_data, apr_pool_t * reply_data); int xxx_forward_full_request( xxx_worker_t *, apr_pool_t * req_uri, apr_table_t * headers, apr_pool_t * post_data, apr_pool_t * reply_data); In that case why not write only proxy_coyote for mod_proxy? Since it will be nice to be able to be warned in mod_xxx from real-time topology updates, ie application down on one tomcat, new application on another tomcat, cluster updates... - I think the protocol should be an extension of AJP/1.3 I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it could be a good candidate. In my idea we should start to write an APR based AJP/1.4 library, which could be first used outside Apache 2 server for test and benchs purposes. +1, but in contradiction with previous :). I would also like to see the gzip like extension to AJP/xx for lowering the data transfer. It was proposed some times ago together with some light crypto to secure apache - tomcat link when you're not in a secure network. All of these could be made optional in protocol negociation side of AJP/14... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Mladen Turk wrote: -Original Message- From: Remy Maucherat For example majors Linux distributions are now using Apache 2 instead of Apache 1.3. So Apache 2.x will be more and more used. When not running inside Apache, there are tons of things when cannot use, including configuration. So the best is indeed to keep JK around for supporting other servers. One of the big problems is that it would be best to keep developing either jk 1.2.x or jk 2.0.x, but not both ;) Ok, but let's try to make the code 'reusable', protocol and basic config tree should be in a separate files, so that we can aventually make something simmilar for other web servers if there will be enough interest, or make a generic 'apr/apr-util' like library, so everything that uses 'ap_xxx' calls should go in mod_coyote. Second reference to mod_coyote ? Should we retains this one ? Remy :;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Mladen Turk wrote: -Original Message- From: Remy Maucherat For example majors Linux distributions are now using Apache 2 instead of Apache 1.3. So Apache 2.x will be more and more used. When not running inside Apache, there are tons of things when cannot use, including configuration. So the best is indeed to keep JK around for supporting other servers. One of the big problems is that it would be best to keep developing either jk 1.2.x or jk 2.0.x, but not both ;) Well I'd like to see jk 1.2.x continuing its slow maintenance cycle since it's the most used module for now. And start from scratch the new mod_coyote. Ok, but let's try to make the code 'reusable', protocol and basic config tree should be in a separate files, so that we can aventually make something simmilar for other web servers if there will be enough interest, or make a generic 'apr/apr-util' like library, so everything that uses 'ap_xxx' calls should go in mod_coyote. Well if we want mod_coyote included in Apache 2.x tree, we shouldn't have too much files. Also I'd like to avoid too many wrapper calls functions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.6 release ? - session tracking cookie
Sandy McArthur wrote: On Jul 19, 2004, at 4:06 AM, Henri Gomez wrote: Sandy McArthur wrote: Thinking on it more, I think I'm full of it and I was confusing the symptoms of two problems that were happening at the same time. Disregard my comments below until I can double check myself. Sandy On Jul 15, 2004, at 6:01 PM, Sandy McArthur wrote: On Jul 15, 2004, at 3:05 AM, Henri Gomez wrote: Could you take the latest code in CVS and check to see if it solve your problem ? We took the new get_cookie() implementation from CVS and replaced the one in our mod_jk 1.2.5 package and all hell broke loose. The jvmroute of the JSESSIONID cookie weren't being respected and users coudn't do anything in our load balanced setup because they were getting new JSESSIONID cookies on each request. We reverted very quickly so I didn't get a good chance to debug it. Tomorrow we'll test mod_jk from CVS to make sure it wasn't a problem with the new get_cookie() in the 1.2.5 version. I've manually followed the new get_cookie() code and it looks right to me but I'm nervous about it for now. I'd like to know if anyone else has had success with the new get_cookie() in a load balanced setup. I'm waiting for your reply to tag and make jk 1.2.6 release. I double checked our setup and our attempt to patch mod_jk 1.2.5 with the new get_cookie implementation and found that request were *not* being forward to the right clone based on the jvmroute part of the JSESSIONID cookie. I have not had time to test a current CVS checkout of mod_jk in a load balanced setup. Well the patch was release to fix your problem and correct what could be a serious problem in jk 1.2.x and I'd like to know if it's fixed before making the 1.2.6 release. And since I couldn't delay the release to long, we need a quick reply, so thanks to take a look at it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
[EMAIL PROTECTED] wrote: Just my 2 pence worth (as an apache/tomcat admin in a large company); - the configuration should be in Apache's config file, rather than some complex properties file +1 Yes please! The general idea is to connect to TC and get the URI/VHOST topology, but we still need the 'intervene' directives for connector specific ones. How to make them simpler to use the JK and JK2? Perhaps using something like: CoyoteWorker workerA ...directives /CoyoteWorker I agreed for this on worker configuration in httpd.conf. And then: Files *.jsp CoyoteUsesWorker workerA /Files ok. We should also be able to handle : Location /myspecialurl CoyoteUsesWorker workerA /Files Something very familiar to Apache admins. Excellent point in that it needs to be similar to other apache directives. - it should work well with other modules (I guess if somehow it is accepted into the Apache codebase, it will be required) That's why we should focus on Apache 2 only module. Hum, but Not sure I'm in favor of that (unless you meant dropping 1.3 module by that). Of course, I want a module designed for Apache 2.x (2.0/2.1). Apache 1.3 could live with jk 1.2.x. IIS/NES/DOMINO could use jk 1.2 or jk2. No more code complexity to handle all the web-servers around, we should focus on Apache 2.x. For example majors Linux distributions are now using Apache 2 instead of Apache 1.3. So Apache 2.x will be more and more used. true. But from experience most admins will not use the vendor (Sun/Redhat/IBM etc ...) supplier widget as this widget is subject to a vendors patching schedule. Hence most admins install their own version outside the normal file system hierarchy. So, be in mind that people like me still use 1.3 for many reasons, although some have moved to 2.x. What I am trying to say is that do not dismiss 1.3.x unless it is difficult to include. Well if we had to support Apache 1.3, will have to support two very different web-server and could make use of APR since Apache 1.3 came without APR. And in such case, we'll have to spend time on -dev and -users list to explain how to make Apache 1.3 with APR support, a waste of time. If admins want to stay with Apache 1.3, no problem for me, they'll have to stay with mod_jk 1.2.x. - I think the protocol should be an extension of AJP/1.3 I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it could be a good candidate. In my idea we should start to write an APR based AJP/1.4 library, which could be first used outside Apache 2 server for test and benchs purposes. +1, but in contradiction with previous :). I would also like to see the gzip like extension to AJP/xx for lowering the data transfer. It was proposed some times ago together with some light crypto to secure apache - tomcat link when you're not in a secure network. All of these could be made optional in protocol negociation side of AJP/14... Crypto and compression would be a very good addition - although not to ignore the simple connection as it needs to be quick/efficient! Compression and crypto are negociated at AJP nego time, see the part about MD5 use in both native and java side. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Mladen Turk wrote: -Original Message- From: Henri Gomez Well I'd like to see jk 1.2.x continuing its slow maintenance cycle since it's the most used module for now. And start from scratch the new mod_coyote. Ok, but let's try to make the code 'reusable', protocol and basic config tree should be in a separate files, so that we can aventually make something simmilar for other web servers if there will be enough interest, or make a generic 'apr/apr-util' like library, so everything that uses 'ap_xxx' calls should go in mod_coyote. Well if we want mod_coyote included in Apache 2.x tree, we shouldn't have too much files. Also I'd like to avoid too many wrapper calls functions. protocol, transport, config, log, utils and mod. (cca 6 files + 2 includes). Seems reasonable. So, what cannot be build without ap_api should go to mod_ file itself. Also all the config should be API based (not directly setting elements). Example please ? The main purpose is to able to 'reuse' the code, but not directly, so that it's core parts like config, protocol and transport can be ported to other servers, with 'reasonably' low efforts. Ok. By that I mean that if we need to read from the server we use the high-level function that will do that, (probably wrapping few ap_xxx calls). It's only a matter of 'strategy' used :). Of course. Also having a ajp style library could help us make so AJP based stress tests applications, a little like ApacheBench. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Remy Maucherat wrote: Henri Gomez wrote: Second reference to mod_coyote ? Should we retains this one ? Maybe ;) We have two connectors planned. This one will use AJP, while the other would use JNI, so we need two, different, non confusing names. So naming this mod_jk3 would be bad, just like naming the two mod_coyote1 and mod_coyote2. So when will we get all these new shiny toys ? :) Well we should first discuss for : - a name :) - what features will be mandatory in the initial release. - library/modules repartition You speak about AJP and JNI, so I suggest 2 differents projets : mod_ajp mod_jni Both will be Apache 2.x modules to link an Apache web-server with tomcat(s) using AJP 1.3++ (AJP 1.4) protocol (mod_ajp) or JNI connectiviy (mod_jni). I could works on mod_ajp, taking the best parts of jk/jk2, and putting the basic bricks in an ajp library. Of course we'll need to see how to make this ajp library with real world, for instance I think we could follow the Mladen idea, ie having a configuration structure (tree) located in memory and updated via call to the API : ajp_config_t * create_ajp_config(); int add_ajp_worker(ajp_config_t * conf, ajp_worker_t * wrk); int remove_ajp_worker(ajp_config_t * conf, ajp_worker_t * wrk); int update_ajp_worker(ajp_config_t * conf, ajp_worker_t * wrk); int destroy_ajp_config(ajp_config_t * conf); Ad minima we should have workers in the configuration. To remove the work to rewrite the URI to worker part, we could start with a mapping using Apache 2 directive ie Location/EnvVars/Files... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.2
Costin Manolache wrote: Mladen Turk wrote: Hi, All (except Costin) developers has to say something, so my conclusion is that we are not dead after all ;) I'm alive as well, and I have something to say - I spent last few weekends playing with coyote and tomcat, probably in few weeks I'll have something working and I'll get back. Seems that the major obstacle is the configuration, so I propose that we forget that for a while, and make a 'generalized' environment that will sattisfy all the 'needs'. That environment could be called APR_JAVA and it will be resposible for os-java communication, having AJPXX, and 'JNI' as one of the possible protocol stacks. It will have a generic mapping mechanism (pcre enabled) for registering URI mapings, setting communication properties, so that one could make a suport from any container (webserver). URI mapping is already duplicated in the web server and catalina, please not a third mapper :-) Of course, and we could start with a simple mapper using Location/EnvVar. It will abstract the container-java communication to the level of 'directory and file' so that one can open a connection to TC like opening a file, or simply speaking a 'Virtual File System', so that one can either 'mount' a volume like '/servlets' or a file filter like '*.jsp' Depends on what you want :-). Request forwarding from server and tomcat works reasonably well, it's the other stuff that is hard, and it doesn't map so well to VFS model ( auth, conf, etc ). Request forwarding is still the main feature, but we'd like to some dynamic topology (webapp discovery, cluster state updates...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
[EMAIL PROTECTED] wrote: What I am trying to say is that do not dismiss 1.3.x unless it is difficult to include. Well if we had to support Apache 1.3, will have to support two very different web-server and could make use of APR since Apache 1.3 came without APR. Ah ok - so this is complex to make it work with 1.3.x. And in such case, we'll have to spend time on -dev and -users list to explain how to make Apache 1.3 with APR support, a waste of time. Agreed. If admins want to stay with Apache 1.3, no problem for me, they'll have to stay with mod_jk 1.2.x. ok - just need to make this clear in the docs/how-to's. Crypto and compression would be a very good addition - although not to ignore the simple connection as it needs to be quick/efficient! Compression and crypto are negociated at AJP nego time, see the part about MD5 use in both native and java side. Ah appologies I though crypto would mean SSL'ing the link or encypting the AJP contents with AES/Blowfish et al. It could of course, all we need is a fast crypto protocol, and more important something ALLREADY available in APR/Apache2/Java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Costin Manolache wrote: We should first determine if Apache2 will have to monitor a service/system links to the various tomcats (in cluster configuration) to learn about real-time topology. In fact, that is why I've pursued the .xml config over the current one. The main idea is to _internally_ have config tree (right now we don't have that). So that internal configuration tree will be populated either using directives in the native httpd.conf or reading server.xml stream from TC or from file. You must keep in mind that tomcat5 is no longer server.xml centric ! It can use separate config files in different directories, if it is embedded it can use the embedor's config, etc. And httpd.conf is static - you can't modify it. We support using httpd.conf for performance-versus-flexibility or for native auth - if you want to use the apache mapper and auth instead of jk mapper and tomcat auth. Well httpd.conf is static but nothing prevent from doing : Location /examples AjpWorker myworker /Location = All /examples goes to myworker, which could be a simple tomcat or a cluster. but the idea behind is to make updates to this 'myworker' from the behind, JMX or AJP13++/AJP14 link. So IMO any jk config MUST be JMX-like. May be. Of course we should have somewhere in the new module the configuration tree in whatever native format we could imagine, apr_map maybe or apr_xml_tree if existing. File format is not important - dynamic changes and updates are the important issue. - the configuration should be in Apache's config file, rather than some complex properties file +1 See above. Apache config file is clearly better than any arbitrary static jk-specific config file. And it does provide close integration - including auth* using any of apache modules, and anything you can dream of in terms of apache modules. However - it is very static, and I doubt this will change soon. Even with apache2, if you change the config ( add a webapp ) you need to restart apache ( which may be interesting if multithreaded and some module is using sessions). Not necessary. Nothing prevent us from doing something like this : Location /*.jsp AjpWorker myworker /Location Location /servlet/* AjpWorker myworker /Location And if the mod_xxx is able to discover the webapp attached to myworker, you got them redirected to the correct worker. The real important feature in jk2 is the JMX emulation - I know almost nobody uses it :-). Well the code is too complex in jk2, and that's also why we need some cleanups. Without having a common codebase and API that can be used outside Apache2? I like apache2, but keeping the options open is pretty important. Tomcat can be integrated in more than Web servers :-) Of course but many users and admins are confused in using jk2 with Apache 2 for example. Too many way to do the same conf make jk2 a difficult thing and that's why many stay on jk 1.2.x If you have a good infrastructure ( library ) for dynamic config and request forwarding - why not keep it reusable for other applications, even for things besides tomcat. Well if other application want to access an embedded tomcat, they could use JNI or direct Java calls ? Having a closeley integrated variant ( using this library ) is a great idea, and it would be even better if this could be bundled with apache. Of course that's the idea, having a resonable module which could came with Apache 2.x distributions, following the same code standards (ie using apr_/ap_) and also the same documentation format (the HTTPD 2.0 documentation is really clear). We should discuss what will be in the API, some will be only APR dependant, but of course many will be dependant of Apache 2.x, for examples Apache requests. But we could see simple call, like : int xxx_forward_simple_request( xxx_worker_t *, apr_pool_t * req_uri, apr_pool_t * reply_data); int xxx_forward_simple_post_request( xxx_worker_t *, apr_pool_t * req_uri, apr_pool_t * post_data, apr_pool_t * reply_data); int xxx_forward_full_request( xxx_worker_t *, apr_pool_t * req_uri, apr_table_t * headers, apr_pool_t * post_data, apr_pool_t * reply_data); In that case why not write only proxy_coyote for mod_proxy? Since it will be nice to be able to be warned in mod_xxx from real-time topology updates, ie application down on one tomcat, new application on another tomcat, cluster updates... This may be a good feature for mod_proxy as well BTW :-) mod_proxy didn't support clustering :( - I think the protocol should be an extension of AJP/1.3 I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it could be a good candidate. In my idea we should start to write an APR based AJP/1.4 library, which could be first
Re: Some JK2 ideas v.3
Costin Manolache wrote: Remy Maucherat wrote: My turn :) Sorry, I won't help code it (well, maybe a little for the Java part); so I don't know if I have a say in any decision, but I though I should participate as well. - it should be simpler than JK 1 or 2 +1 - it should have a name which doesn't confuse folks :) mod_tomcat would be good. - Apache 2.x specific using APR (with the goal being the inclusion in the Apache distribution as a default module: no more compilation problems, etc); for other servers, I think we should keep the current JK That's good if it means generic library plust apache2 specific code, but it's really bad if it means all new functionality will only work in apache2 and for all other servers ( and no-server use cases ) we'll be stuck with jk. - it should try to optimize keepalive if possible for performance - it should support quality of service (messages to notify that a webapp is being serviced on one node, etc) - (nice to have) it should be possible to configure the cluster dynamically I would upgrade this to MUST have, not only for cluster but also webapps. Tomcat5 is pretty dynamic. If this is missing - why bother ? - there should be a clear documentation for which connector to use (I'm not talking about specific needs, but general case: one server - standalone HTTP/1.1, cluster - mod_newthing) - the configuration should be in Apache's config file, rather than some complex properties file -0 - apache config file is the best choice for 'close integration', but it can't be used in a JMX-like dynamic environment. There are use cases where you want one, but the other is as important. - it should have good defaults (I like good defaults :) ) Big +1. - it should work well with other modules (I guess if somehow it is accepted into the Apache codebase, it will be required) - I think the protocol should be an extension of AJP/1.3 +1 - or a standard, existing protocol. No new arbitrary protocols. ( XDR subset remains my favorite ). Well AJP/1.3 exist on TC 3.3.x, 4.1.x and 5.x. Adding some Ajp/1.3++ features is just evolution, not a complete rewrite like an XDR based coyote connector. - No JNI in this module IMO: I think it would be better to have another separate module dedicated to JNI (and trying to use, for example, the in memory protocol handler or similar techniques) if there's interest, rather than add complexity to this module, which has very different needs What complexity does JNI add to jk2 ? There are separate files, using the same protocol. Many and add minima that HTTPD 2.0 didn't require JNI. Frankly I'd prefer to see JNI in a mod_java project instead... The real important lesson in Jk2 is that JNI works faster and better if it is not used to pass objects. The only 2 JNI models that actually work are jk2 protocol marshalling, pass only byte[] and eclipse swt small simple calls with mostly int and byte[] params JNI stuff could goes in mod_jni/mod_java, less complexity, no users/admins questions about auto-configuring/compiling/setup... = Better acceptation by Apache 2.x admins for the mod_ajp module - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: What complexity does JNI add to jk2 ? There are separate files, using the same protocol. The real important lesson in Jk2 is that JNI works faster and better if it is not used to pass objects. The only 2 JNI models that actually work are jk2 protocol marshalling, pass only byte[] and eclipse swt small simple calls with mostly int and byte[] params All that is cool, but what you propose looks a lot like JK 2 (JMX dynamic features, support for many webservers, etc), and we know that almost no developer understands it anymore. This clashes head on with the it has to be simple requirement: how do you expect the issue to be solved ? JMX seems to simplify tomcat5 pretty well, and I think it would be a big lost if we would say 'let's simplify tomcat5 and remove jmx'. If you don't have the ability to deal with the changes in the cluster and the added/removed webapps - why bother, just use mod_proxy and you're done. Why write a special connector if it wouldn't take advantage of almost any tomcat benefit ? Regarding multiple servers - if JMX, then the code will probably have some modularity that would allow this anyway. One thing is clear - if you start with the idea let's not have JMX, may be will add it later, it'll be impossible to do it. That's what we tried in jk2, and it's not very nice. If you start with a dynamic design - and take into account the implications on config, code structure, etc - then it may be a bit more complex that the simplest connector, however you'll have a good base for future changes. Well JK2 inherited too many things from the past and add too many features to be used today. I'd rather prefer a pragmatic approach : - step 1: rewrite mod_ajp module with simplicity and Apache 2.x admin habbits in mind, with simple real worker. Decent documentation about this first version. - step 2: add load-balancing support in using ajp/network and also good documentation about it. - step 3: add JMX-like features by handling special URL (ajp-handler or via AJP/1.3 and provide a good JMX support console for it. This is the point about dropping server portability, among other things. Sorry to say it aloud, but for new developments I don't care about IIS (it should die) nor Apache 1.3, which are the two other servers that matter. To support these, we have mod_jk 1.2 (and too bad if people don't get the extra features). One of the things I'm very interested in is getting tomcat connected with other, non-web server applications. I realize this is crazy and most people don't need such a thing - but we all have crazy ideas, and it happens that having a generic support that works for IIS or iPlanet will also allow other kinds of connectors. Don't use mod_ajp for this, but use the ajp library with custom code. If JMX is used, then it'll require modularity which will then allow other connectors based on the same components. JMX is great but a good console will be required... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas
Costin Manolache wrote: Jess Holle wrote: Andy Armstrong wrote: Jess Holle Getting the IIS connectors to work with IIS 6 appears to be rocket science though. [Dang thing just shows a red down arrow on the filter whatever you do without giving any real error!] Heh. Having spent two days getting the filter to work on IIS I'm thinking about starting to sell a consultancy service based on getting JK2 working. I actually wrote, debugged, documented and delivered a non trivial ISAPI filter for a different project in less time than it took me to get JK2 working. This is the JK, nor JK2, based connector in my case, but: 1. There are documented missing configuration steps out on the web for IIS 6 that should be verified and placed in the Tomcat isapi documentation. 2. Any hint as to what to do other than start over again and hope for better luck would be great appreciated. [I used the 'isapi_install.vbs' script in hopes of having fewer error-prone manual steps. Was that a bad idea?] I'd have kept this off the 'dev' group, but item (1) is quite glaring at this point in that there are many reports that one cannot use the Tomcat connectors with IIS 6 without extra configuration steps beyond what the Tomcat docs provide. Maybe the best response to this would be to update the docs and say tomcat IIS 6 is not supported, plese contact microsoft and ask them to do it. They have plenty of developers and money - they could send a check to Andy and Henri, or do it themself :-) No ask M$ to make a donation to ASF... It's better then having people struggle with mod_jk config and feeling it's tomcat developer's job to support IIS. You could also suggest IIS users to switch to Apache 2.0.50 for Windows :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.0.26 release ? - session tracking cookie
Sandy McArthur wrote: On Jul 14, 2004, at 11:17 AM, Henri Gomez wrote: jk 1.2.6 seems to be in a good shape and a release should be welcome for many users. I'd like to release jk 1.2.6 next week. Any objections ? I have one gripe with the way mod_jk chooses the session tracking cookie. I'm not a dev but I just tracked down a bug that has been causing us, University of Florida, some pain for a few weeks. I'm currently verifying that I'm not full of it before I filed a bug report but the short version is: mod_jk seems to pick the first cookie ending in JSESSIONID such as PSJSESSIONID as opposed to what the servlet spec says in section 7.1.1: The name of the session tracking cookie must be JSESSIONID. Take a look at the get_cookie function in jk_lb_worker.c and walk though it with input similar to: Cookie: PSJSESSIONID=FOOBAR; JSESSIONID=BAZZORK.jvm# I take a look at this and fix if simple :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.0.26 release ?
nyhgan wrote: Hi, Does mod_jk 1.0.26 fix the following problem? I believe that it is the one of the most important issues with the mod_jk. What's the exact problem ? I'm using jk 1.2.5 with Apache 2.0 and Tomcat 3.3.2 and handle about 300 000 req/days and never got this problem. Explain and detail please. nyhgan [EMAIL PROTECTED] wrote: Exactly. I have been on this user list for months and I still haven't seen anyone solve the mod_jk connector issue for apache and tomcat 4.1.x or above. Now, I switch back to use Tomcat3.3 instead because it runs more stable than tomcat4.x and 5.x We can't wait forever like this. Maybe some experience c++ programmers out there can take a look at the source code for mod_jk and see if the problem can be fix. Galam. Daniel Gibby [EMAIL PROTECTED] wrote: All I can say is you are not alone. Requests of our sort never seem to be answered, and we've been asking them for months. Actually, by being answered I'm not saying that people don't post replies, I just mean that I don't know of anyone who has fixed this issue on their system. It sure sounds like the same issue that I'm having with mod_jk2 2.0.2, apache 2.0.40, tomcat 4.1.30 or tomcat 4.1.27... but I can't be sure that it is the same issue. My bet is that most of the tomcat developers don't use connectors because they would rather keep things stable, and introducing apache into the mix just means one more point of failure. Sorry I can't be of more help right now. I've tried using JMeter to reproduce my lockups, and that hasn't helped me yet. Is there someone out there who would like to be paid to run a profiler on some of my applications? Please contact me off-list, and if you can solve my issue, I'll post the results to the list... I'm in contact with two or three people from this list that are having the same type of issues, and more requests for help come into the list weekly. We'd all be happy for the help. Daniel Gibby Beat De Martin wrote: Hello folks I'm using Tomcat 3.3.1, Apache 1.3.27 and mod_jk 1.2.4. Every two days my Tomcat hungs and I have to restart it. Before Tomcat hungs I can see the following in mod_jk.log: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. err=-1 [jk_ajp_common.c (1137)]: Error reading reply from tomcat. Tomcat is down or network problems. [jk_ajp_common.c (1290)]: ERROR: Receiving from tomcat failed, recoverable operation. err=0 [jk_ajp_common.c (1309)]: sending request to tomcat failed in send loop. err=0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas
Andy Armstrong wrote: Mladen Turk wrote: In contrary, it makes it simpler, cause you have a common denominator, and that is 'well documented' config file, usable on any container. Well documented is the crux here for me. Or at least readily understandable. I've just had someone nearly abandon Tomcat altogether because they had a problem (with file uploads) that required the latest version of the IIS connector but they couldn't find out how to configure it. I find it frustrating that we're an Apache project but we're currently nowhere near Apache in usability terms. Right now running Tomcat with another webserver is a scary proposition. All the JK code has to do is forward eligible requests from the host web server to Tomcat. I'm afraid that right now it behaves like a self indulgent vanity project with aspirations above its station. With appropriate apologies for the toes that I'm treading on why tge hell is JK so convoluted? There is weeks I'm thinking about another approach for Apache to Tomcats (AJP13) requests relaying. My idea is about a new module, only Apache 2.x for now, which will make use of SetEnv, SetEnvIf, BrowserMath and Location directives to redirect some URLs to tomcats via AJP. Many users complains about problems between Directive, Location, JkMount and of course the configuration complexity of JK and JK2, and yes jk/jk2 are big when you compare them to modules like mod_rewrite or mod_proxy. What I'd like will be a true Apache module where all settings will be in httpd.conf, a module where there will be only one way to configure or define something (which is not the case for JK2 for instance). After all we're ASF commiter and making a specific Apache 2.x connector seems a reasonable goal. The code in jk/jk2 is now so complex that there is only a small number of people who can be involved in. Ok, now that I exposed my general idea, I'd like to have your opinion about what could be a lighter module. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.0.26 release ? - session tracking cookie
Sandy McArthur wrote: On Jul 14, 2004, at 11:17 AM, Henri Gomez wrote: jk 1.2.6 seems to be in a good shape and a release should be welcome for many users. I'd like to release jk 1.2.6 next week. Any objections ? I have one gripe with the way mod_jk chooses the session tracking cookie. I'm not a dev but I just tracked down a bug that has been causing us, University of Florida, some pain for a few weeks. I'm currently verifying that I'm not full of it before I filed a bug report but the short version is: mod_jk seems to pick the first cookie ending in JSESSIONID such as PSJSESSIONID as opposed to what the servlet spec says in section 7.1.1: The name of the session tracking cookie must be JSESSIONID. Take a look at the get_cookie function in jk_lb_worker.c and walk though it with input similar to: Cookie: PSJSESSIONID=FOOBAR; JSESSIONID=BAZZORK.jvm# Bill patched the lb_worker to fix that. Could you take the latest code in CVS and check to see if it solve your problem ? Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas
jean-frederic clere wrote: Henri Gomez wrote: Andy Armstrong wrote: Mladen Turk wrote: In contrary, it makes it simpler, cause you have a common denominator, and that is 'well documented' config file, usable on any container. Well documented is the crux here for me. Or at least readily understandable. I've just had someone nearly abandon Tomcat altogether because they had a problem (with file uploads) that required the latest version of the IIS connector but they couldn't find out how to configure it. I find it frustrating that we're an Apache project but we're currently nowhere near Apache in usability terms. Right now running Tomcat with another webserver is a scary proposition. All the JK code has to do is forward eligible requests from the host web server to Tomcat. I'm afraid that right now it behaves like a self indulgent vanity project with aspirations above its station. With appropriate apologies for the toes that I'm treading on why tge hell is JK so convoluted? There is weeks I'm thinking about another approach for Apache to Tomcats (AJP13) requests relaying. My idea is about a new module, only Apache 2.x for now, which will make use of SetEnv, SetEnvIf, BrowserMath and Location directives to redirect some URLs to tomcats via AJP. Everything in httpd.conf, probably that is a good idea. Reusing existing directives also. Many users complains about problems between Directive, Location, JkMount and of course the configuration complexity of JK and JK2, and yes jk/jk2 are big when you compare them to modules like mod_rewrite or mod_proxy. What I'd like will be a true Apache module where all settings will be in httpd.conf, a module where there will be only one way to configure or define something (which is not the case for JK2 for instance). After all we're ASF commiter and making a specific Apache 2.x connector seems a reasonable goal. The code in jk/jk2 is now so complex that there is only a small number of people who can be involved in. Ok, now that I exposed my general idea, I'd like to have your opinion about what could be a lighter module. Renew mod_webapp! mod_webapp was a good idea but : - It didn't use the de-facto standard AJP13. - It came too soon, before APR was widely available. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.2
Mladen Turk wrote: Hi, All (except Costin) developers has to say something, so my conclusion is that we are not dead after all ;) Seems that the major obstacle is the configuration, so I propose that we forget that for a while, and make a 'generalized' environment that will sattisfy all the 'needs'. That environment could be called APR_JAVA and it will be resposible for os-java communication, having AJPXX, and 'JNI' as one of the possible protocol stacks. It will have a generic mapping mechanism (pcre enabled) for registering URI mapings, setting communication properties, so that one could make a suport from any container (webserver). It will abstract the container-java communication to the level of 'directory and file' so that one can open a connection to TC like opening a file, or simply speaking a 'Virtual File System', so that one can either 'mount' a volume like '/servlets' or a file filter like '*.jsp' Of course all that sounds like JK3, but ... Did you see my post about a simpler module specific for now to Apache 2.x (2.0/2.1), may be something which could be included in standard Apache 2.x distribution which will save us hours on explaining how to build mod_jk/mod_jk2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.2
Tim Funk wrote:
If this is all wishlists .. it'd be nice if we could set the worker and
handler via mod_rewrite.
Intead of
JkMount /*.jsp loadbalancer
Say:
RewriteCond %{REQUEST_URI} *\.jsp
RewriteRule ^(.+)$$1 [T=jk,E=worker:loaderbalance]
[If my syntax above is correct]
I was thinking something similar
SetEnvIf Request_URI /*.jsp worker:loaderbalance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.0.26 release ?
nyhgan wrote: - What's the exact problem ? I'm using jk 1.2.5 with Apache 2.0 and Tomcat 3.3.2 and handle about 300 000 req/days and never got this problem. Explain and detail please. - Hi, Henri Gomez Tomcat 3.3.2 and jk1.2.5 is what I am using now and it runs fine. The problem described emails below only occurs if you use jk1.2.x with Tomcat 5.x (or 4.x). And because of this reasonI can't upgrade my Tomcat to Tomcat5.x. Was jk1.2.x designed to work with Tomcat 5.x? Do I need to use jk2? I am using Apache 1.3.27 and I don't think it will work with jk2. You could use jk 1.2.x with Tomcat 5.x without problem - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.2
Mladen Turk wrote: -Original Message- From: Henri Gomez Of course all that sounds like JK3, but ... Did you see my post about a simpler module specific for now to Apache 2.x (2.0/2.1), may be something which could be included in standard Apache 2.x distribution which will save us hours on explaining how to build mod_jk/mod_jk2 Yes, I did. I read all the replys wery carefully. Did you understand mine? What I propose is: 'imagine a TC as a virtual file system' So, you can 'apr_vfopen(TC/sever, )' like opening a file. You could for examle: Jk3Mount /*.jsp and have smewhere something like: mapping *.jsp server name=1.2.3.1 factor=10% / /mapping or: Well I'd like to see the JK3 or whatever will name the new module to be much more simpler and with less code. For instance even jk2 inherited many code from jk and since jk was designed to be WebServer independant we couldn't use the full APIs of APR and Apache. That's why I think we should rewrite the jk/jk2 successor with Apache 2.x (2.0/2.1) in mind, using all the power of Apache HTTPD directive, including mapping discovery and so on. Ultimatly if we could produce a smaller module, we could then try to convince Apache 2 team to include it in Apache 2 distribution. mapping *.jsp balance server name=1.2.3.1 factor=10% / server name=1.2.3.2 factor=20% / server name=1.2.3.3 factor=auto / server name=1.2.3.4 factor=failover / /balance /mapping I like the balanced worker definition but for an httpd.conf which more easy for Apache Admins, shouldn't it be : WorkerDef WorkerType ajp13 WorkerName myworker1 WorkerHost 1.2.3.1 WorketPort 8009 /WorkerDef WorkerDef WorkerType ajp13 WorkerName myworker2 WorkerHost 1.2.3.2 WorketPort 8009 /WorkerDef WorkerDef WorkerType ajp13 WorkerName myworker3 WorkerHost 1.2.3.3 WorketPort 8009 /WorkerDef WorkerDef WorkerType ajp13 WorkerName myworker4 WorkerHost 1.2.3.4 WorketPort 8009 /WorkerDef WorkerDef WorkerType lb WorkerName balanced WorkerEntry myworker1 10% WorkerEntry myworker2 20% WorkerEntry myworker3 auto WorkerEntry myworker4 failover /WorkerDef - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time for JkMountExclude in jk 1.2.x ?
David Rees wrote: Henri Gomez wrote, On 7/13/2004 3:27 AM: What about adding support for JkMountExclude : I would suggest leaving it for the next release of mod_jk, unless it is simple and there is little chance of it adding any regressions. -Dave I'm puzzled with JkMount when I have to exclude some URL. I won't do anything before release, if everybody agreed on a quick 1.2.6 release. But works should be conducted to add exclusions, may be also via Notes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time for JkMountExclude in jk 1.2.x ?
Rainer Jung wrote: As I started the discussion thread on releasing mod_jk 1.2.6 a few days ago, I would also prefer to have the stable code released and not adding new features. Releasing 1.2.6 as-is would already be benefitial to many people. Henri: thank you very much for preparing the release. For post-1.2.6 releases: JkMount only gives the ability to seperate between Apache and Tomcat on the basis of: default handled by Apache and special things handled by Tomcat. Now often the situation is reversed: complete contexts (detected by URL-prefixes) should be handled by default by the web container, and only special static objects (subdirectorie or, file name suffixes) by apache. So JkMountExclude would make a lot of sense. Ok just commited something for Apache 2.0 and which should be safe. Using the env var no-jk (à la mode_deflate mod_gzip), for instance in a SetEnvIf directive, you could exclude some URL from being served by JK... Tested on my developpment system and everything seems to works correctly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New feature in mod_jk 1.2.6-dev
Hi to all, I added support for a no-jk env var for mod_jk 1.2.6-dev, under Apache 2.0. This environment variable works like the no-gzip for mod_deflate. If jk find the env var no-jk, it will decline the request process and sus let others modules to handle the Apache request. It will help many of us who have problem in excluding part of URL or can't make mod_alias directory directive works with jk. Example of use : VirtualHost *:80 ServerName testxxx.mysys DocumentRoot /www/testxxx/htdocs SetEnvIf Request_URI /home/* no-jk Alias /home /home/dataxxx/ Directory /home/dataxxx Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all /Directory JkMount /* myssys-xxx /VirtualHost With this setting all requests will be relayed to tomcat worker myssys-xxx except the one containing /home. You could use all the power of SetEnvIf directive : http://httpd.apache.org/docs-2.0/mod/mod_setenvif.html Since many users reported problem with location, rewrite, or mod_alias, I strongly suggest them to take a look at the current code in CVS and see if the SetEnvIf fix there problems. This feature will be available in upcoming jk 1.2.6 :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk 1.0.26 release ?
jk 1.2.6 seems to be in a good shape and a release should be welcome for many users. I'd like to release jk 1.2.6 next week. Any objections ? Vote please ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.0.26 release ?
Shapira, Yoav wrote: Hi, No objections: on the contrary, +1 ;) (And a general +1 to mod_* work and releases) Yes, we have a slower release rate :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk_connect and multi-threading
Bill Barker wrote:
- Original Message -
From: Henri Gomez [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, July 12, 2004 3:07 AM
Subject: jk_connect and multi-threading
Hi to all,
I'm looking for a strange problem under iSeries (AS/400) and wonder
about this look in jk_open_socket() (jk_connect.c) :
do {
jk_log(l, JK_LOG_DEBUG, jk_open_socket, try to connect
socket = %d to %s\n,
sock, jk_dump_hinfo(addr, buf));
ret = connect(sock,
(struct sockaddr *)addr,
sizeof(struct sockaddr_in));
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
if(SOCKET_ERROR == ret) {
errno = WSAGetLastError() - WSABASEERR;
}
#endif /* WIN32 */
jk_log(l, JK_LOG_DEBUG, jk_open_socket, after connect ret
= %d\n, ret);
} while (-1 == ret EINTR == errno);
What's the status on errno in multi-threaded environnement ?
On older *nix boxes it wasn't safe to use it with threads. Don't know about
iSeries. On Solaris it's per-thread (assuming that you've compiled
with -D_REENTRANT).
Shouldn't we clear errno before the connect() call ?
It's not supposed to matter.
BTW, I wonder why we check the errno in such case...
Ok, I take a look at IBM errno list and error 3021 is for EINVAL
(invalid argument).
I'll investigate this error farther...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk_connect and multi-threading
Henri Gomez wrote:
Bill Barker wrote:
- Original Message -
From: Henri Gomez [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, July 12, 2004 3:07 AM
Subject: jk_connect and multi-threading
Hi to all,
I'm looking for a strange problem under iSeries (AS/400) and wonder
about this look in jk_open_socket() (jk_connect.c) :
do {
jk_log(l, JK_LOG_DEBUG, jk_open_socket, try to connect
socket = %d to %s\n,
sock, jk_dump_hinfo(addr, buf));
ret = connect(sock,
(struct sockaddr *)addr,
sizeof(struct sockaddr_in));
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
if(SOCKET_ERROR == ret) {
errno = WSAGetLastError() - WSABASEERR;
}
#endif /* WIN32 */
jk_log(l, JK_LOG_DEBUG, jk_open_socket, after connect ret
= %d\n, ret);
} while (-1 == ret EINTR == errno);
What's the status on errno in multi-threaded environnement ?
On older *nix boxes it wasn't safe to use it with threads. Don't know
about
iSeries. On Solaris it's per-thread (assuming that you've compiled
with -D_REENTRANT).
Shouldn't we clear errno before the connect() call ?
It's not supposed to matter.
BTW, I wonder why we check the errno in such case...
Ok, I take a look at IBM errno list and error 3021 is for EINVAL
(invalid argument).
I'll investigate this error farther...
The problem could be related to BSD 4.4/Unix 98 where the sa_len should
be defined before connect call. May be one of the various reason where
jk_connect failed strangely on many boxes.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk_connect and multi-threading
jean-frederic clere wrote:
Henri Gomez wrote:
Henri Gomez wrote:
Bill Barker wrote:
- Original Message -
From: Henri Gomez [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, July 12, 2004 3:07 AM
Subject: jk_connect and multi-threading
Hi to all,
I'm looking for a strange problem under iSeries (AS/400) and wonder
about this look in jk_open_socket() (jk_connect.c) :
do {
jk_log(l, JK_LOG_DEBUG, jk_open_socket, try to connect
socket = %d to %s\n,
sock, jk_dump_hinfo(addr, buf));
ret = connect(sock,
(struct sockaddr *)addr,
sizeof(struct sockaddr_in));
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
if(SOCKET_ERROR == ret) {
errno = WSAGetLastError() - WSABASEERR;
}
#endif /* WIN32 */
jk_log(l, JK_LOG_DEBUG, jk_open_socket, after connect ret
= %d\n, ret);
} while (-1 == ret EINTR == errno);
What's the status on errno in multi-threaded environnement ?
On older *nix boxes it wasn't safe to use it with threads. Don't
know about
iSeries. On Solaris it's per-thread (assuming that you've compiled
with -D_REENTRANT).
Shouldn't we clear errno before the connect() call ?
It's not supposed to matter.
BTW, I wonder why we check the errno in such case...
Ok, I take a look at IBM errno list and error 3021 is for EINVAL
(invalid argument).
I'll investigate this error farther...
The problem could be related to BSD 4.4/Unix 98 where the sa_len
should be defined before connect call. May be one of the various
reason where
jk_connect failed strangely on many boxes.
Yes, APR uses:
+++
apr_status_t apr_socket_connect(apr_socket_t *sock, apr_sockaddr_t *sa)
{
int rc;
do {
rc = connect(sock-socketdes,
(const struct sockaddr *)sa-sa.sin,
sa-salen);
} while (rc == -1 errno == EINTR);
+++
So setting sa_len and USING sa_len instead sizeof(sockaddr_in) in the
socket() should fix most of the problems.
Ok, but how could we get the correct sa_len ?
Patch welcome
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Time for JkMountExclude in jk 1.2.x ?
Hi to all, As many I'm puzzled in jk 1.2.x in some case : VirtualHost *:80 ServerName test101.mysys DocumentRoot /www/sys101/htdocs JkMount /* test-101 /VirtualHost VirtualHost *:80 ServerName test102.mysys DocumentRoot /www/sys102/htdocs JkMount /* test-102 /VirtualHost No imagine I want to have /home in test102.mysys mapped no more to tomcat but to local directory. VirtualHost *:80 ServerName test102.mysys DocumentRoot /www/sys102/htdocs JkMount /* test-102 Alias /home/ /www/sys102/home/ Directory /www/sys102/home Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all /Directory /VirtualHost There is no way to get http://test102.mysys/home goes to /www/sys102/home local directory. What about adding support for JkMountExclude : VirtualHost *:80 ServerName test102.mysys DocumentRoot /www/sys102/htdocs JkMount /* test-102 JkMountExclude /home/* Alias /home/ /www/sys102/home/ Directory /www/sys102/home Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all /Directory /VirtualHost These will prevent JkMount to forward /home/* to tomcat worker test-102. Thanks to comments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk_connect and multi-threading
jean-frederic clere wrote:
Henri Gomez wrote:
Henri Gomez wrote:
Bill Barker wrote:
- Original Message -
From: Henri Gomez [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, July 12, 2004 3:07 AM
Subject: jk_connect and multi-threading
Hi to all,
I'm looking for a strange problem under iSeries (AS/400) and wonder
about this look in jk_open_socket() (jk_connect.c) :
do {
jk_log(l, JK_LOG_DEBUG, jk_open_socket, try to connect
socket = %d to %s\n,
sock, jk_dump_hinfo(addr, buf));
ret = connect(sock,
(struct sockaddr *)addr,
sizeof(struct sockaddr_in));
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
if(SOCKET_ERROR == ret) {
errno = WSAGetLastError() - WSABASEERR;
}
#endif /* WIN32 */
jk_log(l, JK_LOG_DEBUG, jk_open_socket, after connect ret
= %d\n, ret);
} while (-1 == ret EINTR == errno);
What's the status on errno in multi-threaded environnement ?
On older *nix boxes it wasn't safe to use it with threads. Don't
know about
iSeries. On Solaris it's per-thread (assuming that you've compiled
with -D_REENTRANT).
Shouldn't we clear errno before the connect() call ?
It's not supposed to matter.
BTW, I wonder why we check the errno in such case...
Ok, I take a look at IBM errno list and error 3021 is for EINVAL
(invalid argument).
I'll investigate this error farther...
The problem could be related to BSD 4.4/Unix 98 where the sa_len
should be defined before connect call. May be one of the various
reason where
jk_connect failed strangely on many boxes.
Yes, APR uses:
+++
apr_status_t apr_socket_connect(apr_socket_t *sock, apr_sockaddr_t *sa)
{
int rc;
do {
rc = connect(sock-socketdes,
(const struct sockaddr *)sa-sa.sin,
sa-salen);
} while (rc == -1 errno == EINTR);
+++
So setting sa_len and USING sa_len instead sizeof(sockaddr_in) in the
socket() should fix most of the problems.
From the Rochester Labs documentation, I could read :
http://as400bks.rochester.ibm.com/iseries/v5r2/ic2924/index.htm?info/apis/_xopen_source.htm
BSD 4.3 :
typedef int socklen_t;
typedef unsigned short sa_family_t;
struct sockaddr {
u_short sa_family;
charsa_data[14];
};
BSD 4.4 :
typedef int socklen_t;
typedef uchar sa_family_t;
struct sockaddr {
uint8_t sa_len;
sa_family_t sa_family;
charsa_data[14];
};
So we should set the sa_len in jk_connect.c when BSD 4.4 / Unix 98 or
iSeries using Unix 98. Need info about BSD 4.4 / Unix 98
int jk_open_socket(struct sockaddr_in *addr,
int ndelay,
int keepalive,
jk_logger_t *l)
{
char buf[32];
int sock;
jk_log(l, JK_LOG_DEBUG, Into jk_open_socket\n);
sock = socket(AF_INET, SOCK_STREAM, 0);
if(sock -1) {
int ret;
/* Tries to connect to Tomcat (continues trying while error is
EINTR) */
do {
jk_log(l, JK_LOG_DEBUG, jk_open_socket, try to connect
socket = %d to %s\n,
sock, jk_dump_hinfo(addr, buf));
/* Need more infos for BSD 4.4 and Unix 98 defines, for now only
iSeries when Unix98 is required at compil time */
#if (_XOPEN_SOURCE = 520)
((struct sockaddr *)addr)-sa_len = sizeof(struct sockaddr_in));
#endif
ret = connect(sock,
(struct sockaddr *)addr,
sizeof(struct sockaddr_in));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk_connect and multi-threading
jean-frederic clere wrote:
Henri Gomez wrote:
jean-frederic clere wrote:
Henri Gomez wrote:
Henri Gomez wrote:
Bill Barker wrote:
- Original Message -
From: Henri Gomez [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, July 12, 2004 3:07 AM
Subject: jk_connect and multi-threading
Hi to all,
I'm looking for a strange problem under iSeries (AS/400) and wonder
about this look in jk_open_socket() (jk_connect.c) :
do {
jk_log(l, JK_LOG_DEBUG, jk_open_socket, try to connect
socket = %d to %s\n,
sock, jk_dump_hinfo(addr, buf));
ret = connect(sock,
(struct sockaddr *)addr,
sizeof(struct sockaddr_in));
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
if(SOCKET_ERROR == ret) {
errno = WSAGetLastError() - WSABASEERR;
}
#endif /* WIN32 */
jk_log(l, JK_LOG_DEBUG, jk_open_socket, after
connect ret
= %d\n, ret);
} while (-1 == ret EINTR == errno);
What's the status on errno in multi-threaded environnement ?
On older *nix boxes it wasn't safe to use it with threads. Don't
know about
iSeries. On Solaris it's per-thread (assuming that you've compiled
with -D_REENTRANT).
Shouldn't we clear errno before the connect() call ?
It's not supposed to matter.
BTW, I wonder why we check the errno in such case...
Ok, I take a look at IBM errno list and error 3021 is for EINVAL
(invalid argument).
I'll investigate this error farther...
The problem could be related to BSD 4.4/Unix 98 where the sa_len
should be defined before connect call. May be one of the various
reason where
jk_connect failed strangely on many boxes.
Yes, APR uses:
+++
apr_status_t apr_socket_connect(apr_socket_t *sock, apr_sockaddr_t *sa)
{
int rc;
do {
rc = connect(sock-socketdes,
(const struct sockaddr *)sa-sa.sin,
sa-salen);
} while (rc == -1 errno == EINTR);
+++
So setting sa_len and USING sa_len instead sizeof(sockaddr_in) in
the socket() should fix most of the problems.
Ok, but how could we get the correct sa_len ?
That should be done in jk_resolve().
I do it in jk_connect, just to show that's something needed by connect()
call for iSeries using Unix98. Don't know for BSD 4.4
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
jk_connect and multi-threading
Hi to all,
I'm looking for a strange problem under iSeries (AS/400) and wonder
about this look in jk_open_socket() (jk_connect.c) :
do {
jk_log(l, JK_LOG_DEBUG, jk_open_socket, try to connect
socket = %d to %s\n,
sock, jk_dump_hinfo(addr, buf));
ret = connect(sock,
(struct sockaddr *)addr,
sizeof(struct sockaddr_in));
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
if(SOCKET_ERROR == ret) {
errno = WSAGetLastError() - WSABASEERR;
}
#endif /* WIN32 */
jk_log(l, JK_LOG_DEBUG, jk_open_socket, after connect ret
= %d\n, ret);
} while (-1 == ret EINTR == errno);
What's the status on errno in multi-threaded environnement ?
Shouldn't we clear errno before the connect() call ?
BTW, I wonder why we check the errno in such case...
I see many errors in Apache 2.0.48 on my iSeries when I try to connect
to some workers (more than 40 defined) and it seems that some of them
couldn't be reached :
[Thu Jul 08 17:13:22 2004] [jk_ajp_common.c (720)]: Error connecting to
tomcat. Tomcat is probably not started or is listening o
n the wrong host/port (127.0.0.1:11013). Failed errno = 3021
[Thu Jul 08 17:13:22 2004] [jk_ajp_common.c (1024)]: Error connecting
to the Tomcat process.
[Thu Jul 08 17:13:22 2004] [jk_ajp_common.c (1468)]: sending request to
tomcat failed in send loop. err=0
[Thu Jul 08 17:13:22 2004] [jk_connect.c (181)]: jk_open_socket,
connect() failed errno = 3021
[Thu Jul 08 17:13:22 2004] [jk_ajp_common.c (720)]: Error connecting to
tomcat. Tomcat is probably not started or is listening o
n the wrong host/port (127.0.0.1:11013). Failed errno = 3021
[Thu Jul 08 17:13:22 2004] [jk_ajp_common.c (1024)]: Error connecting
to the Tomcat process.
[Thu Jul 08 17:13:22 2004] [jk_ajp_common.c (1468)]: sending request to
tomcat failed in send loop. err=1
[Thu Jul 08 17:13:22 2004] [jk_connect.c (181)]: jk_open_socket,
connect() failed errno = 3021
[Thu Jul 08 17:13:22 2004] [jk_ajp_common.c (720)]: Error connecting to
tomcat. Tomcat is probably not started or is listening o
n the wrong host/port (127.0.0.1:11013). Failed errno = 3021
[Thu Jul 08 17:13:22 2004] [jk_ajp_common.c (1024)]: Error connecting
to the Tomcat process.
[Thu Jul 08 17:13:22 2004] [jk_ajp_common.c (1468)]: sending request to
tomcat failed in send loop. err=2
[Thu Jul 08 17:13:22 2004] [jk_ajp_common.c (1477)]: Error connecting
to tomcat. Tomcat is probably not started or is listening
on the wrong port. worker=mysys-xxx-101 failed errno = 3021
What is strange is that there is a tomcat running at port 11013 and
I could reach it from another Apache 2 box.
The 3021 errcode is an iSeries error code which seems indicate something
not related with IP problems.
Advices, intutions, magic more than welcome.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ready for mod_jk 1.2.6 release?
Rainer Jung wrote: Hi, the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. Since then there have been important improvements (CPing/CPong and recovery_options). Especially recovery_options is very useful in transparent administration (start/stop) of cluster nodes. The 1.2 branch is still the preferred branch for combination with apache 1.3. Is there any volunteer to make an official 1.2.6 release? I do hope so ;-) I could works on it if nobody else has time to act as release manager. Feedback welcome of course, especially on possible blocking bugs... Another good argument: The documentation of the new features is already there (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/workershowto.html), so no additional work and furthermore, the documentation up to now does not mention, that all these features are still not available, because 1.2.6 has never been released. Many thanks to whoever wrote that document. I worked with a cvs build under solaris for some weeks without problems, but for production purposes people need an official release. The last changes in the native jk code is more then 6 weeks old and there is no code change activity at the moment. So this might be a good point in time to release mod_jk 1.2.6. Looking forward for positive feedback Rainer Jung - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ready for mod_jk 1.2.6 release?
Service Client Fnac.com wrote: Chère Cliente, Cher Client, Merci de nous avoir contactés. Vous venez d'envoyer un message à une adresse ne permettant pas de recevoir d'e-mail. Pour trouver les réponses à vos questions sur vos commandes, sur les produits, sur le site, consultez nos pages d'aide en ligne en cliquant sur : http://www.fnac.com/Help/A01.asp Vous pouvez également suivre en direct l'évolution de vos commandes en cours, en consultant la rubrique Vos Commandes en un clin d'oeil en cliquant sur : https://www.fnac.com/Account/Profil/default.asp Nous espérons que ces pages vous apporteront toutes les informations nécessaires. Dans le cas contraire, vous pouvez nous contacter par e-mail en cliquant sur le lien : http://www.fnac.com/Service_Client/FnacSUGG.asp Merci de votre fidélité a www.fnac.com Très cordialement, Well I don't see why the Client Support of Fnac is subscribed here, so I strongly suggest mailing list manager to remove it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ready for mod_jk 1.2.6 release?
Henri Gomez wrote: Rainer Jung wrote: Hi, the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. Since then there have been important improvements (CPing/CPong and recovery_options). Especially recovery_options is very useful in transparent administration (start/stop) of cluster nodes. The 1.2 branch is still the preferred branch for combination with apache 1.3. Is there any volunteer to make an official 1.2.6 release? I do hope so ;-) I could works on it if nobody else has time to act as release manager. Feedback welcome of course, especially on possible blocking bugs... Make a build on latest from CVS, and it works on both Linux Fedora Core 2 and iSeries (AS/400) V5R2. Could someone works on an Windows version for Apache 2 ? Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: What about gzip compression ?]
Remy ? ---BeginMessage--- Henri Gomez wrote: Take a look in jakarta-tomcat-connectors (ie: http://apache.fastorama.com/dist/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz) jakarta-tomcat-connectors\http11\src\java\org\apache\coyote\http11 Thanks, found it in the Http11Processor. However, it seems that the Coyote connector doesn't handle the TE header. In other words, it doesn't seem to support negotiation? Regards, Jochen ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp ReplicationValve.java
This commit was sponsored by Eclipse 3 RC 1 and its refatoring features :) Somehow, they spell that refactoring in the menus, but it's evidently a mistake, as the features are powerful enough to warrant the Genuine Refatoring (R) label. Great use of Eclipse. Eclipse 3 RC3 is available and the final 3.0 release is scheduled in 2 weeks :) I think it should still build, but I didn't do a fresh checkout to verify. Let me know. It seems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 changes
jean-frederic clere wrote: Andy Armstrong wrote: (posted to the right list now - oops) I'm just making sure the Lotus Domino connector works with the latest jk2 version. As a preamble to that I usually make sure I can get mod_jk2 working with Apache 2 as a kind of baseline. This time I'm getting stuck. Is there an incompatibility between a mod_jk2 built from the current CVS and the 5.0.27 binary build at jakarta.apache.org? Well I couldn't help much these time, but I strongly recommand to make a jk 1.2.6 and jK2 2.0.5 release as soon as possible since fixes and features has been added and users could be stuck since TC 5.0.x and jk/jk2 release cycle are very differents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-5/resources tomcat.spec
[EMAIL PROTECTED] a écrit : costin 2004/05/21 07:52:00 Added: resources tomcat.spec Log: Initial version of a spec file creating a RPM identical with the official binary distribution. Well that's not a clean way to package RPM since in packaging policies, a binary should allways been rebuild from source :-) Also this RPM didn't follow FHS. Why not make a notice to use the rpms provided by www.jpackage.org since users will also get apt-get and yum support, which is the regular way to keep Linux box up to date. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with Coyote Connectors
Hans Schmid wrote: Sorry, I forgot to mention, that we are using mod_jk 1.2.5 on the Apache side I'm using the same config at works, jk 1.2.5 and TC 3.3.2 and didn't see such problem. Are you sure the number of ajp13 threads are correctly set, regarding the number of connections allowed on web server ? We have heavily loaded Tomcat/Apache couple (more than 30 req/day) and the only problem I could see is from time to time the : INFO: Unknown message 0 This one is fixed in CVS (post 3.3.2 release). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with Coyote Connectors
Hans Schmid wrote: Hi Henri, thanks for the quick reply. This is what is used (same config as the former AJP13Connector) CoyoteConnector processorClassName=org.apache.jk.server.JkCoyoteHandler port=11019 maxThreads=2048 maxSpareThreads=80 minSpareThreads=40 / old was: Ajp13Connector port=11019 shutdownEnable=true maxThreads=2048 maxSpareThreads=80 minSpareThreads=40 / served from 2 Apache Servers each with 1024 maxthreads. Threads should be enough. I saw 8 occurrences of the stacktrace within 2 Days, so it does not occur often. I can go back to my old server.xml with the AJP13Connectors as well, but I would love to run Coyote for a while in order to prepare a Tomcat 5 upgrade. We have up to 50 concurrent users and up to 80 req/day :) But not now. this is in November :) BTW. I am missing the shutdownEnabled feature :( (One addional AJP12Connector and port per Tomcat Instance required) 2048 threads on both Tomcat and Apache2 ? I'm using only 150 threads on both end - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.22] Release vote
Remy Maucherat wrote: ballot Release 5.0.22 as Stable: [ ] Yes [ ] No /ballot I've tested the new Windows wrapper, and it did work for me (and it looks as if we did hire some M$ guy to do its UI). However, some more testing is needed (note: it's not suppoed to work on Win9x for now). Another risky change is the upgrade to Xerces 1.6.2. I didn't put the latest docs bundle on the website (AFAIK, the changelog will be the only update, so I think I'll only upload this file). I didn't run the CTS yet with that build. Did the 5.0.22 will include my patch in jk/java/org/apache/jk/common JkMX.java to set correctly the RMI port ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I think lb_factor in JK2 is broken (or just backwards from JK)
Angus Mezick wrote:
I forgot to mention that I am using the following software:
Apache: apache_2.0.47-win32-x86-no_ssl.msi
JK2: mod_jk2-2.0.43.dll AND the 2.0.4 mod_jk.so from the jakarta site.
Tomcat: 4.1.27
-Original Message-
From: Angus Mezick
Sent: Thursday, April 08, 2004 9:44 AM
To: [EMAIL PROTECTED]
Subject: I think lb_factor in JK2 is broken (or just
backwards from JK)
Web01 is running apache
Web01 and web02 are running tomcat
I set web01 to lb_factor=1
I set web02 to lb_factor=15
From what I see in code, lb_factor is used as increment and not as
load factor...
if (rc != NULL) {
/* It it's the default, it'll remain the default - we don't
increase the factor
*/
rc-in_error_state = JK_FALSE;
if (rc-lb_value != 0) {
int newValue = rc-lb_value + rc-lb_factor;
if (newValue 255) {
rc-lb_value = rc-lb_factor;
/* Roll over. This has 2 goals:
- avoid the lb factor becoming too big, and give a
chance to run to
workers that were in error state ( I think it's
cleaner than looking for max )
- the actual lb_value will be 1 byte. Even on the
craziest platform, that
will be an atomic write. We do a lot of operations
on lb_value in a MT environment,
and the chance of reading something inconsistent is
considerable. Since APR
will not support atomic - and adding a CS would cost
too much, this is actually
a good solution.
Note that lb_value is not used for anything critical
- just to balance the load,
the worst that may happen is having a worker stay
idle for 255 requests.
*/
for (i = 0; i lb-workerCnt[currentLevel]; i++) {
jk_worker_t *w = lb-workerTables[currentLevel][i];
w-lb_value = w-lb_factor;
}
}
else {
rc-lb_value = newValue;
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with stress tested apps
Bill Barker wrote: - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, April 06, 2004 5:08 AM Subject: Re: Problems with stress tested apps Henri Gomez wrote: Henri Gomez wrote: Hi to all, I've got problems with some highly stressed applications using jk or jk2 and tomcat 3.3.2 (same thing with TC 5.0.x). I see many errors like these in log : in TC 3.3.2 and 5.0.19 : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 in 5.0.19 I've got also : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest decodeRequest WARNING: Error registering request There is something weird in jtc, since the INFO: Unknown message 0 indicate that there is an invalid command on the AJP13 link. The problem appears with both jk and jk2, so I suspect the problem to be on the java side. I'm investigating the problem. While playing with TC 3.3.3-dev and JTC-dev, I didn't see (yet), the INFO: Unknown message 0 but got some : 6 avr. 2004 08:46:37 org.apache.jk.common.ChannelSocket processConnection GRAVE: Error, releasing connection java.lang.NullPointerException at org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:427) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:659) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:644) at java.lang.Thread.run(Thread.java:534) With the latest TC 3.3.3-dev, I didn't get the : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 This is BZ #27881. With 3.3.2 (unless you JMX-register the CoyoteConnector yourself :) it doesn't do anything except fill up your log file when threads die. Of course, you can always swap in the JK jar from 5.0.21 if you don't want to see the message. Thanks Bill. I made a TC 3.3.3-dev from the CVS and it seems to works great (add since it has been build with common-modeler, more JMX support is included). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.0.22 tag ?
Filip Hanik (lists) wrote: sounds good! Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 06, 2004 5:48 PM To: Tomcat Developers List Subject: 5.0.22 tag ? I plan to tag 5.0.22 tomorrow. Any objections ? +0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PHP from Tomcat , some news from JFC :)
Hi to all, Mladen discussed about using PHP from Tomcat. Jean-Frederic Clere make some tests during his vacation and send me the following mail to be forwarded to the list : Good news, tomcat+php it's easy, php allready have support for. I make a simple try and here's the resulting 'readme' : Using php in Tomcat5: Easy a servlet is available in php (I have tried with php-4.3.5) configure the php with: ./configure --with-servlet=$TOMCAT_HOME --with-java=$JAVA_HOME a jarfile and dynamic library are produced: - sapi/servlet/phpsrvlt.jar - libs/libphp4.so Copy jarfile and arrange web.xml: cp $PHP_HOME/sapi/servlet/phpsrvlt.jar $TOMCAT_HOME/common/lib copy the $PHP_HOME/sapi/servlet/web.xml servlet and servlet-mapping in the $TOMCAT_HOME/conf/web.xml Start the Tomcat: LD_LIBRARY_PATH=$PHP_HOME/libs export LD_LIBRARY_PATH $TOMCAT_HOME/bin/catalina.sh start Try it: Create a file named ./webapps/ROOT/test.php containing: +++ ?php phpinfo(); ? +++ Call it: http://localhost:8080/test.php Patch for the configure of php: --- configure.org 2004-04-07 11:20:24.0 +0200 +++ configure 2004-04-07 11:22:50.0 +0200 if test $withval = yes; then SERVLET_CLASSPATH=. else + if test -f $withval/common/lib/servlet-api.jar; then +SERVLET_CLASSPATH=$withval/common/lib/servlet-api.jar + fi + if test -f $withval/lib/servlet.jar; then SERVLET_CLASSPATH=$withval/lib/servlet.jar fi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PHP from Tomcat , some news from JFC :)
Costin Manolache wrote: Nice :-) Did you try it ? I'm curious, could you run a quick helo world benchmark ( helo.jsp / help.php ) ? The big question is the level of integration - i.e. if you can call java objects from php or use some of the nice PHP features from java. I just forwarded the Jean-Frederic mail to the list, but I'm sure he'll be happy to reply to these questions :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems with stress tested apps
Hi to all, I've got problems with some highly stressed applications using jk or jk2 and tomcat 3.3.2 (same thing with TC 5.0.x). I see many errors like these in log : in TC 3.3.2 and 5.0.19 : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 in 5.0.19 I've got also : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest decodeRequest WARNING: Error registering request There is something weird in jtc, since the INFO: Unknown message 0 indicate that there is an invalid command on the AJP13 link. The problem appears with both jk and jk2, so I suspect the problem to be on the java side. I'm investigating the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with stress tested apps
Henri Gomez wrote: Hi to all, I've got problems with some highly stressed applications using jk or jk2 and tomcat 3.3.2 (same thing with TC 5.0.x). I see many errors like these in log : in TC 3.3.2 and 5.0.19 : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 in 5.0.19 I've got also : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest decodeRequest WARNING: Error registering request There is something weird in jtc, since the INFO: Unknown message 0 indicate that there is an invalid command on the AJP13 link. The problem appears with both jk and jk2, so I suspect the problem to be on the java side. I'm investigating the problem. While playing with TC 3.3.3-dev and JTC-dev, I didn't see (yet), the INFO: Unknown message 0 but got some : 6 avr. 2004 08:46:37 org.apache.jk.common.ChannelSocket processConnection GRAVE: Error, releasing connection java.lang.NullPointerException at org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:427) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:659) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:644) at java.lang.Thread.run(Thread.java:534) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with stress tested apps
Henri Gomez wrote: Henri Gomez wrote: Hi to all, I've got problems with some highly stressed applications using jk or jk2 and tomcat 3.3.2 (same thing with TC 5.0.x). I see many errors like these in log : in TC 3.3.2 and 5.0.19 : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 in 5.0.19 I've got also : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest decodeRequest WARNING: Error registering request There is something weird in jtc, since the INFO: Unknown message 0 indicate that there is an invalid command on the AJP13 link. The problem appears with both jk and jk2, so I suspect the problem to be on the java side. I'm investigating the problem. While playing with TC 3.3.3-dev and JTC-dev, I didn't see (yet), the INFO: Unknown message 0 but got some : 6 avr. 2004 08:46:37 org.apache.jk.common.ChannelSocket processConnection GRAVE: Error, releasing connection java.lang.NullPointerException at org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:427) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:659) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:644) at java.lang.Thread.run(Thread.java:534) With the latest TC 3.3.3-dev, I didn't get the : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 And didn't see either the java.lang.NullPointerException in org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52) Good for TC 5.0.22 ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Remy Maucherat wrote: Costin Manolache wrote: If you're worried about risk, then probably glueing PHP with tomcat will be a bad choice. Tomcat is limited by Java's bad support for integration with native code. Apache will have no problem running Php, perl, python, .net or integrating with any native library that exists today. For tomcat running openSSL seems to be a big thing, and we know too well how difficult it is to get it working with JNI. For tomcat - you can attempt to rewrite/replace every feature in Java ( we are doing this for LDAP auth for example - not sure if JNDI is better or faster than the native ldap auth in apache ). Or you can try to use JNI or connectors - like mod_jk. Or you can just use what already works and is stable, and do something better with your time :-) We'll see the result when it's done :) If Mladen wants to try it because he feels like he has a need for it, it's fine by me. And there is the maintainability, scalability, etc. which I think Java is better at. Well I made some benchmarks on TC 3.3.2, TC 4.1.30, TC 5.0.19, Apache 2, mod_php 4.3.5 and mod_php 5.0RC1 this week-end and you could see that to serve the good old HelloWorld (or its html/php counter part), Java is allways faster. This 'bench' has been conducted on a Pentium 4 with 512Mo RAM , Windows XP and Sun SDK 1.4.2-04. I used each time the default server configurations. Regards Tomcat 3.3.2 / Coyote HTTP 1.1 Server Software:Apache-Coyote/1.1 Server Hostname:127.0.0.1 Server Port:8080 Document Path: /examples/servlet/HelloWorldExample Document Length:419 bytes Concurrency Level: 16 Time taken for tests: 1.902736 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 546000 bytes HTML transferred: 419000 bytes Requests per second:525.56 [#/sec] (mean) Time per request: 30.444 [ms] (mean) Time per request: 1.903 [ms] (mean, across all concurrent requests) Transfer rate: 280.12 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 2.8 0 10 Processing: 0 28 5.1 30 50 Waiting:0 14 9.6 10 40 Total: 0 29 4.7 30 50 Percentage of the requests served within a certain time (ms) 50% 30 66% 30 75% 30 80% 30 90% 30 95% 40 98% 40 99% 40 100% 50 (longest request) --- Tomcat 4.1.30 / Coyote HTTP 1.1 Server Software:Apache-Coyote/1.1 Server Hostname:127.0.0.1 Server Port:8080 Document Path: /examples/servlet/HelloWorldExample Document Length:411 bytes Concurrency Level: 16 Time taken for tests: 2.143081 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 559000 bytes HTML transferred: 411000 bytes Requests per second:466.62 [#/sec] (mean) Time per request: 34.289 [ms] (mean) Time per request: 2.143 [ms] (mean, across all concurrent requests) Transfer rate: 254.31 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:01 3.0 0 10 Processing:10 32 5.3 30 50 Waiting:0 16 10.7 20 50 Total: 10 33 5.6 30 50 Percentage of the requests served within a certain time (ms) 50% 30 66% 40 75% 40 80% 40 90% 40 95% 40 98% 40 99% 50 100% 50 (longest request) --- Tomcat 5.0.19 / Coyote HTTP 1.1 Server Software:Apache-Coyote/1.1 Server Hostname:127.0.0.1 Server Port:8080 Document Path: /servlets-examples/servlet/HelloWorldExample Document Length:365 bytes Concurrency Level: 16 Time taken for tests: 2.173125 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 513000 bytes HTML transferred: 365000 bytes Requests per second:460.17 [#/sec] (mean) Time per request: 34.770 [ms] (mean) Time per request: 2.173 [ms] (mean, across all concurrent requests) Transfer rate: 230.08 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 3.1 0 20 Processing: 0 33 6.1 30 60 Waiting:0 16 10.7 20 50 Total: 0 34 6.5 30 60 Percentage of the requests served within a certain time (ms) 50% 30 66% 40 75% 40 80% 40 90% 40 95% 40 98% 50 99% 60 100% 60 (longest request) --- Apache 2.0.49 (Windows) Server Software:Apache/2.0.49 Server Hostname:127.0.0.1 Server Port:80 Document Path: /helloworld.html Document Length:365 bytes
Re: jk2 and debug on specials uri
NormW wrote:
Good afternoon Henri.
In visualising the process of JkUriSet, arrived at the following in
pseudo-code. Shame I can't translate it to C otherwise I would offer a diff.
:-)
Regards,
Norm
JkUriSet property, value
/* Only allow inside a Location block */
if (!location block) {
log error, JkUriSet not allowed here
return CONFIG_ERROR
}
/* 2 Parameters - property and value */
if (!property or !value) {
log error, missing parameter(s) - property and value
return CONFIG_ERROR
}
/* The property must be in the setAttrInfo list */
if(!property in setAttrInfo() ) {
log error, property not settable-, property
return CONFIG_ERROR
}
/* Create uri name using host, port, location */
.. ()
if(!valid name) {
log error, missing or invalid data - , host,port,context
return CONFIG_ERROR
}
/* Check for existing uri object - update it or create a new one */
if(exist uri name) {
point to it;
log warning, using existing uri object - , name
} else {
status = create_uri()
if(status !=OK) {
log emerg, create uri object failed - , status
return CONFIG_ERROR
}
set uri object
(name,host,port,context,match_type,timing,disabled,debug)
if(default_worker != NULL) {
set group = default_worker
}
}
/* Set passed property value but first set if it is set already */
if (getAttr(property) != NULL) {
log warning, updating existing uri object property - ,
property,value
}
if(setAttr(property, value)!=OK) {
log error, setting property failed - , property,value
return CONFIG_ERROR
}
return OK.
Thanks to send a diff to latest code so I could commit it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 and debug on specials uri
Henri Gomez wrote: Thanks to send a diff to latest code so I could commit it. Oh, you allready provided a patch. Thanks, I commit it ASAP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 and debug on specials uri
NormW wrote: Good evening Henri, Thanks for taking the patch. The pseudo-code (now below) is mostly an 'analysis' of what I would expect JkUriSet to do based on understanding of the process. From this it is mostly a check list of what to expect to find when looking at what the code actually does. In looking at the uri records the current process creates, I noticed the 'name' and 'uri' now lacks the added numbers, yet when I tried the get= command I couldn't retrieve the object; a dmp= showed the uri records still get an object name that has a number added on, which is a little confusing. As mentioned previously, it's my understanding the uri records are meant to aim a url at a designated worker, and if the uri record is first created in workers2.properties then the 'comment' in the mod_jk2.c source that all entries passed in [via jkuriset] are unique clearly _may_ not apply. In that sense the uri objects are much like database records with a primary key that includes the host, port and context... [uri:/examples/*] says to use the 'default' host and port, and if the Location block isn't inside a virtual host directive, then Location /examples/* effectively means the same thing, so there really isn't a need to create an extra uri object As I said, it's mostly meant as a checklist, and is only valid if I understand the requirements. While I would like to be able to code a patch for this, my C skills are such that I limited my pseudo-code to use enough to make it easier to understand it doesn't necessarily make it right. Thanks Norm. Any patch welcome. Also what about working on an XML version of jkstatus ? Could you save some hours on it ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 and debug on specials uri
NormW wrote: Good evening Henri, Wouldn't it be Location /examples/* JkUriSet group lb JkUriSet debug 1 Location I tried but it didn't works ;( or JkSet uri:/examples/*.debug 1 or JkSet2 uri:/examples/* debug 1 Well it didn't works neither. I'm using these 2 on a VirtualHost - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling mod_jk 2.0.4 on macos X (10.2)
Kurt Miller wrote: From: Marco Baringer [EMAIL PROTECTED] i'm trying to compile mod_jk (just the apache side, not the tomcat side). I downloaded jakarta-tomcat-connectors-jk2-2.0.4-src. apr-0.9.4 and apr-util-0.9.4 and was able to successfully run configure (i'm building against apache 1.3). however trying to do make results in an error about build/jk2/apache13/mod_jk2.so not existing (it doesn't). i have all the .o files and i have mod_jk2.a and mod_jk2.la, why isn't the .so file being built? Is there a jk/build/jk2/apache13/usr/local/libexec/mod_jk2.dylib? You could try editing jk/native2/server/apache13/Makefile and change all .so to .dylib and see if that helps. Attempts to build against apache2 result in configure errors about libapr not being found. This has been reported and fixed post 2.0.4. A quick workaound would be to edit jk/native2/configure, find all the referances to libapr-1.so, libapr-0.so and libapr.so and change to libapr-1.dylib, libapr-0.dylib and libapr.dylib respectively. There is a fix in jk2 CVS to fix this .dylib - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 and debug on specials uri
Henri Gomez wrote: NormW wrote: Good evening Henri, Wouldn't it be Location /examples/* JkUriSet group lb JkUriSet debug 1 Location I tried but it didn't works ;( or JkSet uri:/examples/*.debug 1 or JkSet2 uri:/examples/* debug 1 Well it didn't works neither. I'm using these 2 on a VirtualHost I'm looking to fix a problem with charset encoding and it seems that in jk2_service_apache2_head(), s-uriEnv-mbean-debug is 0 ;( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: -Original Message- From: Henri Gomez I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. Interesting idea Mladen. Next idea. If we drop Apache 2.0 support we need to have jk/jk2 jobs done somewhere : What about Tomcat 5 Coyote as a ajp13 dispatcher with advances and fine tuning rules, which could be updated in real time in via JMX ? Yes something like that, It will allow mod_jk2 lb features and header preproc, but in pure Java, and it'll need to expose some kind of the API, usable from native code. Having that in Java will allow dynamic config either using JMX or some other technology. Will it use ajp13 as a messaging protocol? I don't know yet. The discussion is open :) In fact we could need only a TC5 subset, mainly only Coyote HTTP 1.1. To forward request to remote Tomcat we could use AJP or may be RMI ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Remy Maucherat wrote: Mladen Turk wrote: mod_php inside TC. How does that work ? I found out that TC is only 8% slower the Apache2.x. 8% for doing what ? (this will heavily depend on the VM you're using, anyway, so try JRockit to get the good results :) ) 8% slower to serve only static pages ? Which JVM and OS ? So if I need PHP and JSP, the Apache2 is total overhead. You mean: JSP through Apache is slower, so you think a little more overhead on PHP would make for a better average ? I'm not quite convinced yet ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion - /jkstatus and stylesheets
Craig McClanahan wrote: jean-frederic clere wrote: Thorsten Kamann wrote: Hello, Henri Gomez schrieb: Well I didn't like very well the hardcoded way, so I'd like to have it externally. We could : Define a stylesheet property var in workers2.properties, which will contains a full URL and if this var is null, fallback to previous method. Is there a chance the jk provides the status as xml? So the status can checked programmatically. With an nice XSL-Stylesheet I can integrate the status in every monitor page . Your comments? Sounds a good idea to me. Hmm .. separating the view from the model ... now where have I heard that before? :-) No problem for me to provide the result in XML, since I've got friend aroud which could provide me some nice XSL still sheet. Second advantage, the jkstatus could be used by others apps for example for monitoring purposes. +0 for XML (lack of time to works on this ;(). So we should now define a DTD. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jk2 and debug on specials uri
Hi to all, A quick question : I've got the following in a VirtualHost (Apache 2): Location /examples/* JkUriSet group lb Location I'd like to have this /examples/ uri in debug and wonder how to do it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
GzipInputFilter in Coyote/HTTP11
I'm playing with compression actually and I see that we don't have GzipInputFilter. Apache 2.0 mod_deflate has support for it and it could be usefull. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GzipInputFilter in Coyote/HTTP11
Remy Maucherat wrote: Henri Gomez wrote: I'm playing with compression actually and I see that we don't have GzipInputFilter. Apache 2.0 mod_deflate has support for it and it could be usefull. It's a rather specific need, but if you can add it why not. (and the issue is the same as the output: to make it efficient, we would need a straight recyclable array based deflate implementation) Well I see that support has been present and removed. You could see in mod_deflate that GZIP input should be activated only if Content-Encoding contains gzip. mod_deflate also check for the 2 first bytes to contains magic, ie, 1F 8B and very that fourth byte is 00. if deflate didn't find these, it consider the input is not compressed. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
NormW wrote: Good morning All. Just tried Jean's recent change to mod_jk2.c and _pleased_ to say JkUriSet now registers correctly the same as a [uri] section, and can access /admin with only a Location in the httpd.conf. I did note there were duplicate uri objects created (based on their name) if the same uri spec was in both files, but in any case this is a lot closer to theory than in the past. Thanks Jean. Norm This code update will need many testings, and if no problem are found, I suggest a quick 2.0.5 release. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion - /jkstatus and stylesheets
NormW wrote:
Hi from Down Under.
Hi,
As an alternative to the above method I suggest use of an 'external'
stylesheet, which has the following advantages:
[snip]
1. Implement a stylesheet that emulates the current default colour/style
scheme,
2. Have the Developers choose one obtained by any method,
3. Make a 'request for suggestions' on the TC-user list.
I would like to suggest a 4. one:
test for presense of the the style property, and if not present fallback to
the hardcoded style Henri introduced.
* I don't see this as another method to obtaining a default stylesheet but
rather what to do if one isn't defined, much like so I guess:
if( style != NULL) {
s-jkprintf(env, s, LINK REL=stylesheet TYPE='text/css'
HREF='%sjkstatus.css'\n, style );
}
else {
s-jkprintf(env, s, style%s/style\n, DEFAULT_CSS);
}
Admittedly Henri's default style data isn't a big baggage, but another
approach would be to not output any style format at all in the 'else' case,
such as:
if( style != NULL) {
s-jkprintf(env, s, LINK REL=stylesheet TYPE='text/css'
HREF='%sjkstatus.css'\n, style );
}
which is what /jkstatus was doing until Henri added the style block
recently.
Well I didn't like very well the hardcoded way, so I'd like to have it
externally.
We could :
Define a stylesheet property var in workers2.properties, which will
contains a full URL and if this var is null, fallback to previous method.
What about ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: -Original Message- From: jean-frederic clere What do you want to do? - Call native methods in TC to get PHP running. - Write a servlet engine that understands PHP. (Well the problem would be the libraries). If a majority of my web content is a dynamic one, delivered through JSP, PHP, or what ever, why would I need a dummy web server as an intermediate? That's my thoughts. True, I'm thinking of having native connection to PHP, but that's irrelevant compared to the concept itself. Nowadays we are having connectors (to the so called mighty webservers) to the TC, but I'd like to rotate that a bit. Static content is becoming less and less significant than before, and I cannot imagine a ISP provider that doesn't offer some dynamic content 'connector'. I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. Interesting idea Mladen. +0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Henri Gomez wrote: Mladen Turk wrote: -Original Message- From: jean-frederic clere What do you want to do? - Call native methods in TC to get PHP running. - Write a servlet engine that understands PHP. (Well the problem would be the libraries). If a majority of my web content is a dynamic one, delivered through JSP, PHP, or what ever, why would I need a dummy web server as an intermediate? That's my thoughts. True, I'm thinking of having native connection to PHP, but that's irrelevant compared to the concept itself. Nowadays we are having connectors (to the so called mighty webservers) to the TC, but I'd like to rotate that a bit. Static content is becoming less and less significant than before, and I cannot imagine a ISP provider that doesn't offer some dynamic content 'connector'. I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. Interesting idea Mladen. +0 Next idea. If we drop Apache 2.0 support we need to have jk/jk2 jobs done somewhere : What about Tomcat 5 Coyote as a ajp13 dispatcher with advances and fine tuning rules, which could be updated in real time in via JMX ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug: jk2 2.0.4 vs. mod_dir
Jess Holle wrote: Sorry, I should have said mod_alias, not mod_dir... With Apache 1.3 or 2.0 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug: jk2 2.0.4 vs. mod_dir
Jess Holle wrote: Henri Gomez wrote: Jess Holle wrote: Sorry, I should have said mod_alias, not mod_dir... With Apache 1.3 or 2.0 ? 2.0.49 on Windows. I have not tried Solaris or AIX yet. [I have not bothered with mod_jk2 with Apache 1.3 -- I just use mod_jk there on an old with old sort of principle.] I can produce a more definitive test case as needed. I poked around in the sources -- diffing them with 2.0.2 sources, etc, but I couldn't quickly find the issue. Settings and test case of course more than welcome :=} - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 tagged
Mladen Turk wrote: One thing regarding .zip dist. All .dsp and .dsw files should be converted to CRLF. Henri, can you do that? (I'm low on badwith :) ASAP Othervise we'll need to put the comment on that user need to convet them by itself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
