Are there instructions for using Apache HTTP as a front end for tc Server?

[ThomBrando]

I need to integrate applications running in tc Server with a single sign-on domain implemented with CA SiteMinder. That means I need to put an Apache HTTP server "in front of" tc Server.

I found instructions on the Apache site for connecting the HTTP server with Tomcat. Are there specific instructions for connecting an Apache HTTP server with tc Server? If not, do the instructions on the Apache site apply?

Thom

[jpreston]

ThomBrando,

AFAIK, tc Server is essentially Tomcat with Spring extras. That said, the same rules of usage with Apache HTTP are the same. Basically, you have a few options (off the top of my head):

1. mod_jk
2. mod_proxy
3. mod_proxy_ajp

Of those, I'd highly recommend mod_proxy_ajp if you have that available to you as it is the easiest to configure, maintain and administer. In terms of your question, yes, the instructions on the Apache site should apply.

Hope that helps,

[ThomBrando]

Yes, it does. Thanks.

I had hoped that, in preparing Tomcat for the enterprise, the folks at SpringSource might've provided support for configuring tc Server with an HTTP server. I've tried using the mod_jk approach in the past (with Tomcat, not tc Server), without luck. Hopefully, mod_proxy_ajp will be easier to configure, as you say.

Thanks again!

Thom

[jpreston]

Thom,

It is indeed very easy to get it going. Load balancing it is a little more work, but still pretty easy. I don't remember if mod_proxy_ajp is specific to Apache HTTP 2.2, but it very might well be.

The basic setup for a single tomcat instance looks something like:

1. Load mod_proxy_ajp
2. Configure the proxy

IE:

LoadModule proxy_ajp_module modules/mod_proxy_ajp.so

ProxyPass /myapp ajp://tomcat.server.domain.local:8009/myapp
ProxyPassReverse /myapp ajp://tomcat.server.domain.local:8009/myapp

That's usually all it takes; which is why I like it so much :-)

However, even if you can't turn on or use AJP, you should be able to just as easily use:

ProxyPass /myapp http://tomcat.server.domain.local:8080/myapp
ProxyPassReverse /myapp http://tomcat.server.domain.local:8080/myapp

Sometimes, and I repeat SOMETIMES, you may need to specify other options as well, such as:

• ProxyPassReverseCookieDomain internal-domain public-domain
• ProxyPassReverseCookiePath internal-path public-path

You can refer to the mod_proxy manual at http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

Hope that helps,

[dcarwin]

Hi Thom and Josh,

Couple notes:

With due respect and big thanks to Josh for offering help here, if you're using Apache 2.2 as the front-end, we recommend the connection methods in the following order:

1. mod proxy http
2. mod jk
3. mod proxy ajp

The HTTP protocol by virtue of it being human-readable (versus AJP 1.3 which is binary) is by far the easiest to troubleshoot and thus maintain.

Mod_JK is the older standard (circa Apache 1.3 and 2.0), but with the functionality advances in the proxy family of modules in Apache 2.2 including load balancing with sticky sessions, the HTTP proxy module is now the easiest and best way to go.

The mod_proxy_ajp module is the youngest of the three, and at this point in time is the least stable/reliable. (This may change in the the future.)

[note: There may be some slight performance benefit with the AJP protocol due to it being binary, but this slight speed benefit if measurable is outweighed by the transparency of the HTTP protocol. (i.e. it can be sniffed in case of an issue). AJP connection issues can be very difficult to debug.]


Resources:


Here is a link to an older webinar [PPT] on the topic of comparison of the three approaches. It covers the topic in great detail:

http://www.springsource.com/files/Ap...omcatFinal.pdf

Here is a more recent webinar with more info on proxy in general:

Full webinar recording
[note: reg required for newer webinar, and PPT available]

With regards to the configuration of the Apache as a reverse proxy to Tomcat, tcServer will behave identically to standard Tomcat, and thus you need only have the appropriate listener enabled in server.xml. If you use mod_proxy_http, there is no additional configuration on the tcServer side, as the http listener is already enabled out of the box.



Configuring Apache HTTPD as a reverse proxy to tcServer is mainly done on the Apache HTTP side, and you can leverage the documentation provided by the ASF:

http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

http://httpd.apache.org/docs/2.2/mod....html#examples

Some sample config taken from the webinar slides:

<Proxy balancer://foo>
   BalancerMember http://php1:8080/     loadfactor=1
   BalancerMember http://php2:8080/     loadfactor=4
   BalancerMember http://phpbkup:8080/  loadfactor=4 status=+h
   ProxySet lbmethod=bytraffic
</Proxy>

<Proxy balancer://japps>
   BalancerMember ajp://tc1:8089/     loadfactor=1
   BalancerMember ajp://tc2:8089/     loadfactor=4
   ProxySet lbmethod=byrequests
</Proxy>

ProxyPass /apps/ balancer://foo/
ProxyPass /serv/ balancer://japps/

ProxyPass /images/ http://images:8080/

Thom said:

