SV: CLUSTERING PROBLEM FINALLY SOLVED!! <web-module><previous>
The application-creation-howto document was intended to show how to deploy a
full application to Orion, not how to tie a web-application to the default
application. This have been mentioned on this list numerous times, together
with responses on how to do this.
<previous/>
The only things the documentation mentions is that clustering is done on a
per-web-site basis, not on an application basis. It never mentions that the
app has to be tied to the default-web-app
<previous>
The application-creation-howto.html will be updated with either a section
about how to tie a web-application to the default application, or will be
given a link to this information.
<previous/>
So what you're saying is that adding a web-module tag in
config/application.xml is the same thing as tying a web application to the
default web application?
If so, then like I said, the docs *never* mention you have to do this. The
reason why we didn't use previously posted information on the list which
explains how to do this is because we had no idea this was a requirement.
<previous>
Im still a bit bewildered about the fact that you have to tie your
web-application to the default application in order for the clustering to
work. It doesnt make sence to me. Hopefully someone can shed some light on
this.
<previous/>
All I can say is 'try it'. :) Here is a copy of two previous emails I've
sent to the list on how we went about setting up clustering as well as
information on the results of these tries. The first repost explains how we
initially configured orion to cluster. The second repost explains how we
analyzed the cluster debugging information.
Like I said in previous emails: following the cluetering-how-to enabled
clustering for the default-web-app ONLY. You need the web-module tag to
enable it for any other applications and this is NOT covered in the
clustering-how-to or any other doc I've read.
------------------------
REPOST 1
------------------------
STEPS TAKEN TO ENABLE CLUSTERING
--------------------------------
(NOTE: All of these steps were taken for both servers)
1) We tested our web app individually on our two test servers and they ran
correctly. We also added the <distributable /> tag to their web.xml files.
2) We added the <cluster-config/> tag to
orion/application-deployments/default/defaultWebApp/orion-web.xml.
According to the docs: "If you want to add clustering for the whole website
(for all web-applications), edit the orion-web.xml of the default
web-application...". We are using orion 1.4.5, so according to the docs ALL
of the web applications defined in default-web-site.xml should be clustered.
3)We added the cluster-island="1" to the default-web-site.xml file in the
<web-site> tag. Note that all the applications we are testing are defined
in the default-web-site.xml, ie:
<web-site host="ivan.eldan.com" port="8080" cluster-island="1"
display-name="Default
Orion WebSite">
<frontend host="groovy.eldan.com" port="80" />
<default-web-app application="default" name="defaultWebApp" />
<web-app application="TestApp" name="TestApp-web" root="/TestApp" />
<web-app application="Test2" name="Test2-web" root="/Test2" />
Note that we also changed the 'host' attribute in the web-site tag from
[ALL] to our actual hostname.
4) As you can see from step 3) we added the frontend-host tag with the
location of the loadbalancer to the body of the <web-site> tag in
default-web-site.xml
5,6) We started the load balancer on our server named "groovy" then started
our other two servers. The lodablancer successfully noticed our other two
servers and added them to cluster island 1.
7) Lastly we tested the session replication using the
servlets/SessionServlet servlet. We modified the SessionServlet servlet,
adding one line that posts the ip of the server its being run from.
We then re-compiled the session servlet and to be safe, stopped the
loadbalnce, stopped both orion servers, restarted the load-balancer and both
servers (again, the load balancer found both servers).
We then ran SessionServlet and found the ip was from server2, we refreshed
the page until the counter went up to 5. We then shut down server2 and
refreshed again, and lo-and-behold the counter went up to 6! Yeah! We
thought we were done with clustering.
The Problem
We then copied the code for SessionServlet into a JSP called session.jsp.
We put the jsp in the TestApp-Web directory and tried the same test. THIS
time the counter went back to 1 when we ran it. This boggled us. We then
copied session.jsp into the directory orion/default-web-app and tried it.
IT WORKED!! We did not change a line of code.
This is an exact recreation of our problem with orion session replication.
We followed the docs exactly. If you have gotten clustering to work
properly, we would appreciate greatly if you could share your knowledge with
us. We are at an impasse and cannot figure out what to try next.
Just for completeness, here is our server.xml file, perhaps we are missing a
setting in this file(?)
...
<application-server
application-directory="../applications"
deployment-directory="../application-deployments"
>
<rmi-config path="./rmi.xml" />
<principals path="./principals.xml" />
<log>
<file path="../log/server.log" />
</log>
<global-application name="default" path="application.xml" />
<global-web-app-config path="global-web-application.xml" />
<web-site path="./default-web-site.xml" />
<application name="Test2" path="../applications/Test2/" auto-start="true"
/>
<application name="TestApp" path="../applications/TestApp/"
auto-start="true" />
...
---------------------
---------------------
REPOST 2
---------------------
The last thing we did was set orion's cluster debugging information on. ie:
java -jar -Dhttp.cluster.debug=true -Dcluster.debug=true orion.jar
One thing we saw was that when we ran the default-web-app servlet named
SessionServlet, the other servers in the cluster (ie: all servers not
including the one the app was running on) and they printed the following
messages to the console:
Recived cluster-message: defaultWebApp
Recieving HTTP-cluster session value update
However, when we ran any application other than the default-web-app and
changed session variables, they only printed the following message:
Recieved cluster-message: testapp-web
The "Recieving HTTP-cluster session value update" message is missing. We
checked the server the app was running on and saw the following message:
Sending HTTP-cluster session value update for session PENLFAJMHCKLPrtDc_Q-B:
count=3...
What this means is that the server serving the application is sending the
HTTP session updates but the other servers aren't getting the message. We
thought it may be a problem with how we named our servers (ie: in
default-web-site.xml: the value we set for host in the frontend tag and the
value host tag in the web-site tag). We tried using the fully qualified
hostnames as well as ip addresses, but neither fared any better than the
other. Also, if the http update messages were getting lost because of
misnamed servers, then how was the default-web-app successfully replicating
*its* session information? It must obviously be finding the other servers
without problem.
Michael N. Christoff
Developer, Eldan Software, Ltd.
Toronto, Canada
www.eldan.com
