> 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
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
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
> 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