Apache Jakarta (Tomcat) Connector to forward traffic to specific Tomcat - apache

There is one use case I am unable to solve so far with the Apache Jakarta (Tomcat) Connector load balancing feature.
I have one IIS site which has one Apache Tomcat Connector attached to it. I need to "forward" the traffic to a different Tomcat depending on the URI that is requested. It is pretty simple to do when you only have apps with a specific context (like /app1, /app2, etc). My problem is that I have one app (in one Tomcat) that is at / (ROOT) and one other app (in another Tomcat) that is at /app1.
I have tried the following config in uriworkermap.properties:
/*=loadBalancer1
/app1/*=loadBalancer2
But this doesn't work, because "loadBalancer1" takes all the traffic. "loadBalancer2" is being ignored, which make sense, since /app1/* matches /* (regexp wise).
I also tried adding a exclusion as so:
/*=loadBalancer1
!/app1/*=loadBalancer1
/app1/*=loadBalancer2
But that doesn't work either, because "loadBalancer1" is still taking all the traffic, but just ignoring that "/app1/*" URI pattern. "loadBalancer2" is simply ignored again.
Any suggestion, keeping in mind that I cannot have 2 IIS sites, nor can I move the app that is at / (ROOT) to a different context path in Tomcat?
Thank you
Edit:
Instead of using just one Apache Tomcat Connector, I use 1 connector for each Tomcat on the same IIS site.
uriworkermap.properties #1: for Tomcat with app at / (ROOT)
/*=wlb
!/app1/*=wlb
uriworkermap.proerties #2: for Tomcat with app at /app1
/app1/*=wlb
Connector #1 will ignore traffic on URI "/app1/*", but connector #2 will catch it (and vice versa).
Now I can set different VM options and memory allocation to my apps!
I am open to comments or better solution..

Does it work when you reverse it as such ?
/app1/*=loadBalancer2
/*=loadBalancer1

Related

Seamlessly hosting different parts of a website in different docker containers

I have a website that I am trying to convert to a docker-compose solution.
Part of the website is a CMS (WordPress, specifically), and there are also a few Java web applications that are currently handled by tomcat.
The current approach is that I have an official WordPress container and an official Tomcat container. I load my custom content in the WordPress (via a MySQL container which is not really a part of this question) and the WAR files into tomcat.
So the problem is this:
Parts of the WordPress website have links to Java applications. Previously, some of these links were relative links as simple as /Application1 and the user would be able to access the Java application.
Now, since they are hosted in separate containers, I cannot do this because there is nothing named "Application1" in the WordPress container. I have modified the htaccess file for the WordPress container with a RewriteRules like this:
# Tomcat exposes port 8085
RewriteRule ^.*Application1/(.*)$ http://localhost:8085/Application1/$1 [R,L]
But this means that if the user clicks the link for Application1 in wordpress, their browser will then redirect them to localhost:8085 - which works fine if you run this set of containers locally, but does not work for remote users.
I could change localhost to the actual name of the server this will run on. But then it would need to be manually updated for every server this stack will run on, or reset to localhost for developers.
I could combine WordPress and Tomcat into a single container, but we were hoping to keep them separate so that when we need to upgrade, we just change the version of the container we are pulling rather than having to rebuild a custom container from scratch.
Is there a more seamless way to do this, so that the URL in the user's browser never changes? Is there way to get this working so that remote users won't even know that the different parts of the site are hosted in different containers?
Assuming you do docker-compose in development and also in production, you replace localhost with servicename of the corresponding upstream.
Lets say, you have 3 containers: httpd, fpm ( wordpress) and java ( tomcat ). You configure httpd, to redirect to fpm:9000 if its domain.tld/php and redirect to java:8086 if the request is domain.tld/Application1.
All you need to understand is, that the actual service-name you have in docker-compose is available as a hostname in the container ( all containers ) - so containers can reach themselfs using the service-name of the other container - that makes inter-container communication very easy and pre-configureable, without knowing the actual container IPs ( which will change during development / production and host migrations )
I think I figured it out: I should have been using a proxy instead of a RewriteRule.
This seems to get me what I want:
ProxyPass "/Application1" "http://my-tomcat-server:8080/Application1"
ProxyPassReverse "/Application1" "http://my-tomcat-server:8080/Application1"

Apache Reverse Proxy to multiple applications, obscuring context roots

Hokay… so…
I have a series of applications which are deployed to a single Tomcat application server. Let's call them appOne, appTwo and appFoo.
I am fronting these applications with an Apache reverse-proxy listening for appOne.mysite.com, appTwo.mysite.com and appFoo.mysite.com, and it effectively sends traffic where it needs to go using a pattern similar to the following:
<VirtualHost appOne.mysite.com:443>
[ ... ]
ProxyPass / http://serverOne.mysite.com:8080/appOne/
ProxyPass Reverse / http://serverOne.mysite.com:8080/appOne/
[ ... ]
</VirtualHost>
Because of how Tomcat works, each application is granted its own application context on serverOne.mysite.com:8080.
However, I don't want the user's to know they're hitting appOne, vs appFoo, so I want to hide it from the URL pattern reported by the browser.
Thus, a request for appOne.mysite.com should appear as appOne.mysite.com and not appOne.mysite.com/appOne/.
REJECTIONS
It's tempting to just rename the war file for an application to ROOT.war and deploy it because it automagically gets the root context. But in this case, each application should appear to be its own root context (isn't that part of why we use reverse-proxy configurations?).
It's also tempting to suggest that I turn off autoDeploy with Tomcat and provide custom context.xml files for each application… but that doesn't solve the issue of applications fighting over the root context designation and ends up being similar to renaming the war file just to get the context root.
It's also also tempting (see what I did there?) to suggest that I install multiple versions of Tomcat listening on unique ports… but this gets into complications with asking my organization to open firewall requests for different ports and I anticipate more and more of these applications popping up and sharing this Tomcat instance. (YAY for single threaded single points of failure!)
WHAT ABOUT…?
I have also considered that there could be programmatic methods I can recommend to the developers to make this more seamless, but I'm not as strong with Java DEV as I am with supporting it's infrastructure. I am open to suggestions here.
It's Possible…
It's entirely possible the answer is glaring me in the face and I don't see it because I've been staring at the problem for too long, or coming at it from the wrong angle.

Integrating liferay tomcat with apache web server

I am trying to integrate the liferay tomcat with apache web server.I successfully integrate the liferay with web server.
Condition:
Life ray deployed on ip say : 10.10.10.70
Apache web server on ip say: 10.10.10.80
I provided all the requirement virtual host requirement in httpd.conf file..and provided the web.server.host in portal-ext.properties file.
Problem: When i run liferay portal i can open it on ip: 10.10.10.70
but when i click on any page link (let say /home)that is present in my portal it moved the request to
10.10.10.80:8080/home instead of 10.10.10.70:8080/home
I want to know how to handle this condition.
Because i dont have any page resource on web server doc folder only contain static css..
You might be a bit more precise what "all the required virtual host settings" are, e.g. what did you configure?
Note that by explicitly configuring hostnames/IP-addresses, you're explicitly overriding the autodetected settings from the request - no matter how you get to your portal, Liferay will generate URLs based on the explicitly configured hostname/port.
What's the point in having an Apache in front and then trying to reach tomcat through the non-apache IP/Port? Typically you might have static resources, rewrites, caches on Apache, so that you'll get different results when you alternatively access tomcat through both URLs.
If you configure Apache to "properly" handle the requests before tomcat sees them, you'll typically not need to configure Liferay at all, because Apache will make the actual hostname that it's requested under available to Tomcat. I'm typically using mod_jk for this and it beautifully handles all the configuration with almost no need to explicitly configure tomcat/liferay. If you don't like this, keep in mind that you're explicitly configuring Liferay for the virtual host setup - naturally this explicitly configured name is what Liferay uses. It would be weird if the explicit value would not be used, right?

What configuration should be specified to bring different servers in same URL space in CloudBees PaaS

I am trying to use CloudBees PaaS (RUN#CloudBees) to consolidate essentially three different distinct uses under the same URL space:
root (/) main landing, marketing page
app (/app) java app running in CloudBees
blog (/blog) another java app running in cloudbees or possibly outside (example.wordpress.com)
If I was doing it myself in a datacenter or in AWS I would setup a reverse proxy (possibly like Varnish and configure reverse proxy to map the URL space as follows:
root (/): www.example.com/ --> CMS running as cloudbees app example-cms.cloudbees.net
app (/app) java app running in CloudBees www.example.com/app -> app.example.com
blog (/blog) similarly www.example.com/blog -> example.wordpress.com or exampleblog.cloudbees.net
How can I achieve the same with CloudBees. Can it be done? Is this too much to expect from a PaaS vendor?
An interesting problem, and a few solutions:
Use domains instead of paths (eg blog.example.com etc) - so you can use DNS to direct things
Build an app that essentially proxies traffic for you (this could run on cloudbees or elsewhere) - there are lots of ways to do this.
Use some routing/proxy service (like CloudFlare) which may let you set up routing rules (so it can proxy traffic).
My preference would always be for number 1 - DNS is a great way to do things like this.
You can with this approach have /blog similar Urls in your paas application, and have it do a 302 redirect to the real blog.example.com - that kind of gives you a bit of both.

How can I test a comet ajax site on a single host and work around browser simultaneous connection limit?

I am using the comet long-polling technique with apache, php, jquery.
I've got a basic comet update running and it works great. I'm now attempting to build a more complex comet script, and I want a better way to debug.
My comet scripts use $.ajax() with a long timeout, and the server side just sleeps until it either runs up to the timeout or has an event to send to the client. The comet requests go to a different subdomain than the main ajax requests.
For normal pages I edit and test on a linux laptop. I've got apache, mysql, and php with a test database and mirror image of the site. I can edit, save, and see the changes with no upload step. For the comet stuff I've been having to upload to a server to test. This requires me to set up a few fake servers, but mostly it requires me to upload changed files for each test. I've got a mostly automatic upload script, but it's still too slow.
The problem testing locally is the long timeout. The browser won't open another connection to the same server while the comet request is still open. I don't have a subdomain locally so I have all the requests going to the same server so they basically block each other.
I've tried a number of things to make this work and none really do it. I tried first to change my browser setting for number of simultaneous connections. This didn't work in firefox on linux, and I didn't find anything about changing this limit on other browsers.
I tried setting my hosts file to give me two names that map to my ip address. Then I tried configuring VirtualHost conf directives in apache, but that didn't work. I think because apache is looking for an actual dns server to tell it the hostname, not just my /etc/hosts file. Maybe I can run a local dns server to fool apache into thinking my box has two names, but that just seems like a real long way around this problem.
So, does anyone have an idea of how to make this work on one ip address/host?
I'm new to the comet thing, so maybe I've just got the wrong idea about something. Maybe this isn't even possible. Either way, it's time to just ask if this is already a solved problem.
It really should be possible to use /etc/hosts to fool Apache. It certainly does work on Ubuntu Hardy with Apache 2.2.
Try to give different hostname to you local address. Simply add a line like this to /etc/hosts:
127.0.0.1 a.example.com b.example.com c.example.com d.example.com
(Note: use a tab after IP)
Validate this with a ping
ping a.example.com
In you apache configuration, you may use a wildcard alias together with a named virtual host:
<VirtualHost *:80>
ServerName example.com
ServerAlias *.example.com
## snip ##
<VirtualHost>
Instead of using example.com, you might want to use something that's under your control. I use local subdomain of our company's domain (i.e. something.local.molindo.at).
Now you can use different subdomains for your test, each with its own limitation on concurrent connections.
You may need to restart your browser to get this working.
I have made something similar and my hosting gives my max queries limit reached which actually should not happen. But I have read that if my php code is in infinite loop.. ie the sleep mode the hosting detects it and makes db connection user as to be using more queries than allowed. That is alot to presume but I have found a solution to that with same speculations.