"I had hoped that, in preparing Tomcat for the enterprise, the folks at SpringSource might've provided support for configuring tc Server with an HTTP server."

As you can see above, the configuration of Apache as a front end to Tomcat (or tcServer) is done on the Apache side, and thus outside the scope of tcServer config. We do have an enhanced version of the Apache webserver on our roadmap, and preconfiguration for a tcServer back end will be part of that release. We currently offer a distribution of the Apache HTTP webserver called Enterprise Ready Server (ERS) and it comes preconfigured to talk to a Tomcat back end.

Regards,
Dan Carwin
SpringSource

[dcarwin]

I wanted to follow up and provide some more detailed info on setting up the reverse proxy. My environment is ERS Apache 2.2.9, but this should work for other Apache 2.2.x as well. (Though things may change slightly for the better when 2.2.12 is released)



1. Load the proxy balancer module
=================================
I needed to add this line, as I do not think this module is loaded in the default ERS module set. Make sure the other two required modules are also loaded and not commented out: mod_proxy and mod_proxy_http.

LoadModule proxy_balancer_module     "/<your install path>/apache2.2/modules/standard/mod_proxy_balancer.so"

2. Add the proxy config:
========================

#DAN PROXY LB TEST
<Proxy balancer://dan_two>
   BalancerMember http://192.168.0.203:8081  route=ONE loadfactor=50
   BalancerMember http://192.168.0.203:8082  route=TWO loadfactor=50
   ProxySet lbmethod=byrequests
</Proxy>

ProxyPass /swf-booking-mvc balancer://dan_two/swf-booking-mvc
ProxyPassReverse /swf-booking-mvc http://192.168.0.203:8081/swf-booking-mvc
ProxyPassReverse /swf-booking-mvc http://192.168.0.203:8082/swf-booking-mvc

3. [Optional] Enable the balancer-manager to watch the activity and control the behavior
================================================== ======================================
The mod_status module must be loaded.

Add the following to the Apache httpsd.conf file:

<Location /balancer-manager>
   SetHandler balancer-manager
   Order Deny,Allow
   Deny from all
#  BE VERY RESTRICTIVE with YOUR ALLOW STATEMENT
   Allow from 127.0.0.1
</Location>

4. [Optional] Enable sticky sessions by setting jvmRoute in Tomcat
================================================== ================
In each of the back end Tomcat servers, edit the server.xml and modify the <Engine> element:

Before:

<Engine defaultHost="localhost" name="Catalina">

After:

<Engine defaultHost="localhost" name="Catalina" jvmRoute="ONE">

Repeat for each tomcat instance, setting the correct and unique jvmRoute. Each jvmRoute matches the route value on the Apache side.

===END===

This should enable Apache as a load-balanced reverse proxy.
Be sure to clear browser cache frequently when testing.

[jpreston]

dcarwin,

Thanks for the clarification ;-)

I just wanted to make sure he was pointed in the right direction. I have not and do not use tcServer, but rather am just a fan of the Spring Framework in general and found some enjoyment in becoming a contributing forum squatter / troll... I just want to make sure every question that I have at least *some* knowledge about gets answered timely.

I have a couple of questions for you, since you seem to have a firm grasp on the subject; probably more so than I...

I don't recall seeing anywhere the mod_proxy_ajp approach was not recommended due to stability, performance or the relative age of the project. Albeit for debugging purposes, HTTP traffic is dramatically easier to debug than any binary lingo. Do you have any reference or documentation where the mod_proxy_ajp approach is not recommended for production use or are you garnering it due to its relative age (being the newest)?

AFAIK, the mod_proxy_ajp isn't really a full module in and of itself, rather it enables the use of ajp://*.* proxied URLs with mod_proxy and handles the AJP "conversation" vs an HTTP "conversation", am I correct in that assumption?

Regards,

[dcarwin]

Hi Josh,

Thanks again for offering help to Thom. Please continue to be active and contribute as you are.

Do you have any reference or documentation where the mod_proxy_ajp approach is not recommended for production use or are you garnering it due to its relative age (being the newest)?

No, I don't know of any such public documentation either. I base my recommendation on the feedback from the Apache and Tomcat engineers who work on staff here and also in the field troubleshooting production issues for our customers. Each of the modules is functional, and we support all three, this is just our recommendation as of today based on field experience.

Yes you are correct in your understanding that mod_proxy_ajp (as well as mod_proxy_http) requires mod_proxy. Each of these two modules provide protocol support for the proxy module. Mod_proxy_ajp is new for 2.2, as is mod_proxy_balancer.

Regards,
Dan

[jpreston]

Dan,

Good to know that I'm not *THAT* far off base! I've successfully used mod_proxy_ajp in about 10 different solutions and so far none of them have experienced any issues, which is why I asked the question. I think the biggest hurdle I've run into with a mod_proxy approach is the use of cookies, but that was easily handled with correct settings in the proxy side.

I do plan on continuing to help if/when I can and I appreciate you getting back so fast!!

Regards,