Forum Moderators: phranque
I have been puzzled by a complex jetty and apache related problem for quit a long time...
I am now using jetty 6.1.11 as an embedded web container, and I am planning to use an Apache(2.2.2/2.2.10) as front end and jetty as back end (and some other web application not based on jetty will also be used as back ends as well.), apache-jetty is 1-N and apache-other is 1-1. For some reason, I am not going to use the jetty-web.xml to implement the load balance.So I coded my source something like this:
String workerName = getWorkerNameFromConfigFile();
Server server = new Server();
SessionIdManager sessionIdManager = new HashSessionIdManager();
sessionIdManager.setWorkerName(workerName);
server.setSessionIdManager(sessionIdManager);
(In this way, I have already got the JSESSIONID in correct form like JSESSIONID=abcdefghijklmnopqrstuvwxyz.beautifulgirl by both just visiting the back end directly and with the apache mod_proxy_balancer functionality)
and then, I configured httpd.conf in the following way:
<Proxy balancer://my_cluster>
BalancerMember [localhost:31038...] route=goodboy
BalancerMember [localhost:21038...] route=beautifulgirl
</Proxy>
<VirtualHost *:8081>
ServerName localhost
ProxyPass /balancer !
ProxyPass /status !
ProxyPass / balancer://my_cluster/ stickysession=JSESSIONID lbmethod=byrequests nofailover=On
ProxyPassReverse / balancer://my_cluster/
ProxyPreserveHost on
</VirtualHost>
now, when I start the jetty based container and apache, the load balance is implemented, but the session is NOT sticked with the browser.When I request for an html resource which includes some other js or gif files, all requests are proxied to the nodes averagely while what is expected is that all requests should be proxied to one node
Could someone please tell me why the solution goes this way?
Thank you very much!
Best Regards
Tingel Christian T. Sun
Edit/Delete Message
However, in general, the key question here is whether the jsessionID in the HTTP request has any meaning to the load balancer. If not, then it cannot "know" to send the request to the initially-assigned back-end server, and you must find a way to implement this "sticky" functionality.
The proxy through-put function of mod_rewrite may come in handy here, because mod_rewrite can examine HTTP request headers and cookies, and base the selected proxy through-put 'target' on those variables.
Again, I have no experience with your described set-up, so the above response may in fact be useless... :)
Jim
Thank you very much.
I have tried the way you mentioned and it works well when I was using "GET" method really.
But I've got another problem which is that...
I need to match data existing in POSTDATA and now on my way resolving it~~~
Do you have any idea about that?
Thanks!
You can use mod_rewrite's RewriteMap function to call this script during the URL-to-filename translation API phase, so that the content-handler is not invoked until the result is known. The RewriteMap can then supply a new URL-path (for example a proxy-path to your back-end, or an error page).
Once the content-handler phase is invoked, it's too late to redirect or rewrite the request, except by using scripted redirects or "includes." So RewriteMap may be the best solution here.
Jim
Using a self-written apache module (e.g. in c, perl via mod_perl, python via mod_python) to access the request record within the internal request processing would be the smoothest solution.
Actually; internal redirects are called by a content handler and not within a module's hook in ap_process_request_internal.
