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.


resin-interest mailing list

Reply via email to