You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Todd Simons <ts...@gmail.com> on 2015/02/09 02:22:29 UTC
[users@httpd] Any Comparisons? -- mod_wl vs mod_proxy vs mod_jk
Hello All
We've been using the generic mod_proxy for years. We utilize Apache to
layer in HTTPS from the world into our DMZ, then utilize
proxypass/proxypassreverse to our internal servers. Our internal servers
vary between iis, weblogic, tomcat, and a few others.
mod_proxy has been working great for us.
Recently I've been asked why not mod_wl and mod_jk. I really have no
answer and I haven't been able to find much online with regards to
advantages of one vs another.
Has anyone seen, or have, any links that can help outline the difference?
Thanks,
~Todd
Re: [users@httpd] Any Comparisons? -- mod_wl vs mod_proxy vs mod_jk
Posted by Todd Simons <ts...@gmail.com>.
Thanks All. I'm quite happy with mod_proxy, I just wanted to make sure I
wasn't missing the boat on mod_wl.
It seems as if mod_wl has some advanced features if you were using
clustering, etc on the back end.
~Todd
On Mon, Feb 9, 2015 at 9:01 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> You could always try mod_proxy_ajp, which uses the mod_proxy framework,
> but communicates via AJP. It's better at detection of silently
> dropped AJP connections.
>
> > On Feb 9, 2015, at 3:18 AM, Dr James Smith <js...@sanger.ac.uk> wrote:
> >
> >
> > We used mod_jk for ages and have recently flipped back to mod_proxy for
> our java/tomcat apps, we found that we had connectivity issues with mod_jk
> - if the connection between apache/tomcat is severed then mod_jk did not
> always work cleanly - and subsequent requests would just hang. mod_proxy
> didn't have the problem.
> >
> > The problem showed it self when we started segregating machines into
> virtual firewall zones - so traffic between machines was controlled.
> >
> > It does mean that we don't have as easy a load-balanced setup -
> although we do send the requests back through our front-end load balancers
> and this seems effective.
> >
> > James
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > http://www.avast.com
> >
> >
> >
> > --
> > The Wellcome Trust Sanger Institute is operated by Genome Research
> Limited, a charity registered in England with number 1021457 and a company
> registered in England with number 2742969, whose registered office is 215
> Euston Road, London, NW1 2BE.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> > For additional commands, e-mail: users-help@httpd.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: [users@httpd] Any Comparisons? -- mod_wl vs mod_proxy vs mod_jk
Posted by Jim Jagielski <ji...@jaguNET.com>.
You could always try mod_proxy_ajp, which uses the mod_proxy framework,
but communicates via AJP. It's better at detection of silently
dropped AJP connections.
> On Feb 9, 2015, at 3:18 AM, Dr James Smith <js...@sanger.ac.uk> wrote:
>
>
> We used mod_jk for ages and have recently flipped back to mod_proxy for our java/tomcat apps, we found that we had connectivity issues with mod_jk - if the connection between apache/tomcat is severed then mod_jk did not always work cleanly - and subsequent requests would just hang. mod_proxy didn't have the problem.
>
> The problem showed it self when we started segregating machines into virtual firewall zones - so traffic between machines was controlled.
>
> It does mean that we don't have as easy a load-balanced setup - although we do send the requests back through our front-end load balancers and this seems effective.
>
> James
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> http://www.avast.com
>
>
>
> --
> The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Any Comparisons? -- mod_wl vs mod_proxy vs mod_jk
Posted by Dr James Smith <js...@sanger.ac.uk>.
We used mod_jk for ages and have recently flipped back to mod_proxy for
our java/tomcat apps, we found that we had connectivity issues with
mod_jk - if the connection between apache/tomcat is severed then mod_jk
did not always work cleanly - and subsequent requests would just hang.
mod_proxy didn't have the problem.
The problem showed it self when we started segregating machines into
virtual firewall zones - so traffic between machines was controlled.
It does mean that we don't have as easy a load-balanced setup -
although we do send the requests back through our front-end load
balancers and this seems effective.
James
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Any Comparisons? -- mod_wl vs mod_proxy vs mod_jk
Posted by Daniel <df...@gmail.com>.
Hello Nick (niq), ezra-s here.
I don't vouch for oracle documentation as inquestionable but I'll try to
explain the best I can in my experience.
WLSRequest on
* Lower overhead with WLSRequest on as opposed to SetHandler
weblogic-handler common method to handle when locations / extensions should
be proxied to weblogic backend.
* Documentroot on slow filesystem, as of nfs, I have experiened this.
* Resolves 403 errors for URIs which cannot be mapped to the
For what I understand it means that filesystem is not checked with
WLSRequest, but it is when you use the common SetHandler weblogic-handler
method to make a specific location/file be proxied to weblogic server.
About "filesystem length restrictions" I also have seen this with requests
with a very long uri, we even have had some queries about this one in
#httpd. Not sure it 100% related, but when compiling apr "make test" will
report an error for this too, in ext4 at least, haven't checked others
filesystems.
Regards (don't punish me too much! ;P)
2015-02-09 10:52 GMT+01:00 Nick Kew <ni...@webthing.com>:
> On Mon, 2015-02-09 at 08:13 +0100, Daniel wrote:
>
>
> > Has anyone seen, or have, any links that can help outline the
> > difference?
>
> Questions like that very often get answers based on comparing
> a new-and-better solution against something ancient -
> like a 1997 apache version.
>
> There's nothing wrong with this answer in particular,
> but I think answers like this do need challenging
> (you've got another followup that appears to be
> premised on an outdated description of mod_proxy).
>
> > * Lower web server processing overhead in general
>
> Lower than what? And why?
>
> > * Resolves substantial performance degradation when the web server
> > DocumentRoot is on a slow filesystem
>
> Bizarre. Why would you put document root on a slow filesystem?
> In any case, proxy requests run without reference either to
> documentroot or the filesystem. Unless you go out of your way
> to make your server complex and inefficient!
>
> > * Resolves 403 errors for URIs which cannot be mapped to the
> > filesystem due to the filesystem length restrictions
>
> WTF? Filesystem length restrictions? That smells of MSDOS
> 8.3 filenames. Is there really any modern platform that
> might be affected, or was the author of that scraping the
> bottom of the barrel for marketing claims?
>
> I'm sure mod_wl has its merits, but claims like these do
> it no favours. Or can you substantiate them?
>
> --
> Nick Kew
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
--
*Daniel Ferradal*
IT Specialist
email dferradal@gmail.com
linkedin es.linkedin.com/in/danielferradal
Re: [users@httpd] Any Comparisons? -- mod_wl vs mod_proxy vs mod_jk
Posted by Jeff Trawick <tr...@gmail.com>.
On Feb 9, 2015 4:53 AM, "Nick Kew" <ni...@webthing.com> wrote:
>
> On Mon, 2015-02-09 at 08:13 +0100, Daniel wrote:
>
>
> > Has anyone seen, or have, any links that can help outline the
> > difference?
>
> Questions like that very often get answers based on comparing
> a new-and-better solution against something ancient -
> like a 1997 apache version.
>
> There's nothing wrong with this answer in particular,
> but I think answers like this do need challenging
> (you've got another followup that appears to be
> premised on an outdated description of mod_proxy).
>
> > * Lower web server processing overhead in general
>
> Lower than what? And why?
>
> > * Resolves substantial performance degradation when the web server
> > DocumentRoot is on a slow filesystem
>
> Bizarre. Why would you put document root on a slow filesystem?
> In any case, proxy requests run without reference either to
> documentroot or the filesystem. Unless you go out of your way
> to make your server complex and inefficient!
>
> > * Resolves 403 errors for URIs which cannot be mapped to the
> > filesystem due to the filesystem length restrictions
>
> WTF? Filesystem length restrictions? That smells of MSDOS
> 8.3 filenames. Is there really any modern platform that
> might be affected, or was the author of that scraping the
> bottom of the barrel for marketing claims?
>
> I'm sure mod_wl has its merits, but claims like these do
> it no favours. Or can you substantiate them?
You're bitching about something that was from product release notes or
other documentation, not what the poster somehow made up about closed
source code from Oracle.
These were improvements relative to earlier versions of the WLS plugin,
which required the use of httpd's "handler" mechanism for configuration,
which in turn led to a filesystem walk by httpd.
Filesystems don't support the relatively unlimited length resource names
that applications can, so the filesystem check can break an otherwise
viable name.
The type of filesystem of DocumentRoot shouldn't matter intuitively when
you're using httpd solely as a proxy, but using the "handler" configuration
mechanism results in unexpected degradation if the filesystem isn't
consistently very fast.
>
> --
> Nick Kew
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
Re: [users@httpd] Any Comparisons? -- mod_wl vs mod_proxy vs mod_jk
Posted by Nick Kew <ni...@webthing.com>.
On Mon, 2015-02-09 at 08:13 +0100, Daniel wrote:
> Has anyone seen, or have, any links that can help outline the
> difference?
Questions like that very often get answers based on comparing
a new-and-better solution against something ancient -
like a 1997 apache version.
There's nothing wrong with this answer in particular,
but I think answers like this do need challenging
(you've got another followup that appears to be
premised on an outdated description of mod_proxy).
> * Lower web server processing overhead in general
Lower than what? And why?
> * Resolves substantial performance degradation when the web server
> DocumentRoot is on a slow filesystem
Bizarre. Why would you put document root on a slow filesystem?
In any case, proxy requests run without reference either to
documentroot or the filesystem. Unless you go out of your way
to make your server complex and inefficient!
> * Resolves 403 errors for URIs which cannot be mapped to the
> filesystem due to the filesystem length restrictions
WTF? Filesystem length restrictions? That smells of MSDOS
8.3 filenames. Is there really any modern platform that
might be affected, or was the author of that scraping the
bottom of the barrel for marketing claims?
I'm sure mod_wl has its merits, but claims like these do
it no favours. Or can you substantiate them?
--
Nick Kew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
AW: [users@httpd] Any Comparisons? -- mod_wl vs mod_proxy vs mod_jk
Posted by An...@bmw.de.
Hello,
mod_wl has some advantages, mod_proxy does not support i.e. mod_proxy does normally only a ping to check if a backend server is available, which normally works in 99% even if the web-application behind is not available, so it is possible that mod_proxy routes the request to /backend even if /backend is not yet available, because the application server has not loaded the application yet.
This means mod_wl does a little bit more then just checking if the backend server is available via ping, it even checks if the backend url gives a working response. Also mod_wl gets information about the all current cluster members within the session cookie, so if a server is not available anymore he directly knows, which cluster members the plugin can forward the request. Also to simulate the load balancing with mod_proxy in front of a weblogic, this must be done via a ROUTE_ID within the Apache and can not be done via the sessionid like it is done with Glassfish or Tomcat.
But it also has currently some disadvantages i.e. certificate handling via oracle wallets.
Currently all our instances are running with mod_proxy and we have normally no problems, only in the case an application on ONE cluster member breaks, so that the application server is still available but not the application, so in this case the only feature I’m currently missing within mod_proxy is an check URL feature.
Cheers,
André
Von: Daniel [mailto:dferradal@gmail.com]
Gesendet: Montag, 9. Februar 2015 08:13
An: <us...@httpd.apache.org>
Betreff: Re: [users@httpd] Any Comparisons? -- mod_wl vs mod_proxy vs mod_jk
2015-02-09 2:22 GMT+01:00 Todd Simons <ts...@gmail.com>>:
Hello All
We've been using the generic mod_proxy for years. We utilize Apache to layer in HTTPS from the world into our DMZ, then utilize proxypass/proxypassreverse to our internal servers. Our internal servers vary between iis, weblogic, tomcat, and a few others.
mod_proxy has been working great for us.
Recently I've been asked why not mod_wl and mod_jk. I really have no answer and I haven't been able to find much online with regards to advantages of one vs another.
Has anyone seen, or have, any links that can help outline the difference?
Thanks,
~Todd
I can tell you about a bit the weblogic plugin.
Latest versions include WLSRequest directive that, according to its documentation:
* Lower web server processing overhead in general
* Resolves substantial performance degradation when the web server DocumentRoot is on a slow filesystem
* Resolves 403 errors for URIs which cannot be mapped to the filesystem due to the filesystem length restrictions
Among the interesting things it offers weblogic plugin dinamically updates the weblogic cluster members on first connection, no matter if you didn't specify all members of the cluster.
For all related info I would suggest you to check the documentation page which describes everything it can do:
http://docs.oracle.com/middleware/1213/webtier/PLGWL/toc.htm
In any case, if you are happy with your actual solution, why change?
--
Daniel Ferradal
IT Specialist
email dferradal@gmail.com<ma...@gmail.com>
linkedin es.linkedin.com/in/danielferradal<http://es.linkedin.com/in/danielferradal>
Re: [users@httpd] Any Comparisons? -- mod_wl vs mod_proxy vs mod_jk
Posted by Daniel <df...@gmail.com>.
2015-02-09 2:22 GMT+01:00 Todd Simons <ts...@gmail.com>:
> Hello All
> We've been using the generic mod_proxy for years. We utilize Apache to
> layer in HTTPS from the world into our DMZ, then utilize
> proxypass/proxypassreverse to our internal servers. Our internal servers
> vary between iis, weblogic, tomcat, and a few others.
>
> mod_proxy has been working great for us.
>
> Recently I've been asked why not mod_wl and mod_jk. I really have no
> answer and I haven't been able to find much online with regards to
> advantages of one vs another.
>
> Has anyone seen, or have, any links that can help outline the difference?
>
> Thanks,
> ~Todd
>
I can tell you about a bit the weblogic plugin.
Latest versions include WLSRequest directive that, according to its
documentation:
* Lower web server processing overhead in general
* Resolves substantial performance degradation when the web server
DocumentRoot is on a slow filesystem
* Resolves 403 errors for URIs which cannot be mapped to the filesystem due
to the filesystem length restrictions
Among the interesting things it offers weblogic plugin dinamically updates
the weblogic cluster members on first connection, no matter if you didn't
specify all members of the cluster.
For all related info I would suggest you to check the documentation page
which describes everything it can do:
http://docs.oracle.com/middleware/1213/webtier/PLGWL/toc.htm
In any case, if you are happy with your actual solution, why change?
--
*Daniel Ferradal*
IT Specialist
email dferradal@gmail.com
linkedin es.linkedin.com/in/danielferradal