Apache and Tomcat connectivity,

Posted by Jim Jagielski on Monday, July 16. 2007 in Programming

Mladen has a nice post comparing mod_jk and mod_proxy_ajp from his point of view. His recommendation is that, for most people, mod_jk makes more sense than mod_proxy_ajp (m_p_a), and I can certainly understand that POV. He does mention, however, that one reason for his recommendation is the lack of parity between mod_jk and m_p_a, like with the load balancer code, and although mod_jk does have an additional method (busyness), he fails to mention that the design of mod_proxy_balancer is such that one can easily extend and add addition load balancing methods to mod_proxy with no changes to the core Apache code. Since in mod_proxy, the load balancer implementation uses normal Apache providers, one can create addition mod_proxy sub-modules that implement new providers that the load balancer code can then use. With mod_jk, the load balancer methods are very, very tightly entwined making adding new methods very hard and certainly not something one can do without major changes to the mod_jk source. Mladen also mentions the "maintenance" aspect of mod_jk, which, again, could be a useful feature for mod_proxy itself. However, the actual maintenance itself does incur a noticable overhead, which, at least in my opinion and in testing, offsets any such "improvements" in proposed efficiency of the whole scheme. It also, again at least in my opinion, tries to introduce a time scale (and thus, some sense of "history") into a design which should be time ignorant. In other words, the decay aspects of the maintenance implementation is such that "older" values have less importance than more "recent" ones. IMO, load balancing should be akin to a quick, efficient state table; the selection and hand-off should be as quick as possible and the more you try to "perfect" the "correctness" of load balancing, the slower the actual handling of the pass-off will be. If you want to do so, however, I can envision several LB methods where that makes sense, but to make it a universal aspect of the core balancer itself seems almost unwise. Why, for example, should a "by_randomness" or "by_roundrobin" method even care? In any case, I do agree that there are some aspects of current mod_jk functionality (incl some LB concepts) that would be useful to backport to mod_proxy itself, because this also means that not only AJP but also HTTP proxies would benefit. And, this also implies that the "best" way to connect Apache and Tomcat is via AJP itself, a statement which I may not totally agree with :-)

Long time

Posted by Jim Jagielski on Thursday, July 5. 2007 in Junk Drawer

Geez... it's been almost a month since I last blogged... Obviously, I still don't make it a priority and when blog-thoughts pop into the old noggin, I think "Nah, that would make a pretty bogus and meaningless entry" and so don't post anything... I still feel that blog entries need to be "important", and I guess my standards are too high (and therefore I self-censor a lot more than I should). So where to start: Events are manna from heaven. Although I agree that we should continue making Apache more event "aware", I remain unconvinced that event-based servers are, in and of themselves, "better" especially as the issues which are problematic for non-event-based servers become resolved and improved. The cool thing about Apache MPMs is that *you* decide which impl makes sense for your environment; no "one size fits all" approach. For people using XML/XSLT and making the move from PHP4 to PHP5, xslt-php4-to-php5.php and domxml-php4-to-php5.php save you some time until you can port the code the right way. JSR 315 RMS: Open mouth, insert foot

Page 1 of 1, totaling 2 entries


Search for an entry in IMO:

Did not find what you were looking for? Post a comment for an entry or contact us via email!