Hi, Stargazer escribió: > I am experiencing server memory leaks in my http child processes. I > can't nail these down and they have been present for literally years, > always using mod_caucho. I fix them by limiting the requests they serve > in apaches httpd.conf - not ideal. Now I'm not pointing the finger here, > far from it, but this approach is excellent as another test for me to > perform. Sincere thanks...!
We started with this approach long long ago when the first mod_jk versions were born. They were quite buggy and each new version always brought new problems. Moreover, we've had to "live" in a special OS for long time, Digital Unix, which for us means that native code is not fixed as soon as in other more popular platforms, even in popular projects. To tell you the truth, we never tried using mod_caucho as by the time we moved to Resin, around version 1.2.1 IIRC, we have already opted for the policy of using mod_proxy and avoiding native modules. > I'd need to do all the virtual hosts plus their webapps - defined as > such in both apache and resin. Your example suggests just webapps? Also > SSL? In our case, we have the virtual hosts defined at the Apache level, the internal application servers just have a common name and a private internal IP. Each application server might hold a couple of Resin instances with a couple of applications each so the Apache decides, depending on virtual host and virtual path to which host/port/webapp needs to proxy the request. Real client IPs are added to the headers by the mod_proxy module (one has to take this into account as one cannot trust request.getRemoteHost() any longer). I understand that if an application has to modify its behaviour depending on the virtual host that has been called, one would need to be able to distinguish them at the Resin level, so something would need to be added. Regarding SSL, Apache is the one that handles the SSL traffic and we have applications that are proxied just through the "SSL virtual server". Traffic between the Apache server and the application server is not encripted as it is internal traffic. In our case, that's enough, I understand that might not be the case in some scenarios. > Does this impact resins sticky session handling? Performance? Well, if I get you correctly, resin handling sticky sessions means ONE resin instance gets all the requests and redirects them to the appropriate cluster instance respecting the sticky sessions. In this case Apache in front would only add a layer of indirection. OTOTH, If you wanted to use Apache to redirect directly to the cluster instances, you would need to configure Apache to honor the "stickiness" of the sessions. We tested it adding mod_proxy_balancer to the mix and using cookie-append-server-index in Resin so Apache can have something to know wich server to redirect to. However, I have to say we have not used it in production yet, as our successful efforts to optimize the server configuration all through these years have been always "rewarded" with having just one server... so we don't have anything to balance it against :D. Regarding performance, we have done no tests, as going native is really not an option for us, but there probably is some penalty, as native modules are supposed to be more efficient. If that is significant vs the overall response time probably depends on your type of traffic and server load... > Basically, there must be some downside or there would be no need for > mod_caucho at all. Plus my infamous bug > http://bugs.caucho.com/view.php?id=3013 could have been sidestepped 6 > months earlier than it took :-( As I said, I guess there probably is some performance penalty, important or not depending on your profile, but we have never felt the need to use native modules, so I'm not the right man to list the advantages of doing so :). The other difference is the remote host swap, but we implemented the routines to get the remote host from the X-Forwarded-For header a long time ago, so it's not an issue for us. If you use the REMOTE_HOST for anything, you have to take this into account. If there is something else one can do with native modules that one cannot do with pure apache modules, we have not needed it, yet. In any case, it might be a quick emergency fix to work around the bug while you move to a Resin-only approach. S! D. _______________________________________________ resin-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/resin-interest
