Re: clustering
Hello John, no, but there's http://kb.atlassian.com/content/orion/docs/http-clustering.html - it might help you... greetings Rob Friday, February 01, 2002, 5:35:53 PM, you wrote: JC hi, JC I was wondering if anyone out there has any solid information on clustering JC orion server JC thanks -- Robert Virkus scaraboo GmbH mobile Entertainment Georg-Wulf-Str.4-6 28199 Bremen Germany phone +49 - (0)421 - 59 67 549 fax+49 - (0)421 - 59 67 567 mobile +49 - (0)171 - 35 31 635 [EMAIL PROTECTED] www.scaraboo.de wap.scaraboo.de Aus Rechts- und Sicherheitsgruenden ist die in dieser E-Mail gegebene Information nicht rechtsverbindlich. Eine rechtsverbindliche Bestaetigung reichen wir Ihnen gerne auf Anforderung in schriftlicher Form nach. Beachten Sie bitte, dass jede Form der unautorisierten Nutzung, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieser E-Mail nicht gestattet ist. Diese Nachricht ist ausschliesslich fuer den bezeichneten Adressaten oder dessen Vertreter bestimmt. Sollten Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein, so bitten wir Sie, sich mit dem Absender der E-Mail in Verbindung zu setzen. For legal and security reasons the information provided in this e-mail is not legally binding. Upon request we would be pleased to provide you with a legally binding confirmation in written form. Any form of unauthorised use, publication, reproduction, copying or disclosure of the content of this e-mail is not permitted. This message is exclusively for the person addressed or their representative. If you are not the intended recipient of this message and its contents, please notify the sender immediately.
RE: clustering
My experience is that it is broken in 1.5.2 and 1.5.3 under heavy load; see bug number 687 at http://bugzilla.orionserver.com/bugzilla/. I have been working with Magnus Rydin to get the problem resolved but we haven't gotten vary far, hopefully they will find time to fix this problem soon. -Mike _ : mike moulton : meltmedia : : [EMAIL PROTECTED] : www.meltmedia.com : : 602.340.9440 : 602.432.2568 dig : 602.340.1005 fax : : monOrchid studios : 214 e roosevelt st : phoenix, az 85004 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Creaner Sent: Friday, February 01, 2002 9:36 AM To: Orion-Interest Subject: clustering hi, I was wondering if anyone out there has any solid information on clustering orion server thanks
RE: clustering
We have seen this behavior in earlier releases, 1.4.5 and 1.4.7, as well and reported it to Karl and Magnus at JavaONE 2001 (v1.5.2 came out right around then). We found that it always worked fine in low load environments and didn't discover this problem until we pushed clustering to our production servers. We've since been using independant non-clustered servers behind a hardware loadbalancer to distribute load, but we have no failover. I was getting ready to give it another shot soon. I guess I expected the Oracle agreement and having larger installations using Orion would have propelled this issue towards the top of the heap. But it looks like its still not quite ready. -Original Message- From: Mike Moulton [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 2:00 PM To: Orion-Interest Subject: RE: clustering My experience is that it is broken in 1.5.2 and 1.5.3 under heavy load; see bug number 687 at http://bugzilla.orionserver.com/bugzilla/. I have been working with Magnus Rydin to get the problem resolved but we haven't gotten vary far, hopefully they will find time to fix this problem soon. -Mike _ : mike moulton : meltmedia : : [EMAIL PROTECTED] : www.meltmedia.com : : 602.340.9440 : 602.432.2568 dig : 602.340.1005 fax : : monOrchid studios : 214 e roosevelt st : phoenix, az 85004 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Creaner Sent: Friday, February 01, 2002 9:36 AM To: Orion-Interest Subject: clustering hi, I was wondering if anyone out there has any solid information on clustering orion server thanks
Re: Clustering with Hw Load Balaner
So does it mean we need any other layer of load-balancing failover, like at the Web Server farm? - NH - Original Message - From: Patel, Atul [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Saturday, October 13, 2001 9:39 AM Subject: Clustering with Hw Load Balaner Hi all. Is it possible to cluster orion (2 servers with one instance each) without using loadbalancer.jar? I have a hardware loadbalaner which handles the traffic. I thought the primary reason for clustering was to be able to provide continuos support if a server goes down. If loadbalancer.jar is required, isn't the server running loadbalancer.jar a potential failure point? I like orion and so far it seems very stable. Is loadbalancer.jar just as stable? Can it handle traffic in the neighborhood of 1000 concurrent users? This is my first post and I hope the questions are helpful to everyone else as well. Any replies are greatly appreciated.
RE: Clustering in Orion
Will my EJBs be replicated across the cluster? The documentation states the following. The HttpSession data (as long as it is Serializable or an EJB reference). Note that if the EJBs are located on a server that fails, the references might become invalid. The ServletContext data. Please note that the Servlet spec does not say that ServletContext is replicated, so you are relying on a Orion specific feature.
RE: Clustering in Orion
Title: Clustering in Orion As I understand it clustering of session EJBs will soon be available. But thats just the rumor. -Original Message-From: GUNDA, Satish / RSAIFS - IOM [mailto:[EMAIL PROTECTED]]Sent: Friday, August 31, 2001 7:52 AMTo: Orion-InterestSubject: Clustering in Orion Hi all, What is the clustering support provided by Orion? Will my EJBs be replicated across the cluster? The documentation states the following. The HttpSession data (as long as it is Serializable or an EJB reference). Note that if the EJBs are located on a server that fails, the references might become invalid. The ServletContext data. Does it mean EJBs are not replicated acorss a cluster? I don't know how just replication at HTTPSession level can help a production site which requires 99.99 uptime. Any idea when (if) Orion is coming up with this support? Thanks, Satish
RE: Clustering in Orion
Title: Clustering in Orion Really? Could you share the source (of the rumor)? -Original Message-From: Aaron Tavistock [mailto:[EMAIL PROTECTED]]Sent: Viernes, 31 de Agosto de 2001 16:39To: Orion-InterestSubject: RE: Clustering in Orion As I understand it clustering of session EJBs will soon be available. But thats just the rumor. -Original Message-From: GUNDA, Satish / RSAIFS - IOM [mailto:[EMAIL PROTECTED]]Sent: Friday, August 31, 2001 7:52 AMTo: Orion-InterestSubject: Clustering in Orion Hi all, What is the clustering support provided by Orion? Will my EJBs be replicated across the cluster? The documentation states the following. The HttpSession data (as long as it is Serializable or an EJB reference). Note that if the EJBs are located on a server that fails, the references might become invalid. The ServletContext data. Does it mean EJBs are not replicated acorss a cluster? I don't know how just replication at HTTPSession level can help a production site which requires 99.99 uptime. Any idea when (if) Orion is coming up with this support? Thanks, Satish
RE: Clustering in Orion
Title: Clustering in Orion I saw that one too..somewhere in the list archives. -Original Message-From: Juan Lorandi (Chile) [mailto:[EMAIL PROTECTED]]Sent: Friday, August 31, 2001 2:56 PMTo: Orion-InterestSubject: RE: Clustering in Orion Really? Could you share the source (of the rumor)? -Original Message-From: Aaron Tavistock [mailto:[EMAIL PROTECTED]]Sent: Viernes, 31 de Agosto de 2001 16:39To: Orion-InterestSubject: RE: Clustering in Orion As I understand it clustering of session EJBs will soon be available. But thats just the rumor. -Original Message-From: GUNDA, Satish / RSAIFS - IOM [mailto:[EMAIL PROTECTED]]Sent: Friday, August 31, 2001 7:52 AMTo: Orion-InterestSubject: Clustering in Orion Hi all, What is the clustering support provided by Orion? Will my EJBs be replicated across the cluster? The documentation states the following. The HttpSession data (as long as it is Serializable or an EJB reference). Note that if the EJBs are located on a server that fails, the references might become invalid. The ServletContext data. Does it mean EJBs are not replicated acorss a cluster? I don't know how just replication at HTTPSession level can help a production site which requires 99.99 uptime. Any idea when (if) Orion is coming up with this support? Thanks, Satish
Re: clustering problem
i got it to work quite by chance (it figures, 1 week of failure, and 5 mins after i posted i figured it out) and i can offer this piece of advice.. as i stated i followed the howto on orionserver.com, and the only thing i added was the load-on-startup=true attribute in the default-web-site.xml, so i guess this is vital cheers Morten Wilken - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 9:38 PM Subject: RE: clustering problem Morten, post your server.xml, default-web-site.xml, application.xml, web.xml, and orion-web.xml. If you are using the load-balancer.xml, post that too. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Morten Wilken Sent: Thursday, July 19, 2001 3:32 AM To: Orion-Interest Subject: clustering problem hi all i have a problem configuring orion clustering i have downloaded the latest stable release 1.5.2, and followed the howto on the orion site. i have 2 pc running and i have made a web application in the default web site. here i have a simple jsp file a la SessionServlet, that just increments a counter what happends is this: i start the loadbalancer, and then the 2 servers. both registers ok and i load up my jsp one of the server serves the jsp and the counter increments... i do this until it reaches ie 5 and the shut the server down. the other server then takes over, imports the session (or so it says), but the counter is the back to 1... then i increment it to ie 10 and start up the first server and shuts down the second and bing the counter is back to 5 so you may say, multicasting on my lan doesnt work and the state is not sent over the multicast ip. i the wrote a small multicast listener that listens on 230.0.0.1 port 9128, and the state is sent.. so what gives? i might add that when using the debug mode on oion, i can see tht the state is sent Sending HTTP-cluster session value update for session GIOMGHDOHEJAAfaAuASBA: count=7... but i never see a corresponding Recieving blabla... on the other server if anyone knows whats going on here, or can give some pointers please let me know sincirely Morten Wilken
RE: clustering problem
Morten, post your server.xml, default-web-site.xml, application.xml, web.xml, and orion-web.xml. If you are using the load-balancer.xml, post that too. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Morten Wilken Sent: Thursday, July 19, 2001 3:32 AM To: Orion-Interest Subject: clustering problem hi all i have a problem configuring orion clustering i have downloaded the latest stable release 1.5.2, and followed the howto on the orion site. i have 2 pc running and i have made a web application in the default web site. here i have a simple jsp file a la SessionServlet, that just increments a counter what happends is this: i start the loadbalancer, and then the 2 servers. both registers ok and i load up my jsp one of the server serves the jsp and the counter increments... i do this until it reaches ie 5 and the shut the server down. the other server then takes over, imports the session (or so it says), but the counter is the back to 1... then i increment it to ie 10 and start up the first server and shuts down the second and bing the counter is back to 5 so you may say, multicasting on my lan doesnt work and the state is not sent over the multicast ip. i the wrote a small multicast listener that listens on 230.0.0.1 port 9128, and the state is sent.. so what gives? i might add that when using the debug mode on oion, i can see tht the state is sent Sending HTTP-cluster session value update for session GIOMGHDOHEJAAfaAuASBA: count=7... but i never see a corresponding Recieving blabla... on the other server if anyone knows whats going on here, or can give some pointers please let me know sincirely Morten Wilken
RE: Clustering..
When you use a SSL hardware accelerator, are you able to retrieve the digital certificate that the user uses from your application on Orion?. Is there a way to retrieve the digital certificate while usin a SSL hardware accelerator? At 14:11 16/07/2001 -0700, you wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Monday, July 16, 2001 1:35 PM To: Orion-Interest Subject: RE: Clustering.. Thanks for the reply. 1. clustering only handles http session data. sfsb's will not be replicated. I thought that the entire application context was replicated? So anything set to Application scope (beans, etc) is NOT replicated? Is that the way it is supposed to be..or just a bug/enhancement for Orion team to work on? ew I believe only the session context is replicated, but you will notice that if you don't have a Serializable object, the server will throw an error. I don't think the application context is replicated...since each server has its own application context. If you fall over to another server, you get that servers application context...otherwise all of the other applications would have problems. This shouldn't be a problem, since usually the app context is the same on each server in a cluster. 2. Although rmi can be clustered and you can get fail-over for ejb's, the ejb's are not load-balanced. Not sure if I understand..I thought load balancing was done via a hardware load balancer? In other words, wouldn't you have a setup like a firewall that feeds to a load-balancer that then feeds to one (or more) islands, each having one (or more) servers running EJB? The front-end cluster would access this single fire-wall IP (via JNDI when looking up EJBs), which would follow the flow to the ejb cluster. When you are talking about clustering EJB's (load balancing them), how have you done this, or how is it normally done? Again..i would think the identical hardware to load-balance the front-end cluster would be in place for the EJB tier..including a firewall since EJB's may be directly accessed via WAN clients, or from Web Services? ew you can use hardware or the software loadbalancer. The ejb's have nothing to do with the http loadbalancing. That the ejb's happen to be on the same servers is not actually garanteed unless you plan it that way. You can use remote ejb's from other servers on other machines. I mean, that's the whole point of ejb's. One ejb pseudo loadbalancing technique is to set the maximum number of beans on any one server, and then cluster the rmi. As one server fills up, another server will kick-in to server ejb's. This isn't really loadbalancing, though, but it is fail-over. 3. careful specification of the server is required, for example, the web-apps must be in the config/application.xml. This is new to me. I haven't read any recent clustering docs, but the original clustering doc (not even sure if Orion ever posted it, or if it is on orionsupport.com or not) had specific settings in web.xml (setting the clusterable option), and I think in orion-web.xml and the .xml config file under /orion/config for the specific application to be clustered. Has this all changed? ew if an application is not bound to the default application, you will need a separate web-app tag in the config/application.xml file to make sure the session data is clustered. The docs only cover clustering and loadbalancing the default web site and anything bound to this app. Of course you can have more than one web-app which is not bound to the default web site, but another web-site. 4. ssl loadbalancing does not work and is broken. I just mentioned this to our CTO. I think using a hardware SSL device (whether as a separate linux box that handles the encoding/decoding, web server that forwards all SSL on after encoding/decoding, or a stand-alone hardware box that does this very fast (my personal favorite)) should take care of this. For the mere $5K you pay for a box that can handle several hundred SSL transactions per second, I think its worth the peace of mind it gives you in not having to do any SSL coding tricks. I remember reading something about how SSL sessions were getting lost. Don't recall what this was about..but it makes me worry about moving to Orion (or OC4J) if SSL doesn't fully work. ew proxy or hardware for the ssl acceleration is the way to go. Sonicwall even has a hardware accelerator that looks like a network interface to your server for $2500. SSL works fine on the server, its just the software loadbalancer that doesn't work with ssl. Maybe I am missing something..but I would think a good part of the appeal to move to an App Server is for its clustering capabilities. Sure, you get awesome web performance, simple setup and powerful features for a single server/app server setup. But if your site grows, you are bound to require clustering..aren't you? Or does everyone just add a new box and load-balance via session
RE: Clustering..
AFAIK, these accelerators handle the front end, and the backend doesn't use ssl. You can also have ssl throughout, but ...I mean, what's the point of having the accelerator if you don't use it. You may be able to tunnel through the accelerator or proxy, or something. I will check out the docs to see if you can proxy the certificate. This is certainly necessary for login credentials if you use a client certificate for a login. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ismael Sent: Wednesday, July 18, 2001 12:37 AM To: Orion-Interest Subject: RE: Clustering.. When you use a SSL hardware accelerator, are you able to retrieve the digital certificate that the user uses from your application on Orion?. Is there a way to retrieve the digital certificate while usin a SSL hardware accelerator? At 14:11 16/07/2001 -0700, you wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Monday, July 16, 2001 1:35 PM To: Orion-Interest Subject: RE: Clustering.. Thanks for the reply. 1. clustering only handles http session data. sfsb's will not be replicated. I thought that the entire application context was replicated? So anything set to Application scope (beans, etc) is NOT replicated? Is that the way it is supposed to be..or just a bug/enhancement for Orion team to work on? ew I believe only the session context is replicated, but you will notice that if you don't have a Serializable object, the server will throw an error. I don't think the application context is replicated...since each server has its own application context. If you fall over to another server, you get that servers application context...otherwise all of the other applications would have problems. This shouldn't be a problem, since usually the app context is the same on each server in a cluster. 2. Although rmi can be clustered and you can get fail-over for ejb's, the ejb's are not load-balanced. Not sure if I understand..I thought load balancing was done via a hardware load balancer? In other words, wouldn't you have a setup like a firewall that feeds to a load-balancer that then feeds to one (or more) islands, each having one (or more) servers running EJB? The front-end cluster would access this single fire-wall IP (via JNDI when looking up EJBs), which would follow the flow to the ejb cluster. When you are talking about clustering EJB's (load balancing them), how have you done this, or how is it normally done? Again..i would think the identical hardware to load-balance the front-end cluster would be in place for the EJB tier..including a firewall since EJB's may be directly accessed via WAN clients, or from Web Services? ew you can use hardware or the software loadbalancer. The ejb's have nothing to do with the http loadbalancing. That the ejb's happen to be on the same servers is not actually garanteed unless you plan it that way. You can use remote ejb's from other servers on other machines. I mean, that's the whole point of ejb's. One ejb pseudo loadbalancing technique is to set the maximum number of beans on any one server, and then cluster the rmi. As one server fills up, another server will kick-in to server ejb's. This isn't really loadbalancing, though, but it is fail-over. 3. careful specification of the server is required, for example, the web-apps must be in the config/application.xml. This is new to me. I haven't read any recent clustering docs, but the original clustering doc (not even sure if Orion ever posted it, or if it is on orionsupport.com or not) had specific settings in web.xml (setting the clusterable option), and I think in orion-web.xml and the .xml config file under /orion/config for the specific application to be clustered. Has this all changed? ew if an application is not bound to the default application, you will need a separate web-app tag in the config/application.xml file to make sure the session data is clustered. The docs only cover clustering and loadbalancing the default web site and anything bound to this app. Of course you can have more than one web-app which is not bound to the default web site, but another web-site. 4. ssl loadbalancing does not work and is broken. I just mentioned this to our CTO. I think using a hardware SSL device (whether as a separate linux box that handles the encoding/decoding, web server that forwards all SSL on after encoding/decoding, or a stand-alone hardware box that does this very fast (my personal favorite)) should take care of this. For the mere $5K you pay for a box that can handle several hundred SSL transactions per second, I think its worth the peace of mind it gives you in not having to do any SSL coding tricks. I remember reading something about how SSL sessions were getting lost. Don't recall what this was about..but it makes me worry about moving to Orion (or OC4J) if SSL doesn't fully work
RE: Clustering..
Title: RE: Clustering..
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kesav
KumarSent: Tuesday, July 17, 2001 12:32 AMTo:
Orion-InterestSubject: RE: Clustering..
snip
This mechanism have one
drawback: If you keep an object in session and later some place you get
the reference of the object and modify the object the modifications won't get
reflect across islands:
Example:
UserInfo info = new UserInfo() // Some kind of
object... info.user_name = "oldName";
session.setAttribute("UserInfo", info) // At this point the info is
replicated to all cluster islands
//Later at any place of your code
UserInfo info =
session.getAttribute("UserInfo");
info.user_name =
"newName"; //This change won't replicated
//In some other program
UserInfo info =
session.getAttribute("UserInfo");
System.out.println(info.user_name) // If the request comes to the
same cluster where the modification occures you will get the "NewName" if the
request goes to another cluster you will get "oldname"
Work Around: If you do any kind of modifications to your
session objects put the objects again into session using
setSessionAttribute. Keep one thing in mind that when ever you call this
setSessionAttribute method the session info is going to replicate across
different islands.
MSI've noticed this too, is this according to
the jsp/servlet specifications or just container specific? When you are using
JSP's it is very awkward having to call setAttribute() after every
jsp:setProperty name="myObject" property="*" / or
similar.
This is the same problem which I faced and lead me to write my
own session management.
Kesav Kumar Kolla Voquette Inc
650 356 3740(W) 510 889 6840(R)
Voquette...Delivering Sound Information
-Original Message- From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Duffey, Kevin Sent: Monday, July 16, 2001
12:39 PM To: Orion-Interest Subject: Clustering..
Hi all,
I know how to cluster Orion..after all, its pretty easy. What I
want to know from someone who knows..is if in the 1.5.2
version all the bugs (if there were actually any) are
worked out. Does Orion cluster with no problems? Does session fail-over and application context fail-over work without a
hitch (providing all objects in the session and/or
context are serializable)? If you have two machines in
an island, and the session begins on one..does it automatically "copy" any session info to the other box for you? If you
shut that box off, and all requests go to the 2nd box,
does the session still exist with all objects still in
memory?
I take it each and every request on a clustered box requires the
session to be duplicated exactly as is to the other
machine? If this is the case, at what "rate" does Orion
copy out the session and anything else to another server
in the island (or to each and every server in the island)? How does
this affect performance as compared to using just a single box
without clustering..is it 2 to 3 times slower because of
not only copying its session to one or more boxes, but
also having to deal with "merging" other boxes
context/session information into its own? Or does a cluster simply
create the objects and session stuff on each box as its
generated (thus..its not some background thread that
copies session info when it has time to other
boxes)?
Is it equally good at clustering on the EJB tier (so scalability
on the EJB tier or the front-end WEB tier is equally as
easy)?
Thanks.
RE: Clustering..
Title: RE: Clustering..
I
haven't check with the latest version, but I store a handle to a sfsb.
When I failover it is invalid on the other server. Is this a
bug?
-Paul
-Original Message-From: Kesav Kumar
[mailto:[EMAIL PROTECTED]]Sent: Monday, July 16, 2001 3:32
PMTo: Orion-InterestSubject: RE:
Clustering..
Clustering in orion is only for sessions. EJB clustering
is not yet provided.
The clustering mechanism in orion is based on
JMS(Topic/Subscriber). When every you keep information in session by
using setSessionAttribute(String name, Object object) the session information
is copied to all other clusters.
All objects in the seesion must be serializable inorder to
provide clustering. Once clustering is enabled if switch requests
between islands you will have session information valid.
Unfortuantely this mechanism is little expensive in terms of
memory since session information is kept in memory of all islands. So
adding one more machine or island into the cluster group doesn't reduce your
memory requirements rather it increase your memory requirements.
This mechanism have one drawback: If you keep an object
in session and later some place you get the reference of the object and modify
the object the modifications won't get reflect across islands:
Example:
UserInfo info = new UserInfo() // Some kind of
object... info.user_name = "oldName";
session.setAttribute("UserInfo", info) // At this point the info is
replicated to all cluster islands
//Later at any place of your code
UserInfo info =
session.getAttribute("UserInfo");
info.user_name =
"newName"; //This change won't replicated
//In some other program
UserInfo info =
session.getAttribute("UserInfo");
System.out.println(info.user_name) // If the request comes to the
same cluster where the modification occures you will get the "NewName" if the
request goes to another cluster you will get "oldname"
Work Around: If you do any kind of modifications to your
session objects put the objects again into session using
setSessionAttribute. Keep one thing in mind that when ever you call this
setSessionAttribute method the session info is going to replicate across
different islands.
I think this is too much to put down. If some one finds
boaring just ignore this mail.
This is the same problem which I faced and lead me to write my
own session management.
Kesav Kumar Kolla Voquette Inc
650 356 3740(W) 510 889
6840(R) Voquette...Delivering Sound Information
-Original Message- From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Duffey, Kevin Sent: Monday, July 16, 2001
12:39 PM To: Orion-Interest Subject: Clustering..
Hi all,
I know how to cluster Orion..after all, its pretty easy. What
I want to know from someone who knows..is if in the
1.5.2 version all the bugs (if there were actually
any) are worked out. Does Orion cluster with no problems? Does
session fail-over and application context fail-over work
without a hitch (providing all objects in the session
and/or context are serializable)? If you have two
machines in an island, and the session begins on one..does it automatically "copy" any session info to the other box for you? If you
shut that box off, and all requests go to the 2nd box,
does the session still exist with all objects still in
memory?
I take it each and every request on a clustered box requires
the session to be duplicated exactly as is to the
other machine? If this is the case, at what "rate"
does Orion copy out the session and anything else to another server in the island (or to each and every server in the island)? How
does this affect performance as compared to using just
a single box without clustering..is it 2 to 3 times
slower because of not only copying its session to one
or more boxes, but also having to deal with "merging" other boxes context/session information into its own? Or does a cluster
simply create the objects and session stuff on each
box as its generated (thus..its not some background
thread that copies session info when it has time to other boxes)?
Is it equally good at clustering on the EJB tier (so
scalability on the EJB tier or the front-end WEB tier
is equally as easy)?
Thanks.
RE: Clustering..
Title: RE: Clustering..
Paul,
only
http session data is shared in the cluster. For example, the Petstore
application doesn't cluster very well because its statemachine isin a
sfsb. The work around is to use a slsb, and pass a serializable bean from the
session context with the each slsb method.
of
course, the sfsb could also be on a remote server, so this wouldn't be a
problem since the sfsb reference would still be valid.
Regards,
the
elephantwalker
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Paul
KnepperSent: Tuesday, July 17, 2001 7:18 AMTo:
Orion-InterestSubject: RE: Clustering..
I
haven't check with the latest version, but I store a handle to a sfsb.
When I failover it is invalid on the other server. Is this a
bug?
-Paul
-Original Message-From: Kesav Kumar
[mailto:[EMAIL PROTECTED]]Sent: Monday, July 16, 2001 3:32
PMTo: Orion-InterestSubject: RE:
Clustering..
Clustering in orion is only for sessions. EJB
clustering is not yet provided.
The clustering mechanism in orion is based on
JMS(Topic/Subscriber). When every you keep information in session by
using setSessionAttribute(String name, Object object) the session
information is copied to all other clusters.
All objects in the seesion must be serializable inorder to
provide clustering. Once clustering is enabled if switch requests
between islands you will have session information valid.
Unfortuantely this mechanism is little expensive in terms of
memory since session information is kept in memory of all islands. So
adding one more machine or island into the cluster group doesn't reduce your
memory requirements rather it increase your memory requirements.
This mechanism have one drawback: If you keep an
object in session and later some place you get the reference of the object
and modify the object the modifications won't get reflect across
islands:
Example:
UserInfo info =
new UserInfo() // Some kind of object...
info.user_name =
"oldName"; session.setAttribute("UserInfo", info) // At this point the info is
replicated to all cluster islands
//Later at any place of your code
UserInfo info =
session.getAttribute("UserInfo");
info.user_name =
"newName"; //This change won't replicated
//In some other program
UserInfo info =
session.getAttribute("UserInfo");
System.out.println(info.user_name) // If the request comes to
the same cluster where the modification occures you will get the "NewName"
if the request goes to another cluster you will get "oldname"
Work Around: If you do any kind of modifications to
your session objects put the objects again into session using
setSessionAttribute. Keep one thing in mind that when ever you call
this setSessionAttribute method the session info is going to replicate
across different islands.
I think this is too much to put down. If some one
finds boaring just ignore this mail.
This is the same problem which I faced and lead me to write
my own session management.
Kesav Kumar Kolla Voquette
Inc 650 356 3740(W) 510 889
6840(R) Voquette...Delivering Sound
Information
-Original Message- From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Duffey, Kevin Sent: Monday, July 16, 2001
12:39 PM To: Orion-Interest Subject: Clustering..
Hi all,
I know how to cluster Orion..after all, its pretty easy.
What I want to know from someone who knows..is if in
the 1.5.2 version all the bugs (if there were
actually any) are worked out. Does Orion cluster with no problems?
Does session fail-over and application context
fail-over work without a hitch (providing all
objects in the session and/or context are serializable)? If you have two machines in an island, and the session begins on
one..does it automatically "copy" any session info
to the other box for you? If you shut that box off,
and all requests go to the 2nd box, does the session still exist with all objects still in memory?
I take it each and every request on a clustered box requires
the session to be duplicated exactly as is to the
other machine? If this is the case, at what "rate"
does Orion copy out the session and anything else to another
server in the island (or to each and every server in the
island)? How does this affect performance as
compared to using just a single box without clustering..is it 2 to 3 times slower because of not only copying
its session to one or more boxes, but also having to
deal with "merging" other boxes context/session
information into its own? Or does a clust
Re: Clustering..
Title: RE: Clustering..
good point, but i wouldn't see this as a drawback
-- it's just how it works.
isn't that sort of like saying, if i retrieve a
value from the database, and change it on the client, then the database isn't
automatically updated?
- Original Message -
From:
Marcel Schutte
To: Orion-Interest
Sent: Tuesday, July 17, 2001 6:01
PM
Subject: RE: Clustering..
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kesav
KumarSent: Tuesday, July 17, 2001 12:32 AMTo:
Orion-InterestSubject: RE: Clustering..
snip
This mechanism have one
drawback: If you keep an object in session and later some place you get
the reference of the object and modify the object the modifications won't get
reflect across islands:
Example:
UserInfo info = new UserInfo() // Some kind of
object... info.user_name = "oldName";
session.setAttribute("UserInfo", info) // At this point the info is
replicated to all cluster islands
//Later at any place of your code
UserInfo info =
session.getAttribute("UserInfo");
info.user_name =
"newName"; //This change won't replicated
//In some other program
UserInfo info =
session.getAttribute("UserInfo");
System.out.println(info.user_name) // If the request comes to the
same cluster where the modification occures you will get the "NewName" if the
request goes to another cluster you will get "oldname"
Work Around: If you do any kind of modifications to your
session objects put the objects again into session using
setSessionAttribute. Keep one thing in mind that when ever you call this
setSessionAttribute method the session info is going to replicate across
different islands.
MSI've noticed this too, is this according to
the jsp/servlet specifications or just container specific? When you are using
JSP's it is very awkward having to call setAttribute() after every
jsp:setProperty name="myObject" property="*" / or
similar.
This is the same problem which I faced and lead me to write my
own session management.
Kesav Kumar Kolla Voquette Inc
650 356 3740(W) 510 889
6840(R) Voquette...Delivering Sound Information
-Original Message- From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Duffey, Kevin Sent: Monday, July 16, 2001
12:39 PM To: Orion-Interest Subject: Clustering..
Hi all,
I know how to cluster Orion..after all, its pretty easy. What
I want to know from someone who knows..is if in the
1.5.2 version all the bugs (if there were actually
any) are worked out. Does Orion cluster with no problems? Does
session fail-over and application context fail-over work
without a hitch (providing all objects in the session
and/or context are serializable)? If you have two
machines in an island, and the session begins on one..does it automatically "copy" any session info to the other box for you? If you
shut that box off, and all requests go to the 2nd box,
does the session still exist with all objects still in
memory?
I take it each and every request on a clustered box requires
the session to be duplicated exactly as is to the
other machine? If this is the case, at what "rate"
does Orion copy out the session and anything else to another server in the island (or to each and every server in the island)? How
does this affect performance as compared to using just
a single box without clustering..is it 2 to 3 times
slower because of not only copying its session to one
or more boxes, but also having to deal with "merging" other boxes context/session information into its own? Or does a cluster
simply create the objects and session stuff on each
box as its generated (thus..its not some background
thread that copies session info when it has time to other boxes)?
Is it equally good at clustering on the EJB tier (so
scalability on the EJB tier or the front-end WEB tier
is equally as easy)?
Thanks.
RE: Clustering..
Title: RE: Clustering..
The
database senario and session senarios are different. If we are keeping
information session thinking that this will be replicated across all the
clusters. The current JSP jsp:setProperty tag doesn't give any
extra attribute to actually say do clustering also. Either the JSP has to
provide or the session replication mechanism should facilitate
this.
Kesav Kumar Kolla Voquette Inc 650 356 3740(W)
510 889 6840(R) Voquette...Delivering Sound Information
-Original Message-From: Greg Matthews
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 17, 2001 4:49
PMTo: Orion-InterestSubject: Re:
Clustering..
good point, but i wouldn't see this as a drawback
-- it's just how it works.
isn't that sort of like saying, if i retrieve a
value from the database, and change it on the client, then the database isn't
automatically updated?
- Original Message -
From:
Marcel Schutte
To: Orion-Interest
Sent: Tuesday, July 17, 2001 6:01
PM
Subject: RE: Clustering..
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kesav
KumarSent: Tuesday, July 17, 2001 12:32 AMTo:
Orion-InterestSubject: RE: Clustering..
snip
This mechanism have one
drawback: If you keep an object in session and later some place you
get the reference of the object and modify the object the modifications
won't get reflect across islands:
Example:
UserInfo info =
new UserInfo() // Some kind of object...
info.user_name =
"oldName"; session.setAttribute("UserInfo", info) // At this point the info is
replicated to all cluster islands
//Later at any place of your code
UserInfo info =
session.getAttribute("UserInfo");
info.user_name =
"newName"; //This change won't replicated
//In some other program
UserInfo info =
session.getAttribute("UserInfo");
System.out.println(info.user_name) // If the request comes to
the same cluster where the modification occures you will get the "NewName"
if the request goes to another cluster you will get "oldname"
Work Around: If you do any kind of modifications to
your session objects put the objects again into session using
setSessionAttribute. Keep one thing in mind that when ever you call
this setSessionAttribute method the session info is going to replicate
across different islands.
MSI've noticed this too, is this according
to the jsp/servlet specifications or just container specific? When you are
using JSP's it is very awkward having to call setAttribute() after every
jsp:setProperty name="myObject" property="*" / or
similar.
This is the same problem which I faced and lead me to write
my own session management.
Kesav Kumar Kolla Voquette
Inc 650 356 3740(W) 510 889
6840(R) Voquette...Delivering Sound
Information
-Original Message- From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Duffey, Kevin Sent: Monday, July 16, 2001
12:39 PM To: Orion-Interest Subject: Clustering..
Hi all,
I know how to cluster Orion..after all, its pretty easy.
What I want to know from someone who knows..is if in
the 1.5.2 version all the bugs (if there were
actually any) are worked out. Does Orion cluster with no problems?
Does session fail-over and application context
fail-over work without a hitch (providing all
objects in the session and/or context are serializable)? If you have two machines in an island, and the session begins on
one..does it automatically "copy" any session info
to the other box for you? If you shut that box off,
and all requests go to the 2nd box, does the session still exist with all objects still in memory?
I take it each and every request on a clustered box requires
the session to be duplicated exactly as is to the
other machine? If this is the case, at what "rate"
does Orion copy out the session and anything else to another
server in the island (or to each and every server in the
island)? How does this affect performance as
compared to using just a single box without clustering..is it 2 to 3 times slower because of not only copying
its session to one or more boxes, but also having to
deal with "merging" other boxes context/session
information into its own? Or does a cluster simply create the objects and session stuff on each box as its generated
(thus..its not some background thread that copies
session info when it has time to other
boxes)?
Is it equally good at clustering on the EJB tier (so
scalability on the EJB tier or the front-end WEB
tier is equally as easy)?
Thanks.
RE: Clustering..
Kevin, 1. clustering only handles http session data. sfsb's will not be replicated. 2. Although rmi can be clustered and you can get fail-over for ejb's, the ejb's are not load-balanced. 3. careful specification of the server is required, for example, the web-apps must be in the config/application.xml. 4. ssl loadbalancing does not work and is broken. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Monday, July 16, 2001 12:39 PM To: Orion-Interest Subject: Clustering.. Hi all, I know how to cluster Orion..after all, its pretty easy. What I want to know from someone who knows..is if in the 1.5.2 version all the bugs (if there were actually any) are worked out. Does Orion cluster with no problems? Does session fail-over and application context fail-over work without a hitch (providing all objects in the session and/or context are serializable)? If you have two machines in an island, and the session begins on one..does it automatically copy any session info to the other box for you? If you shut that box off, and all requests go to the 2nd box, does the session still exist with all objects still in memory? I take it each and every request on a clustered box requires the session to be duplicated exactly as is to the other machine? If this is the case, at what rate does Orion copy out the session and anything else to another server in the island (or to each and every server in the island)? How does this affect performance as compared to using just a single box without clustering..is it 2 to 3 times slower because of not only copying its session to one or more boxes, but also having to deal with merging other boxes context/session information into its own? Or does a cluster simply create the objects and session stuff on each box as its generated (thus..its not some background thread that copies session info when it has time to other boxes)? Is it equally good at clustering on the EJB tier (so scalability on the EJB tier or the front-end WEB tier is equally as easy)? Thanks.
RE: Clustering..
Thanks for the reply. 1. clustering only handles http session data. sfsb's will not be replicated. I thought that the entire application context was replicated? So anything set to Application scope (beans, etc) is NOT replicated? Is that the way it is supposed to be..or just a bug/enhancement for Orion team to work on? 2. Although rmi can be clustered and you can get fail-over for ejb's, the ejb's are not load-balanced. Not sure if I understand..I thought load balancing was done via a hardware load balancer? In other words, wouldn't you have a setup like a firewall that feeds to a load-balancer that then feeds to one (or more) islands, each having one (or more) servers running EJB? The front-end cluster would access this single fire-wall IP (via JNDI when looking up EJBs), which would follow the flow to the ejb cluster. When you are talking about clustering EJB's (load balancing them), how have you done this, or how is it normally done? Again..i would think the identical hardware to load-balance the front-end cluster would be in place for the EJB tier..including a firewall since EJB's may be directly accessed via WAN clients, or from Web Services? 3. careful specification of the server is required, for example, the web-apps must be in the config/application.xml. This is new to me. I haven't read any recent clustering docs, but the original clustering doc (not even sure if Orion ever posted it, or if it is on orionsupport.com or not) had specific settings in web.xml (setting the clusterable option), and I think in orion-web.xml and the .xml config file under /orion/config for the specific application to be clustered. Has this all changed? 4. ssl loadbalancing does not work and is broken. I just mentioned this to our CTO. I think using a hardware SSL device (whether as a separate linux box that handles the encoding/decoding, web server that forwards all SSL on after encoding/decoding, or a stand-alone hardware box that does this very fast (my personal favorite)) should take care of this. For the mere $5K you pay for a box that can handle several hundred SSL transactions per second, I think its worth the peace of mind it gives you in not having to do any SSL coding tricks. I remember reading something about how SSL sessions were getting lost. Don't recall what this was about..but it makes me worry about moving to Orion (or OC4J) if SSL doesn't fully work. Maybe I am missing something..but I would think a good part of the appeal to move to an App Server is for its clustering capabilities. Sure, you get awesome web performance, simple setup and powerful features for a single server/app server setup. But if your site grows, you are bound to require clustering..aren't you? Or does everyone just add a new box and load-balance via session/cookie keys to the specific one box with no fail-over of the session? Alot of sites, like google.com and the bunch must have tons of web servers. Are they not set up in a cluster? I mean..search engines probably aren't..they just have to handle major hits and database access for searches. But transaction based sites like online bank sites, e-commerce, etc must use more than a single server AND preserve the sessions incase of failure..don't they? Thanks again. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Monday, July 16, 2001 12:39 PM To: Orion-Interest Subject: Clustering.. Hi all, I know how to cluster Orion..after all, its pretty easy. What I want to know from someone who knows..is if in the 1.5.2 version all the bugs (if there were actually any) are worked out. Does Orion cluster with no problems? Does session fail-over and application context fail-over work without a hitch (providing all objects in the session and/or context are serializable)? If you have two machines in an island, and the session begins on one..does it automatically copy any session info to the other box for you? If you shut that box off, and all requests go to the 2nd box, does the session still exist with all objects still in memory? I take it each and every request on a clustered box requires the session to be duplicated exactly as is to the other machine? If this is the case, at what rate does Orion copy out the session and anything else to another server in the island (or to each and every server in the island)? How does this affect performance as compared to using just a single box without clustering..is it 2 to 3 times slower because of not only copying its session to one or more boxes, but also having to deal with merging other boxes context/session information into its own? Or does a cluster simply create the objects and session stuff on each box as its generated (thus..its not some background thread that copies session info when it has time to other boxes)? Is it equally good at clustering on the
RE: Clustering..
Title: RE: Clustering.. Clustering in orion is only for sessions. EJB clustering is not yet provided. The clustering mechanism in orion is based on JMS(Topic/Subscriber). When every you keep information in session by using setSessionAttribute(String name, Object object) the session information is copied to all other clusters. All objects in the seesion must be serializable inorder to provide clustering. Once clustering is enabled if switch requests between islands you will have session information valid. Unfortuantely this mechanism is little expensive in terms of memory since session information is kept in memory of all islands. So adding one more machine or island into the cluster group doesn't reduce your memory requirements rather it increase your memory requirements. This mechanism have one drawback: If you keep an object in session and later some place you get the reference of the object and modify the object the modifications won't get reflect across islands: Example: UserInfo info = new UserInfo() // Some kind of object... info.user_name = oldName; session.setAttribute(UserInfo, info) // At this point the info is replicated to all cluster islands //Later at any place of your code UserInfo info = session.getAttribute(UserInfo); info.user_name = newName; //This change won't replicated //In some other program UserInfo info = session.getAttribute(UserInfo); System.out.println(info.user_name) // If the request comes to the same cluster where the modification occures you will get the NewName if the request goes to another cluster you will get oldname Work Around: If you do any kind of modifications to your session objects put the objects again into session using setSessionAttribute. Keep one thing in mind that when ever you call this setSessionAttribute method the session info is going to replicate across different islands. I think this is too much to put down. If some one finds boaring just ignore this mail. This is the same problem which I faced and lead me to write my own session management. Kesav Kumar Kolla Voquette Inc 650 356 3740(W) 510 889 6840(R) Voquette...Delivering Sound Information -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Monday, July 16, 2001 12:39 PM To: Orion-Interest Subject: Clustering.. Hi all, I know how to cluster Orion..after all, its pretty easy. What I want to know from someone who knows..is if in the 1.5.2 version all the bugs (if there were actually any) are worked out. Does Orion cluster with no problems? Does session fail-over and application context fail-over work without a hitch (providing all objects in the session and/or context are serializable)? If you have two machines in an island, and the session begins on one..does it automatically copy any session info to the other box for you? If you shut that box off, and all requests go to the 2nd box, does the session still exist with all objects still in memory? I take it each and every request on a clustered box requires the session to be duplicated exactly as is to the other machine? If this is the case, at what rate does Orion copy out the session and anything else to another server in the island (or to each and every server in the island)? How does this affect performance as compared to using just a single box without clustering..is it 2 to 3 times slower because of not only copying its session to one or more boxes, but also having to deal with merging other boxes context/session information into its own? Or does a cluster simply create the objects and session stuff on each box as its generated (thus..its not some background thread that copies session info when it has time to other boxes)? Is it equally good at clustering on the EJB tier (so scalability on the EJB tier or the front-end WEB tier is equally as easy)? Thanks.
RE: Clustering..
Title: RE: Clustering..
Kesar,
you
can cluster you ejb's, but this is through rmi. The clustering means that if,
for some reason, your remote ejb's go down, another server can pick it up. This
is failover but not loadbalancing. Take a look at the rmi.xml file spec to see
the clustering.
Regards,
the
elephantwalker
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kesav
KumarSent: Monday, July 16, 2001 3:32 PMTo:
Orion-InterestSubject: RE: Clustering..
Clustering in orion is only for sessions. EJB clustering
is not yet provided.
The clustering mechanism in orion is based on
JMS(Topic/Subscriber). When every you keep information in session by
using setSessionAttribute(String name, Object object) the session information
is copied to all other clusters.
All objects in the seesion must be serializable inorder to
provide clustering. Once clustering is enabled if switch requests
between islands you will have session information valid.
Unfortuantely this mechanism is little expensive in terms of
memory since session information is kept in memory of all islands. So
adding one more machine or island into the cluster group doesn't reduce your
memory requirements rather it increase your memory requirements.
This mechanism have one drawback: If you keep an object
in session and later some place you get the reference of the object and modify
the object the modifications won't get reflect across islands:
Example:
UserInfo info = new UserInfo() // Some kind of
object... info.user_name = "oldName";
session.setAttribute("UserInfo", info) // At this point the info is
replicated to all cluster islands
//Later at any place of your code
UserInfo info =
session.getAttribute("UserInfo");
info.user_name =
"newName"; //This change won't replicated
//In some other program
UserInfo info =
session.getAttribute("UserInfo");
System.out.println(info.user_name) // If the request comes to the
same cluster where the modification occures you will get the "NewName" if the
request goes to another cluster you will get "oldname"
Work Around: If you do any kind of modifications to your
session objects put the objects again into session using
setSessionAttribute. Keep one thing in mind that when ever you call this
setSessionAttribute method the session info is going to replicate across
different islands.
I think this is too much to put down. If some one finds
boaring just ignore this mail.
This is the same problem which I faced and lead me to write my
own session management.
Kesav Kumar Kolla Voquette Inc
650 356 3740(W) 510 889
6840(R) Voquette...Delivering Sound Information
-Original Message- From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Duffey, Kevin Sent: Monday, July 16, 2001
12:39 PM To: Orion-Interest Subject: Clustering..
Hi all,
I know how to cluster Orion..after all, its pretty easy. What
I want to know from someone who knows..is if in the
1.5.2 version all the bugs (if there were actually
any) are worked out. Does Orion cluster with no problems? Does
session fail-over and application context fail-over work
without a hitch (providing all objects in the session
and/or context are serializable)? If you have two
machines in an island, and the session begins on one..does it automatically "copy" any session info to the other box for you? If you
shut that box off, and all requests go to the 2nd box,
does the session still exist with all objects still in
memory?
I take it each and every request on a clustered box requires
the session to be duplicated exactly as is to the
other machine? If this is the case, at what "rate"
does Orion copy out the session and anything else to another server in the island (or to each and every server in the island)? How
does this affect performance as compared to using just
a single box without clustering..is it 2 to 3 times
slower because of not only copying its session to one
or more boxes, but also having to deal with "merging" other boxes context/session information into its own? Or does a cluster
simply create the objects and session stuff on each
box as its generated (thus..its not some background
thread that copies session info when it has time to other boxes)?
Is it equally good at clustering on the EJB tier (so
scalability on the EJB tier or the front-end WEB tier
is equally as easy)?
Thanks.
RE: Clustering..
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Monday, July 16, 2001 1:35 PM To: Orion-Interest Subject: RE: Clustering.. Thanks for the reply. 1. clustering only handles http session data. sfsb's will not be replicated. I thought that the entire application context was replicated? So anything set to Application scope (beans, etc) is NOT replicated? Is that the way it is supposed to be..or just a bug/enhancement for Orion team to work on? ew I believe only the session context is replicated, but you will notice that if you don't have a Serializable object, the server will throw an error. I don't think the application context is replicated...since each server has its own application context. If you fall over to another server, you get that servers application context...otherwise all of the other applications would have problems. This shouldn't be a problem, since usually the app context is the same on each server in a cluster. 2. Although rmi can be clustered and you can get fail-over for ejb's, the ejb's are not load-balanced. Not sure if I understand..I thought load balancing was done via a hardware load balancer? In other words, wouldn't you have a setup like a firewall that feeds to a load-balancer that then feeds to one (or more) islands, each having one (or more) servers running EJB? The front-end cluster would access this single fire-wall IP (via JNDI when looking up EJBs), which would follow the flow to the ejb cluster. When you are talking about clustering EJB's (load balancing them), how have you done this, or how is it normally done? Again..i would think the identical hardware to load-balance the front-end cluster would be in place for the EJB tier..including a firewall since EJB's may be directly accessed via WAN clients, or from Web Services? ew you can use hardware or the software loadbalancer. The ejb's have nothing to do with the http loadbalancing. That the ejb's happen to be on the same servers is not actually garanteed unless you plan it that way. You can use remote ejb's from other servers on other machines. I mean, that's the whole point of ejb's. One ejb pseudo loadbalancing technique is to set the maximum number of beans on any one server, and then cluster the rmi. As one server fills up, another server will kick-in to server ejb's. This isn't really loadbalancing, though, but it is fail-over. 3. careful specification of the server is required, for example, the web-apps must be in the config/application.xml. This is new to me. I haven't read any recent clustering docs, but the original clustering doc (not even sure if Orion ever posted it, or if it is on orionsupport.com or not) had specific settings in web.xml (setting the clusterable option), and I think in orion-web.xml and the .xml config file under /orion/config for the specific application to be clustered. Has this all changed? ew if an application is not bound to the default application, you will need a separate web-app tag in the config/application.xml file to make sure the session data is clustered. The docs only cover clustering and loadbalancing the default web site and anything bound to this app. Of course you can have more than one web-app which is not bound to the default web site, but another web-site. 4. ssl loadbalancing does not work and is broken. I just mentioned this to our CTO. I think using a hardware SSL device (whether as a separate linux box that handles the encoding/decoding, web server that forwards all SSL on after encoding/decoding, or a stand-alone hardware box that does this very fast (my personal favorite)) should take care of this. For the mere $5K you pay for a box that can handle several hundred SSL transactions per second, I think its worth the peace of mind it gives you in not having to do any SSL coding tricks. I remember reading something about how SSL sessions were getting lost. Don't recall what this was about..but it makes me worry about moving to Orion (or OC4J) if SSL doesn't fully work. ew proxy or hardware for the ssl acceleration is the way to go. Sonicwall even has a hardware accelerator that looks like a network interface to your server for $2500. SSL works fine on the server, its just the software loadbalancer that doesn't work with ssl. Maybe I am missing something..but I would think a good part of the appeal to move to an App Server is for its clustering capabilities. Sure, you get awesome web performance, simple setup and powerful features for a single server/app server setup. But if your site grows, you are bound to require clustering..aren't you? Or does everyone just add a new box and load-balance via session/cookie keys to the specific one box with no fail-over of the session? Alot of sites, like google.com and the bunch must have tons of web servers. Are they not set up in a cluster? I mean..search engines probably aren't..they just have to handle major hits and database access
Re: clustering + ssl together
Hello, I just encountered this problem myself, and a question popped up: In which version did this bug appear? So I went as far back as 1.3.8 and the bug was still there. Is there a possibility of misconfiguration here? Can anybody from Orion development team comment on this? This a very important issue to me and any feedback is greatly appreciated. Thank you, Greg Kogan.
RE: clustering + ssl together
Sure.. you can do this: some kind of ssl proxy: 1. apache w/ ssl_mod and reverse proxy or 2. openssl w/ sslproxy These software frontends handle the conversion from ssl to normal http headers. The backend would be the loadbalancer from orion, but with no ssl configuration. These could be on the same machine. Of course, the frontend ... tag in the web-site.xml would have to have the proxy address and port, and not the loadbalancer's address and port. 3. You could also do the same thing with a hardware ssl accelerator (for example, the sonic wall ssl accelerator) which front-ends the loadbalancer. There are also many other more expensive hardware solutions to this. If a dedicated machine is used for 1 or 2, the cost is about the same as 3. Oracle's strategy for using orion is the same: 1. https:// and http:// static loadbalancing from their apache adapted frontend (like 1 or 2, above) 2. http session aware loadbalancing from the oc4j loadbalancer (Orion 1.5.x). So you can be damn sure it works with Orion. There is a 4th option. This is so clearly a need in the market that nobody has addressed effectively for the low end, write your own ssl proxy front end, put in on a computer and disk on a chip..there's a cnet article on how to do this, and start selling it at a price below sonic wall's price. Likewise, the clustering architecture that Orion uses makes use of multicast messaging in java. If we had an open interface to this, you could right you own loadbalancer...;). Regards, the elephantwalker .ps I have found that the only thing the secure=true controls is which port is listened to, port 443 (for true) and port 80 for anything else (secure=apples makes the loadbalancer listen to the port 80). You can comment out the ssl-config tag, and have secure-true and there are NO COMPLAINTS. If you do the same in a web-site.xml, the server complains that there is no secure classdefinitantly this is a broken feature :(. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Kogan Sent: Friday, July 06, 2001 2:37 PM To: Orion-Interest Subject: Re: clustering + ssl together Greg, The orion team doesn't ordinarily moniter the orion-interest list. I have contacted them by email directly under our license contract, and Karl noted the configuration for ssl in the load-balancer.xml. However, I haven't heard from him after several direct emails. I think they are a little busy now. An email from Karl is included below. It might be a configuration error, but the ssl-config tag is exactly the same as the tag used in the web-site.xml, so I don't think that is the issue. When I used openssl s_client to check what was going on, it appears to blow-up in the handshake step. Regards, the elephantwalker Thanks for the info. BTW, I looked on bugzilla, and this bug is not assigned to a developer yet (if that means anything at all), though it seems to be a show stopper (from my point of view.) .ps I think many people use apache reverse-proxy server and/or hardware loadbalancers to do this. There doesn't seem to be much interest in using an orion ssl loadbalancer solution, or there would have been more response to this email trail. Sun's crypto solution is notoriously slow, so this could be why people aren't very interested in this. Is it possible to use apache reverse-proxy server and/or hardware loadbalancers and still make use of clustering (ssl or not)? I personally am not attached to orion's loadballancer. I simply did not find another way to achieve HTTP state replication. If you know of another way, please let me know. Thanks, Greg. Karls email to me: Please answer these questions. We have two problems with the loadbalancer 1. The access log for each orion instance only lists the ip address of the loadbalancer. We need a workaround for this bug (already logged as a bug). Forwarding the ip of the request initiator to the backend is a feature that's not implemented yet. I can't see a way for you to handle this, unless you add your own logging mechanism. 2. How to loadbalance our ssl site? Look at http://www.orionserver.com/docs/load-balancer.xml.html That shows the syntax of the load-balancer.xml file. Look at the secure attribute and the ssl-config. Remember, that the software loadbalancer provided might not give the same performance as a hardware loadbalancer, and it might become a bottleneck if you need to serve many requests. Regards, Karl Avedal -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Kogan Sent: Friday, July 06, 2001 10:18 AM To: Orion-Interest Subject: Re: clustering + ssl together Hello, I just encountered this problem myself, and a question popped up: In which version did this bug appear? So I went as far back as 1.3.8 and the bug was still there. Is there a possibility of misconfiguration here? Can anybody from Orion
RE: clustering + ssl together
Greg, I just tried this... 1. I assummed that ssl was completely broken for the loadbalancer. So I stripped off the secure=true from my loadbalancer on port 443 and all of my secure-web-site.xml's backends'. 2. I created a new orion instance with only the secure-web-site.xml in the server.xml. 3. I modified the global-web-application.xml so that the only servlet and mapping is this: servlet servlet-nametunnel/servlet-name servlet-classcom.evermind.server.http.TunnelServlet/servlet-class init-param param-nametargetRoot/param-name param-valuehttp://loadbalancermachine:443//param-value /init-param /servlet servlet-mapping servlet-nametunnel/servlet-name url-pattern/*/url-pattern /servlet-mapping 5. I started the new proxy orion instance. With my browser, I put https://proxymachine/ ... Voila! it worked! Its a little slow, so you could probably do this with a reverse-proxy, ssl apache to get faster response. This is only a workaround, since the loadbalancer ssl is broken now. Regards, the elephantwalker .ps the only caveat here is the j2ee j_security_check won't work, but otherwise, everything works. I don't understand why, though. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Wednesday, June 27, 2001 12:00 AM To: Orion-Interest Subject: Re: clustering + ssl together ew, using your example, i have tried the equivalent of https://localhost/mysecuresite/login which should have gone to port 443. in the effort to look under orion's covers. i've seen a -Djavax.net.debug=all flag mentioned in a previous post by tomas anderson (27.6.01), and gave it a try but no extra output appeared in orion. do you know what this is supposed to show? do you know if there is a way to see where the request is getting up to? can we do a netstat or something to see where the request is falling over or what processes are listening on what ports? greg. - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 2:58 PM Subject: RE: clustering + ssl together Greg, I just tried something which ALMOST worked. I tried the secure loadbalancer instance like this in the browser: http://localhost:443/mysecuresite/login. The secure loadbalancer showed a session id, and forwarded the request to the secure island! Of course the site didn't do anything, since it was looking for a handshake. It looks like the loadbalancer is just not doing its bit...it is refusing all connections which are secure. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Tuesday, June 26, 2001 3:00 PM To: Orion-Interest Subject: Re: clustering + ssl together ew, i was trying to run a single secure load balancer with it's own load-balancer.xml. loadbalancer did register the 2 orions i'd set up to appear in the cluster, but after being able to see them appear on the loadbalancer screen, i was still unable to access my web app. the browser just sat there with the little IE symbol spinning, but no joy. all orions and the loadbalancer had their own keystore setup using a test certificate generated from thawte.com loadbalancer = secure and on port 443 (on box1) orion1 = secure and on port 443 (on box2) orion2 = secure and on port 8080 (on box1) !! but only in some experiments. i also tried various other configurations of the loadbalancer and cluster machines having secure on/off, etc. and swapping the port numbers around, e.g. when loadbalancer and orion2 were both running, they were both secure=true but obviously only one can run on port 443 at one time, so i made orion2 run on port 8080 while secure=true was set. i also had a look at apache for how to setup SSL but it looks like you've got to compile the mod in yourself for win32 so i've given that a miss for the moment. greg. - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 2:48 AM Subject: RE: clustering + ssl together Here are the hickups in the plan so far...see below. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Monday, June 25, 2001 1:29 AM To: Orion-Interest Subject: RE: clustering + ssl together Greg, I am doing this now, so I will get back to the list when I am finished. This is my working plan: 1. there are two loadbalancers instances, one for http and one for https. These can be on the same machine or seperate machines. hickup At one level this works, but you have to set the minimumIsland/maximumIsland so that each respective loadbalancer picks up either the https island or the http island. However, https connections do not work. It could be because of this blurb
RE: clustering + ssl together
Greg, I found a tool that you can use to look at what's going on with ssl and the loadbalancer or orion. If you are using linux, you probably have this already, openssl. I am not sure if there is a windows build, though. at the command line: openssl s_client -connect loadbalancermachine:443 -state -debug The result is clear, ssl returns with an ssl handshake failure. If you do this on the an instance of orion with ssl: openssl s_client -connect orionmachine:443 -state -debug There is no problem. So that nails the bug down, its got to be the loadbalancer. I will post this in bug 525 for Karl. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Thursday, June 28, 2001 2:22 PM To: Orion-Interest Subject: RE: clustering + ssl together Greg, I just tried this... 1. I assummed that ssl was completely broken for the loadbalancer. So I stripped off the secure=true from my loadbalancer on port 443 and all of my secure-web-site.xml's backends'. 2. I created a new orion instance with only the secure-web-site.xml in the server.xml. 3. I modified the global-web-application.xml so that the only servlet and mapping is this: servlet servlet-nametunnel/servlet-name servlet-classcom.evermind.server.http.TunnelServlet/servlet-class init-param param-nametargetRoot/param-name param-valuehttp://loadbalancermachine:443//param-value /init-param /servlet servlet-mapping servlet-nametunnel/servlet-name url-pattern/*/url-pattern /servlet-mapping 5. I started the new proxy orion instance. With my browser, I put https://proxymachine/ ... Voila! it worked! Its a little slow, so you could probably do this with a reverse-proxy, ssl apache to get faster response. This is only a workaround, since the loadbalancer ssl is broken now. Regards, the elephantwalker .ps the only caveat here is the j2ee j_security_check won't work, but otherwise, everything works. I don't understand why, though. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Wednesday, June 27, 2001 12:00 AM To: Orion-Interest Subject: Re: clustering + ssl together ew, using your example, i have tried the equivalent of https://localhost/mysecuresite/login which should have gone to port 443. in the effort to look under orion's covers. i've seen a -Djavax.net.debug=all flag mentioned in a previous post by tomas anderson (27.6.01), and gave it a try but no extra output appeared in orion. do you know what this is supposed to show? do you know if there is a way to see where the request is getting up to? can we do a netstat or something to see where the request is falling over or what processes are listening on what ports? greg. - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 2:58 PM Subject: RE: clustering + ssl together Greg, I just tried something which ALMOST worked. I tried the secure loadbalancer instance like this in the browser: http://localhost:443/mysecuresite/login. The secure loadbalancer showed a session id, and forwarded the request to the secure island! Of course the site didn't do anything, since it was looking for a handshake. It looks like the loadbalancer is just not doing its bit...it is refusing all connections which are secure. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Tuesday, June 26, 2001 3:00 PM To: Orion-Interest Subject: Re: clustering + ssl together ew, i was trying to run a single secure load balancer with it's own load-balancer.xml. loadbalancer did register the 2 orions i'd set up to appear in the cluster, but after being able to see them appear on the loadbalancer screen, i was still unable to access my web app. the browser just sat there with the little IE symbol spinning, but no joy. all orions and the loadbalancer had their own keystore setup using a test certificate generated from thawte.com loadbalancer = secure and on port 443 (on box1) orion1 = secure and on port 443 (on box2) orion2 = secure and on port 8080 (on box1) !! but only in some experiments. i also tried various other configurations of the loadbalancer and cluster machines having secure on/off, etc. and swapping the port numbers around, e.g. when loadbalancer and orion2 were both running, they were both secure=true but obviously only one can run on port 443 at one time, so i made orion2 run on port 8080 while secure=true was set. i also had a look at apache for how to setup SSL but it looks like you've got to compile the mod in yourself for win32 so i've given that a miss for the moment. greg. - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Wednesday, June 27
Re: clustering + ssl together
cool. thanks for the info. we're using windows so i'll try to track down a version. look like you've nailed the bug? down pretty well. hopefully, the orion lads will be nice enough to fix it for the next build. - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Friday, June 29, 2001 8:59 AM Subject: RE: clustering + ssl together Greg, I found a tool that you can use to look at what's going on with ssl and the loadbalancer or orion. If you are using linux, you probably have this already, openssl. I am not sure if there is a windows build, though. at the command line: openssl s_client -connect loadbalancermachine:443 -state -debug The result is clear, ssl returns with an ssl handshake failure. If you do this on the an instance of orion with ssl: openssl s_client -connect orionmachine:443 -state -debug There is no problem. So that nails the bug down, its got to be the loadbalancer. I will post this in bug 525 for Karl. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Thursday, June 28, 2001 2:22 PM To: Orion-Interest Subject: RE: clustering + ssl together Greg, I just tried this... 1. I assummed that ssl was completely broken for the loadbalancer. So I stripped off the secure=true from my loadbalancer on port 443 and all of my secure-web-site.xml's backends'. 2. I created a new orion instance with only the secure-web-site.xml in the server.xml. 3. I modified the global-web-application.xml so that the only servlet and mapping is this: servlet servlet-nametunnel/servlet-name servlet-classcom.evermind.server.http.TunnelServlet/servlet-class init-param param-nametargetRoot/param-name param-valuehttp://loadbalancermachine:443//param-value /init-param /servlet servlet-mapping servlet-nametunnel/servlet-name url-pattern/*/url-pattern /servlet-mapping 5. I started the new proxy orion instance. With my browser, I put https://proxymachine/ ... Voila! it worked! Its a little slow, so you could probably do this with a reverse-proxy, ssl apache to get faster response. This is only a workaround, since the loadbalancer ssl is broken now. Regards, the elephantwalker .ps the only caveat here is the j2ee j_security_check won't work, but otherwise, everything works. I don't understand why, though. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Wednesday, June 27, 2001 12:00 AM To: Orion-Interest Subject: Re: clustering + ssl together ew, using your example, i have tried the equivalent of https://localhost/mysecuresite/login which should have gone to port 443. in the effort to look under orion's covers. i've seen a -Djavax.net.debug=all flag mentioned in a previous post by tomas anderson (27.6.01), and gave it a try but no extra output appeared in orion. do you know what this is supposed to show? do you know if there is a way to see where the request is getting up to? can we do a netstat or something to see where the request is falling over or what processes are listening on what ports? greg. - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 2:58 PM Subject: RE: clustering + ssl together Greg, I just tried something which ALMOST worked. I tried the secure loadbalancer instance like this in the browser: http://localhost:443/mysecuresite/login. The secure loadbalancer showed a session id, and forwarded the request to the secure island! Of course the site didn't do anything, since it was looking for a handshake. It looks like the loadbalancer is just not doing its bit...it is refusing all connections which are secure. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Tuesday, June 26, 2001 3:00 PM To: Orion-Interest Subject: Re: clustering + ssl together ew, i was trying to run a single secure load balancer with it's own load-balancer.xml. loadbalancer did register the 2 orions i'd set up to appear in the cluster, but after being able to see them appear on the loadbalancer screen, i was still unable to access my web app. the browser just sat there with the little IE symbol spinning, but no joy. all orions and the loadbalancer had their own keystore setup using a test certificate generated from thawte.com loadbalancer = secure and on port 443 (on box1) orion1 = secure and on port 443 (on box2) orion2 = secure and on port 8080 (on box1) !! but only in some experiments. i also tried various other configurations of the loadbalancer and cluster machines having secure on/off, etc. and swapping the port
Re: clustering + ssl together
ew, using your example, i have tried the equivalent of https://localhost/mysecuresite/login which should have gone to port 443. in the effort to look under orion's covers. i've seen a -Djavax.net.debug=all flag mentioned in a previous post by tomas anderson (27.6.01), and gave it a try but no extra output appeared in orion. do you know what this is supposed to show? do you know if there is a way to see where the request is getting up to? can we do a netstat or something to see where the request is falling over or what processes are listening on what ports? greg. - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 2:58 PM Subject: RE: clustering + ssl together Greg, I just tried something which ALMOST worked. I tried the secure loadbalancer instance like this in the browser: http://localhost:443/mysecuresite/login. The secure loadbalancer showed a session id, and forwarded the request to the secure island! Of course the site didn't do anything, since it was looking for a handshake. It looks like the loadbalancer is just not doing its bit...it is refusing all connections which are secure. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Tuesday, June 26, 2001 3:00 PM To: Orion-Interest Subject: Re: clustering + ssl together ew, i was trying to run a single secure load balancer with it's own load-balancer.xml. loadbalancer did register the 2 orions i'd set up to appear in the cluster, but after being able to see them appear on the loadbalancer screen, i was still unable to access my web app. the browser just sat there with the little IE symbol spinning, but no joy. all orions and the loadbalancer had their own keystore setup using a test certificate generated from thawte.com loadbalancer = secure and on port 443 (on box1) orion1 = secure and on port 443 (on box2) orion2 = secure and on port 8080 (on box1) !! but only in some experiments. i also tried various other configurations of the loadbalancer and cluster machines having secure on/off, etc. and swapping the port numbers around, e.g. when loadbalancer and orion2 were both running, they were both secure=true but obviously only one can run on port 443 at one time, so i made orion2 run on port 8080 while secure=true was set. i also had a look at apache for how to setup SSL but it looks like you've got to compile the mod in yourself for win32 so i've given that a miss for the moment. greg. - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 2:48 AM Subject: RE: clustering + ssl together Here are the hickups in the plan so far...see below. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Monday, June 25, 2001 1:29 AM To: Orion-Interest Subject: RE: clustering + ssl together Greg, I am doing this now, so I will get back to the list when I am finished. This is my working plan: 1. there are two loadbalancers instances, one for http and one for https. These can be on the same machine or seperate machines. hickup At one level this works, but you have to set the minimumIsland/maximumIsland so that each respective loadbalancer picks up either the https island or the http island. However, https connections do not work. It could be because of this blurb in the load-balancer.xml description: secure - Whether or not to use SSL. The default is false. SSL is only used when using session (not IP) based balancing and the backend and the site is using SSL. If you specify the balancer to use SSL then the backend servers will not (the balancer converts to HTTP, ie contains the SSL layer). Note that this puts the strain of decoding the SSL on the balancer. I'm sorry, but does this say that we have the option of NOT using SSL for the balancer, but using it for the backend? Or if we use SSL for the balancer, SSL isn't used on the backend (and thus we have to strip all of the SSL configuration from the backend)? /hickup 2. the ports for your web-sites can be different from your loadbalancer(s) port. This allows you to have the loadbalancer and an orion instance on the same machine, for example. Or the ports can be the same, in which case the loadbalancer(s) has to be on a different machine. hickup Since web-sites are load-balanced (not applications), its important that each *web-site.xml which you use have its own island. This is done by setting the cluster-island attribute in the web-site tag. See above for reference to min/max island ids for the loadbalancer. The port bit seems to work. That is, the http web-site had a port of 10180, and the http loadbalancer
Re: clustering + ssl together
nice one. since the purpose of the work we've both been doing is to get a clustered SSL setup going, would it be worth adding something to the bug report? i.e. which asks karl and magnus very nicely to see if they can create a clustered SSL setup? greg - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 3:57 PM Subject: RE: clustering + ssl together Greg, I just logged this as bug 525. The ssl loadbalancer just won't accept connections with https://, but will accept connections with http://. Basic problem with the code. Its not us. Karl and Magnus need to fix this. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Tuesday, June 26, 2001 9:59 PM To: Orion-Interest Subject: RE: clustering + ssl together Greg, I just tried something which ALMOST worked. I tried the secure loadbalancer instance like this in the browser: http://localhost:443/mysecuresite/login. The secure loadbalancer showed a session id, and forwarded the request to the secure island! Of course the site didn't do anything, since it was looking for a handshake. It looks like the loadbalancer is just not doing its bit...it is refusing all connections which are secure. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Tuesday, June 26, 2001 3:00 PM To: Orion-Interest Subject: Re: clustering + ssl together ew, i was trying to run a single secure load balancer with it's own load-balancer.xml. loadbalancer did register the 2 orions i'd set up to appear in the cluster, but after being able to see them appear on the loadbalancer screen, i was still unable to access my web app. the browser just sat there with the little IE symbol spinning, but no joy. all orions and the loadbalancer had their own keystore setup using a test certificate generated from thawte.com loadbalancer = secure and on port 443 (on box1) orion1 = secure and on port 443 (on box2) orion2 = secure and on port 8080 (on box1) !! but only in some experiments. i also tried various other configurations of the loadbalancer and cluster machines having secure on/off, etc. and swapping the port numbers around, e.g. when loadbalancer and orion2 were both running, they were both secure=true but obviously only one can run on port 443 at one time, so i made orion2 run on port 8080 while secure=true was set. i also had a look at apache for how to setup SSL but it looks like you've got to compile the mod in yourself for win32 so i've given that a miss for the moment. greg. - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 2:48 AM Subject: RE: clustering + ssl together Here are the hickups in the plan so far...see below. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Monday, June 25, 2001 1:29 AM To: Orion-Interest Subject: RE: clustering + ssl together Greg, I am doing this now, so I will get back to the list when I am finished. This is my working plan: 1. there are two loadbalancers instances, one for http and one for https. These can be on the same machine or seperate machines. hickup At one level this works, but you have to set the minimumIsland/maximumIsland so that each respective loadbalancer picks up either the https island or the http island. However, https connections do not work. It could be because of this blurb in the load-balancer.xml description: secure - Whether or not to use SSL. The default is false. SSL is only used when using session (not IP) based balancing and the backend and the site is using SSL. If you specify the balancer to use SSL then the backend servers will not (the balancer converts to HTTP, ie contains the SSL layer). Note that this puts the strain of decoding the SSL on the balancer. I'm sorry, but does this say that we have the option of NOT using SSL for the balancer, but using it for the backend? Or if we use SSL for the balancer, SSL isn't used on the backend (and thus we have to strip all of the SSL configuration from the backend)? /hickup 2. the ports for your web-sites can be different from your loadbalancer(s) port. This allows you to have the loadbalancer and an orion instance on the same machine, for example. Or the ports can be the same, in which case the loadbalancer(s) has to be on a different machine. hickup Since web-sites are load-balanced (not applications), its important that each *web-site.xml which you use have its own island. This is done by setting the cluster-island attribute in the web-site tag. See above for reference to min/max
RE: clustering + ssl together
Here are the hickups in the plan so far...see below. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Monday, June 25, 2001 1:29 AM To: Orion-Interest Subject: RE: clustering + ssl together Greg, I am doing this now, so I will get back to the list when I am finished. This is my working plan: 1. there are two loadbalancers instances, one for http and one for https. These can be on the same machine or seperate machines. hickup At one level this works, but you have to set the minimumIsland/maximumIsland so that each respective loadbalancer picks up either the https island or the http island. However, https connections do not work. It could be because of this blurb in the load-balancer.xml description: secure - Whether or not to use SSL. The default is false. SSL is only used when using session (not IP) based balancing and the backend and the site is using SSL. If you specify the balancer to use SSL then the backend servers will not (the balancer converts to HTTP, ie contains the SSL layer). Note that this puts the strain of decoding the SSL on the balancer. I'm sorry, but does this say that we have the option of NOT using SSL for the balancer, but using it for the backend? Or if we use SSL for the balancer, SSL isn't used on the backend (and thus we have to strip all of the SSL configuration from the backend)? /hickup 2. the ports for your web-sites can be different from your loadbalancer(s) port. This allows you to have the loadbalancer and an orion instance on the same machine, for example. Or the ports can be the same, in which case the loadbalancer(s) has to be on a different machine. hickup Since web-sites are load-balanced (not applications), its important that each *web-site.xml which you use have its own island. This is done by setting the cluster-island attribute in the web-site tag. See above for reference to min/max island ids for the loadbalancer. The port bit seems to work. That is, the http web-site had a port of 10180, and the http loadbalancer listened on port 80. This was no problem. So if you want to have the loadbalancer and web-site on the same ip address, you will need to set the website port to something else so they don't conflict. /hickup 3. the same rules apply for the loadbalancer as orion for unix machines. You need to use some port forwarding, like ipchains, if you want to run the loadbalancer on a user account which is not the superuser. This applies also for the ssl port. (skip 3 if you are using m$ or don't care) 4. the ssl setup in the load-balancer.xml (see the ssl-config tag in the load-balancer.xml documentation) is the same as the secure-web-site.xml, but you will have to set the secure flag in the load-balancer tag. Obviously, this means you will need a keystore for the loadbalancer, and a keystore for the backend for total secure communication. I believe that the communication to the backend is transparant to the user, so you can self certify that connection, irregardless of what those guys at verisign say. 5. you can skip all of this and use apache for ssl (interesting, but slow). This is what oracle advises, because they can't figure out orion, or they have so much invested in the apache/oracle solution. hickup This option is looking better and better. /hickup I'm testing this now, as soon as I get through the hickups, I will let the list know. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Sunday, June 24, 2001 3:02 PM To: Orion-Interest Subject: clustering + ssl together dear all, there has been a recent post on this but no solution posted. i've got some more info on the problem. can the developers of orion or anyone else let me know if anyone has successfully set up an ssl orion cluster? i can: - set up clustering - set up ssl ...but not both together. some clues. 1. on orionserver.com there is doco for load-balancer.xml that suggests loadbalancer.jar can be given SSL keystore information. does this mean that a clustered SSL setup requires loadbalancer to share the same keystore as each box in the cluster? 2. how do you set the web-site.xml for a clustered secure app. you can't have both the loadbalancer + your secure app both running on port 443 on the same box, so what do you do? i) run loadbalancer on another port? ii) run your app on another port? - the orion doco says that when your app needs to be made secure you should add a secure=true attribute to the web-site element of the web-site.xml plus remove the port attribute. if someone has made this work i'd be grateful for any information, or if you couldn't be bothered explaining how to do it, just maybe forward me your server.xml, loadbalancer.xml, web-site.xml and i'll work it out from that. thanks. greg.
Re: clustering + ssl together
ew, i was trying to run a single secure load balancer with it's own load-balancer.xml. loadbalancer did register the 2 orions i'd set up to appear in the cluster, but after being able to see them appear on the loadbalancer screen, i was still unable to access my web app. the browser just sat there with the little IE symbol spinning, but no joy. all orions and the loadbalancer had their own keystore setup using a test certificate generated from thawte.com loadbalancer = secure and on port 443 (on box1) orion1 = secure and on port 443 (on box2) orion2 = secure and on port 8080 (on box1) !! but only in some experiments. i also tried various other configurations of the loadbalancer and cluster machines having secure on/off, etc. and swapping the port numbers around, e.g. when loadbalancer and orion2 were both running, they were both secure=true but obviously only one can run on port 443 at one time, so i made orion2 run on port 8080 while secure=true was set. i also had a look at apache for how to setup SSL but it looks like you've got to compile the mod in yourself for win32 so i've given that a miss for the moment. greg. - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 2:48 AM Subject: RE: clustering + ssl together Here are the hickups in the plan so far...see below. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Monday, June 25, 2001 1:29 AM To: Orion-Interest Subject: RE: clustering + ssl together Greg, I am doing this now, so I will get back to the list when I am finished. This is my working plan: 1. there are two loadbalancers instances, one for http and one for https. These can be on the same machine or seperate machines. hickup At one level this works, but you have to set the minimumIsland/maximumIsland so that each respective loadbalancer picks up either the https island or the http island. However, https connections do not work. It could be because of this blurb in the load-balancer.xml description: secure - Whether or not to use SSL. The default is false. SSL is only used when using session (not IP) based balancing and the backend and the site is using SSL. If you specify the balancer to use SSL then the backend servers will not (the balancer converts to HTTP, ie contains the SSL layer). Note that this puts the strain of decoding the SSL on the balancer. I'm sorry, but does this say that we have the option of NOT using SSL for the balancer, but using it for the backend? Or if we use SSL for the balancer, SSL isn't used on the backend (and thus we have to strip all of the SSL configuration from the backend)? /hickup 2. the ports for your web-sites can be different from your loadbalancer(s) port. This allows you to have the loadbalancer and an orion instance on the same machine, for example. Or the ports can be the same, in which case the loadbalancer(s) has to be on a different machine. hickup Since web-sites are load-balanced (not applications), its important that each *web-site.xml which you use have its own island. This is done by setting the cluster-island attribute in the web-site tag. See above for reference to min/max island ids for the loadbalancer. The port bit seems to work. That is, the http web-site had a port of 10180, and the http loadbalancer listened on port 80. This was no problem. So if you want to have the loadbalancer and web-site on the same ip address, you will need to set the website port to something else so they don't conflict. /hickup 3. the same rules apply for the loadbalancer as orion for unix machines. You need to use some port forwarding, like ipchains, if you want to run the loadbalancer on a user account which is not the superuser. This applies also for the ssl port. (skip 3 if you are using m$ or don't care) 4. the ssl setup in the load-balancer.xml (see the ssl-config tag in the load-balancer.xml documentation) is the same as the secure-web-site.xml, but you will have to set the secure flag in the load-balancer tag. Obviously, this means you will need a keystore for the loadbalancer, and a keystore for the backend for total secure communication. I believe that the communication to the backend is transparant to the user, so you can self certify that connection, irregardless of what those guys at verisign say. 5. you can skip all of this and use apache for ssl (interesting, but slow). This is what oracle advises, because they can't figure out orion, or they have so much invested in the apache/oracle solution. hickup This option is looking better and better. /hickup I'm testing this now, as soon as I get through the hickups, I will let the list know. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Sunday, June 24
RE: clustering + ssl together
Greg, I just tried something which ALMOST worked. I tried the secure loadbalancer instance like this in the browser: http://localhost:443/mysecuresite/login. The secure loadbalancer showed a session id, and forwarded the request to the secure island! Of course the site didn't do anything, since it was looking for a handshake. It looks like the loadbalancer is just not doing its bit...it is refusing all connections which are secure. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Tuesday, June 26, 2001 3:00 PM To: Orion-Interest Subject: Re: clustering + ssl together ew, i was trying to run a single secure load balancer with it's own load-balancer.xml. loadbalancer did register the 2 orions i'd set up to appear in the cluster, but after being able to see them appear on the loadbalancer screen, i was still unable to access my web app. the browser just sat there with the little IE symbol spinning, but no joy. all orions and the loadbalancer had their own keystore setup using a test certificate generated from thawte.com loadbalancer = secure and on port 443 (on box1) orion1 = secure and on port 443 (on box2) orion2 = secure and on port 8080 (on box1) !! but only in some experiments. i also tried various other configurations of the loadbalancer and cluster machines having secure on/off, etc. and swapping the port numbers around, e.g. when loadbalancer and orion2 were both running, they were both secure=true but obviously only one can run on port 443 at one time, so i made orion2 run on port 8080 while secure=true was set. i also had a look at apache for how to setup SSL but it looks like you've got to compile the mod in yourself for win32 so i've given that a miss for the moment. greg. - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 2:48 AM Subject: RE: clustering + ssl together Here are the hickups in the plan so far...see below. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Monday, June 25, 2001 1:29 AM To: Orion-Interest Subject: RE: clustering + ssl together Greg, I am doing this now, so I will get back to the list when I am finished. This is my working plan: 1. there are two loadbalancers instances, one for http and one for https. These can be on the same machine or seperate machines. hickup At one level this works, but you have to set the minimumIsland/maximumIsland so that each respective loadbalancer picks up either the https island or the http island. However, https connections do not work. It could be because of this blurb in the load-balancer.xml description: secure - Whether or not to use SSL. The default is false. SSL is only used when using session (not IP) based balancing and the backend and the site is using SSL. If you specify the balancer to use SSL then the backend servers will not (the balancer converts to HTTP, ie contains the SSL layer). Note that this puts the strain of decoding the SSL on the balancer. I'm sorry, but does this say that we have the option of NOT using SSL for the balancer, but using it for the backend? Or if we use SSL for the balancer, SSL isn't used on the backend (and thus we have to strip all of the SSL configuration from the backend)? /hickup 2. the ports for your web-sites can be different from your loadbalancer(s) port. This allows you to have the loadbalancer and an orion instance on the same machine, for example. Or the ports can be the same, in which case the loadbalancer(s) has to be on a different machine. hickup Since web-sites are load-balanced (not applications), its important that each *web-site.xml which you use have its own island. This is done by setting the cluster-island attribute in the web-site tag. See above for reference to min/max island ids for the loadbalancer. The port bit seems to work. That is, the http web-site had a port of 10180, and the http loadbalancer listened on port 80. This was no problem. So if you want to have the loadbalancer and web-site on the same ip address, you will need to set the website port to something else so they don't conflict. /hickup 3. the same rules apply for the loadbalancer as orion for unix machines. You need to use some port forwarding, like ipchains, if you want to run the loadbalancer on a user account which is not the superuser. This applies also for the ssl port. (skip 3 if you are using m$ or don't care) 4. the ssl setup in the load-balancer.xml (see the ssl-config tag in the load-balancer.xml documentation) is the same as the secure-web-site.xml, but you will have to set the secure flag in the load-balancer tag. Obviously, this means you will need a keystore for the loadbalancer, and a keystore for the backend for total secure communication. I believe
RE: clustering + ssl together
Greg, I just logged this as bug 525. The ssl loadbalancer just won't accept connections with https://, but will accept connections with http://. Basic problem with the code. Its not us. Karl and Magnus need to fix this. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Tuesday, June 26, 2001 9:59 PM To: Orion-Interest Subject: RE: clustering + ssl together Greg, I just tried something which ALMOST worked. I tried the secure loadbalancer instance like this in the browser: http://localhost:443/mysecuresite/login. The secure loadbalancer showed a session id, and forwarded the request to the secure island! Of course the site didn't do anything, since it was looking for a handshake. It looks like the loadbalancer is just not doing its bit...it is refusing all connections which are secure. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Tuesday, June 26, 2001 3:00 PM To: Orion-Interest Subject: Re: clustering + ssl together ew, i was trying to run a single secure load balancer with it's own load-balancer.xml. loadbalancer did register the 2 orions i'd set up to appear in the cluster, but after being able to see them appear on the loadbalancer screen, i was still unable to access my web app. the browser just sat there with the little IE symbol spinning, but no joy. all orions and the loadbalancer had their own keystore setup using a test certificate generated from thawte.com loadbalancer = secure and on port 443 (on box1) orion1 = secure and on port 443 (on box2) orion2 = secure and on port 8080 (on box1) !! but only in some experiments. i also tried various other configurations of the loadbalancer and cluster machines having secure on/off, etc. and swapping the port numbers around, e.g. when loadbalancer and orion2 were both running, they were both secure=true but obviously only one can run on port 443 at one time, so i made orion2 run on port 8080 while secure=true was set. i also had a look at apache for how to setup SSL but it looks like you've got to compile the mod in yourself for win32 so i've given that a miss for the moment. greg. - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 2:48 AM Subject: RE: clustering + ssl together Here are the hickups in the plan so far...see below. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Monday, June 25, 2001 1:29 AM To: Orion-Interest Subject: RE: clustering + ssl together Greg, I am doing this now, so I will get back to the list when I am finished. This is my working plan: 1. there are two loadbalancers instances, one for http and one for https. These can be on the same machine or seperate machines. hickup At one level this works, but you have to set the minimumIsland/maximumIsland so that each respective loadbalancer picks up either the https island or the http island. However, https connections do not work. It could be because of this blurb in the load-balancer.xml description: secure - Whether or not to use SSL. The default is false. SSL is only used when using session (not IP) based balancing and the backend and the site is using SSL. If you specify the balancer to use SSL then the backend servers will not (the balancer converts to HTTP, ie contains the SSL layer). Note that this puts the strain of decoding the SSL on the balancer. I'm sorry, but does this say that we have the option of NOT using SSL for the balancer, but using it for the backend? Or if we use SSL for the balancer, SSL isn't used on the backend (and thus we have to strip all of the SSL configuration from the backend)? /hickup 2. the ports for your web-sites can be different from your loadbalancer(s) port. This allows you to have the loadbalancer and an orion instance on the same machine, for example. Or the ports can be the same, in which case the loadbalancer(s) has to be on a different machine. hickup Since web-sites are load-balanced (not applications), its important that each *web-site.xml which you use have its own island. This is done by setting the cluster-island attribute in the web-site tag. See above for reference to min/max island ids for the loadbalancer. The port bit seems to work. That is, the http web-site had a port of 10180, and the http loadbalancer listened on port 80. This was no problem. So if you want to have the loadbalancer and web-site on the same ip address, you will need to set the website port to something else so they don't conflict. /hickup 3. the same rules apply for the loadbalancer as orion for unix machines. You need to use some port forwarding, like ipchains, if you want to run the loadbalancer on a user account which is not the superuser
RE: clustering + ssl together
Greg, I am doing this now, so I will get back to the list when I am finished. This is my working plan: 1. there are two loadbalancers instances, one for http and one for https. These can be on the same machine or seperate machines. 2. the ports for your web-sites can be different from your loadbalancer(s) port. This allows you to have the loadbalancer and an orion instance on the same machine, for example. Or the ports can be the same, in which case the loadbalancer(s) has to be on a different machine. 3. the same rules apply for the loadbalancer as orion for unix machines. You need to use some port forwarding, like ipchains, if you want to run the loadbalancer on a user account which is not the superuser. This applies also for the ssl port. (skip 3 if you are using m$ or don't care) 4. the ssl setup in the load-balancer.xml (see the ssl-config tag in the load-balancer.xml documentation) is the same as the secure-web-site.xml, but you will have to set the secure flag in the load-balancer tag. Obviously, this means you will need a keystore for the loadbalancer, and a keystore for the backend for total secure communication. I believe that the communication to the backend is transparant to the user, so you can self certify that connection, irregardless of what those guys at verisign say. 5. you can skip all of this and use apache for ssl (interesting, but slow). This is what oracle advises, because they can't figure out orion, or they have so much invested in the "apache/oracle" solution. I'm testing this now, as soon as I get through the hickups, I will let the list know. regards, the elephantwalker -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg MatthewsSent: Sunday, June 24, 2001 3:02 PMTo: Orion-InterestSubject: clustering + ssl together dear all, there has been a recent post on this but no solution posted. i've got some more info on the problem. can the developers of orion or anyone else let me know if anyone has successfully set up an ssl orion cluster? i can: - set up clustering - set up ssl ...but not both together. some clues. 1. on orionserver.com there is doco for load-balancer.xml that suggests loadbalancer.jar can be given SSL keystore information. does this mean that a clustered SSL setup requires loadbalancer to share the same keystore as each box in the cluster? 2. how do you set the web-site.xml for a clustered secure app. you can't have both the loadbalancer + your secure app both running on port 443 on the same box, so what do you do? i) run loadbalancer on another port? ii) run your app on another port? - the orion doco says that when your app needs to be made secure you should add a secure="true" attribute to the web-site element of the web-site.xml plus remove the port attribute. if someone has made this work i'd be grateful for any information, or if you couldn't be bothered explaining how to do it, just maybe forward me your server.xml, loadbalancer.xml, web-site.xml and i'll work it out from that. thanks. greg.
RE: clustering and class/jar visibility
try placing the jar file in the web app WEB-INF/lib directory. Remember when you deploy an application it has its own sandbox. Thats my best bet. it should be visible if it is in that directory though. Al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Conway Sent: Wednesday, June 13, 2001 10:38 AM To: Orion-Interest Subject: clustering and class/jar visibility we have a 'dev' instance on box 1...we can deploy a web app using the 'exploded directory structure', and put our sybase jdbc driver zip file in lib under j2ee/home...works great. we have a 'test' instance on box 2...with 2 instances of orion running in a load-balanced cluster. We set an auto-deploy directory in our server xml files pointing to a shared file space (afs). We than .ear up the web app we had in 'dev' and deploy...it looks like deployment worked, but the sybase jdbc drivers are not visible..I get class not found...even tho the jconnect40.zip file is in the same j2ee/home/lib directory as on 'dev'is there some catch to distributing web apps to a cluster that effects the visibility of .jar files placed in j2ee/home/lib? I saw some messages about starting orion with a classpath directive in the java command explicitly mapping jar files, such as is done when starting jserv manually...is this the 'gotcha' of this type of config? Any help appreciated... Regards, Mike Conway UNC-Chapel Hill
Re: clustering and key generation
jason, thankyou for yor responses. in the interests of keeping it simple, i've decided to try to lobby the rest of the team to go back to using db generated keys (i.e. identity columns in the case of ms sql server ) and throw out key our key generation code. we'll then have a single .ear that can be deployed on any box with minimal changes to 1 or 2 orion files to allow clustering, and the only single point of failure will then be the database, and not the box generating keys. cheers, greg. - Original Message - From: Jason Smith [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Sunday, June 10, 2001 2:36 AM Subject: RE: clustering and key generation Have you tried setting: ejb-module remote=true path=keygenerator / in your orion-application.xml on machines B,C, and D? The only place the KeyGenerator bean is really deployed is on A, so machine A's orion-application.xml will have remote=false. I am assuming you have already set up your rmi.xml, etc. correctly to support this kind of operation (as in the links I posted earlier). The only other thing I can think of right now is maybe try making a parent application which has the KeyGenerator bean and run children apps on the other machines. I haven't tried the parent/child app deployment, so you would have to check the archives to see if this is feasible. -jason
RE: clustering and key generation
Greg, I didn't really understand your problem. If you are using counter.jar to generate your keys, then the key is actually generated based upon the last key in the database, not the appserver, so clustering shouldn't be a problem. If there is an issue with transaction concurrency, you can always hack the ejb-jar.xml for counter.jar to keep control of the transactions. If you are using jdbc and a slsb (see Brett McGlauphlin's column on Flashline.com), again the database is keeping track of the keys generated, and not the appserver, so clustering shouldn't be a problem. If you are using a bean (not an ejb, just anyolbean) to generate your keys, then you've got a problem with clustering...forget about this approach, it will never work. We use counter.jar, and have had no problems with key generation in a clustered environment. Counter.jar is in the newsapp, and is freely available for anybody to use. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Sunday, June 10, 2001 3:19 PM To: Orion-Interest Subject: Re: clustering and key generation jason, thankyou for yor responses. in the interests of keeping it simple, i've decided to try to lobby the rest of the team to go back to using db generated keys (i.e. identity columns in the case of ms sql server ) and throw out key our key generation code. we'll then have a single .ear that can be deployed on any box with minimal changes to 1 or 2 orion files to allow clustering, and the only single point of failure will then be the database, and not the box generating keys. cheers, greg. - Original Message - From: Jason Smith [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Sunday, June 10, 2001 2:36 AM Subject: RE: clustering and key generation Have you tried setting: ejb-module remote=true path=keygenerator / in your orion-application.xml on machines B,C, and D? The only place the KeyGenerator bean is really deployed is on A, so machine A's orion-application.xml will have remote=false. I am assuming you have already set up your rmi.xml, etc. correctly to support this kind of operation (as in the links I posted earlier). The only other thing I can think of right now is maybe try making a parent application which has the KeyGenerator bean and run children apps on the other machines. I haven't tried the parent/child app deployment, so you would have to check the archives to see if this is feasible. -jason
Re: clustering and key generation
If I understand Greg's decision correctly, he made it to prevent a single point of failure on the Orion server instance serving the key generation with the counter.jar. That Orion server indeed is a single point of failure instance as only one server should serve the key generation locally. Of course, using the database as single point of failure is just a slight shift of focus, but those beasts are usually a bit more stable thus I think his decision probably improved the reliability of his system. Ate - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Monday, June 11, 2001 00:52 Subject: RE: clustering and key generation Greg, I didn't really understand your problem. If you are using counter.jar to generate your keys, then the key is actually generated based upon the last key in the database, not the appserver, so clustering shouldn't be a problem. If there is an issue with transaction concurrency, you can always hack the ejb-jar.xml for counter.jar to keep control of the transactions. If you are using jdbc and a slsb (see Brett McGlauphlin's column on Flashline.com), again the database is keeping track of the keys generated, and not the appserver, so clustering shouldn't be a problem. If you are using a bean (not an ejb, just anyolbean) to generate your keys, then you've got a problem with clustering...forget about this approach, it will never work. We use counter.jar, and have had no problems with key generation in a clustered environment. Counter.jar is in the newsapp, and is freely available for anybody to use. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Sunday, June 10, 2001 3:19 PM To: Orion-Interest Subject: Re: clustering and key generation jason, thankyou for yor responses. in the interests of keeping it simple, i've decided to try to lobby the rest of the team to go back to using db generated keys (i.e. identity columns in the case of ms sql server ) and throw out key our key generation code. we'll then have a single .ear that can be deployed on any box with minimal changes to 1 or 2 orion files to allow clustering, and the only single point of failure will then be the database, and not the box generating keys. cheers, greg. - Original Message - From: Jason Smith [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Sunday, June 10, 2001 2:36 AM Subject: RE: clustering and key generation Have you tried setting: ejb-module remote=true path=keygenerator / in your orion-application.xml on machines B,C, and D? The only place the KeyGenerator bean is really deployed is on A, so machine A's orion-application.xml will have remote=false. I am assuming you have already set up your rmi.xml, etc. correctly to support this kind of operation (as in the links I posted earlier). The only other thing I can think of right now is maybe try making a parent application which has the KeyGenerator bean and run children apps on the other machines. I haven't tried the parent/child app deployment, so you would have to check the archives to see if this is feasible. -jason
RE: clustering and key generation
We have several orion's running in clustering, each of them serving up keys from counter.jar, with no conflicts. Let me be clear, each orion instance uses its own local counter.jar ejb to generate a key, but the underlying data for the key generation comes from the database. The counter.jar is called directly from a slsb, which then passes the generated key to the entity bean create method. (We could have done this from within the entity bean, it just seemed a little faster from the slsb). The slsb method to create the entity bean is called from the web tier, a type II controller servlet. If one orion fails, then the other orion can take over, since the web tier is clustered as is the loadbalancer's job. We have tested this functionality, and it if we turn off one appserver, the other one takes over the controller session without a problem. You can directly use the database to create the keys from within the controller servlet or a bean instanced in the controller, but then you do not have any transaction control or any of those nice pooling things going on under the hood with the app server, and you will pay for this with a performance slowdown. Brett McGlauphlin's series of articles on Flashline.com clearly indicates the reasons for abstracting the key generation to the enterprise tier. I would suggest a good read of this. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ate Douma Sent: Sunday, June 10, 2001 6:05 PM To: Orion-Interest Subject: Re: clustering and key generation If I understand Greg's decision correctly, he made it to prevent a single point of failure on the Orion server instance serving the key generation with the counter.jar. That Orion server indeed is a single point of failure instance as only one server should serve the key generation locally. Of course, using the database as single point of failure is just a slight shift of focus, but those beasts are usually a bit more stable thus I think his decision probably improved the reliability of his system. Ate - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Monday, June 11, 2001 00:52 Subject: RE: clustering and key generation Greg, I didn't really understand your problem. If you are using counter.jar to generate your keys, then the key is actually generated based upon the last key in the database, not the appserver, so clustering shouldn't be a problem. If there is an issue with transaction concurrency, you can always hack the ejb-jar.xml for counter.jar to keep control of the transactions. If you are using jdbc and a slsb (see Brett McGlauphlin's column on Flashline.com), again the database is keeping track of the keys generated, and not the appserver, so clustering shouldn't be a problem. If you are using a bean (not an ejb, just anyolbean) to generate your keys, then you've got a problem with clustering...forget about this approach, it will never work. We use counter.jar, and have had no problems with key generation in a clustered environment. Counter.jar is in the newsapp, and is freely available for anybody to use. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Sunday, June 10, 2001 3:19 PM To: Orion-Interest Subject: Re: clustering and key generation jason, thankyou for yor responses. in the interests of keeping it simple, i've decided to try to lobby the rest of the team to go back to using db generated keys (i.e. identity columns in the case of ms sql server ) and throw out key our key generation code. we'll then have a single .ear that can be deployed on any box with minimal changes to 1 or 2 orion files to allow clustering, and the only single point of failure will then be the database, and not the box generating keys. cheers, greg. - Original Message - From: Jason Smith [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Sunday, June 10, 2001 2:36 AM Subject: RE: clustering and key generation Have you tried setting: ejb-module remote=true path=keygenerator / in your orion-application.xml on machines B,C, and D? The only place the KeyGenerator bean is really deployed is on A, so machine A's orion-application.xml will have remote=false. I am assuming you have already set up your rmi.xml, etc. correctly to support this kind of operation (as in the links I posted earlier). The only other thing I can think of right now is maybe try making a parent application which has the KeyGenerator bean and run children apps on the other machines. I haven't tried the parent/child app deployment, so you would have to check the archives to see if this is feasible. -jason
Re: clustering and key generation
i think elephantwalker's solution is probably better from a database independence point of view and understand now that counter works off the db. i think using identity's is probably ok also, but we'll have to do some OO stuff server side to abstract away the get the last identity used (MS SQL SERVER) from get the next value from the sequence (ORACLE). cheers, greg - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Monday, June 11, 2001 1:24 PM Subject: RE: clustering and key generation We have several orion's running in clustering, each of them serving up keys from counter.jar, with no conflicts. Let me be clear, each orion instance uses its own local counter.jar ejb to generate a key, but the underlying data for the key generation comes from the database. The counter.jar is called directly from a slsb, which then passes the generated key to the entity bean create method. (We could have done this from within the entity bean, it just seemed a little faster from the slsb). The slsb method to create the entity bean is called from the web tier, a type II controller servlet. If one orion fails, then the other orion can take over, since the web tier is clustered as is the loadbalancer's job. We have tested this functionality, and it if we turn off one appserver, the other one takes over the controller session without a problem. You can directly use the database to create the keys from within the controller servlet or a bean instanced in the controller, but then you do not have any transaction control or any of those nice pooling things going on under the hood with the app server, and you will pay for this with a performance slowdown. Brett McGlauphlin's series of articles on Flashline.com clearly indicates the reasons for abstracting the key generation to the enterprise tier. I would suggest a good read of this. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ate Douma Sent: Sunday, June 10, 2001 6:05 PM To: Orion-Interest Subject: Re: clustering and key generation If I understand Greg's decision correctly, he made it to prevent a single point of failure on the Orion server instance serving the key generation with the counter.jar. That Orion server indeed is a single point of failure instance as only one server should serve the key generation locally. Of course, using the database as single point of failure is just a slight shift of focus, but those beasts are usually a bit more stable thus I think his decision probably improved the reliability of his system. Ate - Original Message - From: elephantwalker [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Monday, June 11, 2001 00:52 Subject: RE: clustering and key generation Greg, I didn't really understand your problem. If you are using counter.jar to generate your keys, then the key is actually generated based upon the last key in the database, not the appserver, so clustering shouldn't be a problem. If there is an issue with transaction concurrency, you can always hack the ejb-jar.xml for counter.jar to keep control of the transactions. If you are using jdbc and a slsb (see Brett McGlauphlin's column on Flashline.com), again the database is keeping track of the keys generated, and not the appserver, so clustering shouldn't be a problem. If you are using a bean (not an ejb, just anyolbean) to generate your keys, then you've got a problem with clustering...forget about this approach, it will never work. We use counter.jar, and have had no problems with key generation in a clustered environment. Counter.jar is in the newsapp, and is freely available for anybody to use. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Sunday, June 10, 2001 3:19 PM To: Orion-Interest Subject: Re: clustering and key generation jason, thankyou for yor responses. in the interests of keeping it simple, i've decided to try to lobby the rest of the team to go back to using db generated keys (i.e. identity columns in the case of ms sql server ) and throw out key our key generation code. we'll then have a single .ear that can be deployed on any box with minimal changes to 1 or 2 orion files to allow clustering, and the only single point of failure will then be the database, and not the box generating keys. cheers, greg. - Original Message - From: Jason Smith [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Sunday, June 10, 2001 2:36 AM Subject: RE: clustering and key generation Have you tried setting: ejb-module remote=true path=keygenerator / in your orion-application.xml on machines B,C, and D? The only place the KeyGenerator bean
RE: clustering and key generation
Have you tried setting: ejb-module remote=true path=keygenerator / in your orion-application.xml on machines B,C, and D? The only place the KeyGenerator bean is really deployed is on A, so machine A's orion-application.xml will have remote=false. I am assuming you have already set up your rmi.xml, etc. correctly to support this kind of operation (as in the links I posted earlier). The only other thing I can think of right now is maybe try making a parent application which has the KeyGenerator bean and run children apps on the other machines. I haven't tried the parent/child app deployment, so you would have to check the archives to see if this is feasible. -jason
Re: clustering and key generation
hi, i had a read and i'm still stuck. my question specifically is about why the InitialContext i create for referencing a KeyGeneratorBean on another box doesn't work. machines A, B, C, and D each have the same app deployed, which has many beans. Each box should use it's own beans, except KeyGeneratorBean. I want to tell *all* boxes to use the KeyGeneratorBean on machine A. I do this by creating a new InitialContext that is used only when getting a home interface to KeyGeneratorBean, by calling the InitialContext( Hashtable) constructor, where Hashtable contains java.naming.factory.initial=com.evermind.server.rmi.RMIInitialContextFactory java.naming.security.principal=principal java.naming.security.credentials=credentials java.naming.provider.url=ormi://machineA/myApp this works when i run a standalone dos program to get a reference to KeyGeneratorBean on machineA, so why doesn't it work when the same code is run from inside an EJB on machineB? any help much appreciated, greg. - Original Message - From: Jason Smith [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Friday, June 08, 2001 2:04 PM Subject: RE: clustering and key generation These posts in the archive may help you (although they target Orion web server-Orion ejb server configuration instead of a cluster). http://www.mail-archive.com/orion-interest@orionserver.com/msg12704.html http://www.mail-archive.com/orion-interest@orionserver.com/msg11905.html -jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Thursday, June 07, 2001 10:19 PM To: Orion-Interest Subject: clustering and key generation dear all, if there any way to get all machines in a cluster to lookup a stateless session bean (KeyGeneratorBean) on *one* of the machines in the cluster only. i've given it a try but can't seem to find a way to get machine B to use machine A's KeyGeneratorBean, even though machine B builds a new InitialContext with the 4 environment parameters, e.g. principal/credentials/url/factory when doing a lookup for KeyBean. thanks, greg.
RE: clustering and key generation
These posts in the archive may help you (although they target Orion web server-Orion ejb server configuration instead of a cluster). http://www.mail-archive.com/orion-interest@orionserver.com/msg12704.html http://www.mail-archive.com/orion-interest@orionserver.com/msg11905.html -jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Matthews Sent: Thursday, June 07, 2001 10:19 PM To: Orion-Interest Subject: clustering and key generation dear all, if there any way to get all machines in a cluster to lookup a stateless session bean (KeyGeneratorBean) on *one* of the machines in the cluster only. i've given it a try but can't seem to find a way to get machine B to use machine A's KeyGeneratorBean, even though machine B builds a new InitialContext with the 4 environment parameters, e.g. principal/credentials/url/factory when doing a lookup for KeyBean. thanks, greg.
RE: CLUSTERING PROBLEM FINALLY SOLVED!! web-module
Hi Mike, I don't doubt you when you say you've had problems, but plenty of others (including myself) have managed to cluster Orion easily in the past (okay - I don't include the loadbalancer.jar in that statement about it being easy- whenwe were using it, it was buggy as hell, and quite probably still is). Without looking up the documentation to try and confirm that the bits you need aren't there, myguess is that perhaps something has changed in a recent version of Orion and the documentation hasn't been updated to correspond. All the best, Tony. -Original Message-From: Mike N. Christoff [mailto:[EMAIL PROTECTED]]Sent: 10 May 2001 18:48To: Orion-InterestSubject: CLUSTERING PROBLEM FINALLY SOLVED!! web-module With the help of Jeff Hubbach, we were finally able to get orion http clustering to work for all our applications, not just the default-web-app. So what was the problem?? A) Although the orion docs say otherwise, you MUST manually add the cluster-config / tag to the orion/application-deployments/myapp/myapp-web/orion-web.xml file. B)B was the main problem for us, since even before we got it working, we had manually added the cluster-config tag. What we were missing was the following tag in orion/config/application.xml: web-module id="myapp" path="../applications/myapp/" / None of us here have EVER read ANYTHING in the orion docs that say you must have an entry for your web app in config/application.xml. Where is config/application.xml mentioned in the orion primer??? Where is it mentioned in application-creation-howto.html??? It isn't!! I find the fact that this isn't mentioned in the docs cited above OR!! the docs for http clustering to be a horrible oversight on the part of the orion doc writers and orion authors. The fact we had to spend overs 2 weeks trying to solve thisproblem is absolutely horrible. They REALLY REALLY REALLY need to fully document the server PROPERLY!! before they addONE new feature. Anyways, thanks to everyone who helped us out, it was greatly appreciated. Michael N. ChristoffDeveloper, Eldan Software, Ltd.Toronto, Canadawww.eldan.com
Re: CLUSTERING PROBLEM FINALLY SOLVED!! web-module
SV: CLUSTERING PROBLEM FINALLY SOLVED!! web-moduleprevious 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
RE: Clustering and Multicasting
are you connecting everything to the same switch (hub)??? multicasting in a LAN is usually done by the switches, so hooking into a different hub may be problematic with some switches HTH JP -Original Message- From: Jesse Schoch [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 7:32 PM To: Orion-Interest Subject: Clustering and Multicasting I have installed a 3 node orion cluster(2 on windows2k and 1 on linux) and have it working just dandy, the replication seems to work and so does the loadbalancer but... I also have a bsdi box, and recently upgraded to the 4.2 version which has a JDK and JVM on which orion runs fine, but when I try to put into the cluster orion will not start and complains that it can't bind to the multicast address. any ideas why this is happening?
Re: Clustering and Multicasting
they are connected to a hub - Original Message - From: "Juan Lorandi (Chile)" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Saturday, March 03, 2001 1:59 PM Subject: RE: Clustering and Multicasting are you connecting everything to the same switch (hub)??? multicasting in a LAN is usually done by the switches, so hooking into a different hub may be problematic with some switches HTH JP -Original Message- From: Jesse Schoch [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 7:32 PM To: Orion-Interest Subject: Clustering and Multicasting I have installed a 3 node orion cluster(2 on windows2k and 1 on linux) and have it working just dandy, the replication seems to work and so does the loadbalancer but... I also have a bsdi box, and recently upgraded to the 4.2 version which has a JDK and JVM on which orion runs fine, but when I try to put into the cluster orion will not start and complains that it can't bind to the multicast address. any ideas why this is happening?
RE: Clustering Advice, Software or Hardware
Hi there, First, you definitely want to use the application specific clustering, with a load-balancer feeding to two or more, per island. If your not familiar with Orion clustering, your in for a nice surprise..its VERY easy to do. Orion even comes with its own software load-balancer that is "Orion aware" and as you add more Orion app servers, they automagically appear on the server that the Orion load-balancer is running on. You even see all incoming requests, what server they went to, when a computer is added or taken away, etc. There is a nice doc on the orion site, I forget the URL, that explains a good deal on how to easily set up clustering. I have tried it and it works. The thing to know, however is that HttpSession data (the stuff that the "state" of a client is stored in via a session), needs to be failed over, so that if one server goes down, they are still connected via the session data. If the HttpSession objects were not failed over, when a server went down, everything in the clients "cart" (if say you were building a cart system), would be gone. On our site, people have to log in. We store an object in the HttpSession session for each client that indicates if they are logged in or not. If the server they were on went down, they would no longer be logged in, even if a load-balancer was in place and fed them to another server. The idea behind Session fail-over is that you set up an island of web servers..and in that island all HttpSession data is copied to each of the servers. Therefore, if I am a new client and hit your ip (a load-balancer for example), my request is sent to any one of x number of servers in a specific island (a cluster). My HttpSession is created and its "replicated" to all the servers in the island. Therefore, if you have 3 machines, each machine gets not only its data, but the data of the other two servers..so memory requirements go up a bit on each machine. With Orion, because of the way it clusters, I would put 3 servers per island, with two islands, for "minimum optimum fail-over". You don't have to put fast machines..a single $1200 PIII or AMD Athlon based pc with 500MHz cpus are fine. I ran a simple "login" load-test with 25 users on my PIII650 workstation with Orion, with the Interbase database server running on it as well, and I was able to achieve 4milliion pages per day. Ofcourse..it helps that it is on my local box, but even if the database was on a different machine, I would achieve similar results. And this with only 2 database connections in the pool! Imagine the performance you can get from a 3-server cluster of 500Mhz PCs with 1GB of memory each. Anyways, you can cluster with 2 servers per island, but I recommend 3 simply because if one goes down, you still have a cluster. I wouldn't go with 4..instead I would set up two islands, each with 2 computers if you can only use 4 servers. You can easily add a machine to the island too. The reason being..the more servers you have in an island, the more memory each will need to handle the HttpSession objects of the other servers in the island. Therefore, I think 3 is perfect, each with 1GB (or more) of memory. These days, you can buy nice Dell servers for about $4K each with 900Mhz cpus, 1GB memory, Ultra SCSI 160 hds, etc. Hope that helps. Feel free to ask questions.. -Original Message- From: Neal Kaiser [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 25, 2000 2:04 PM To: Orion-Interest Subject: Clustering Advice, Software or Hardware We are soon going to develop a J2EE app using Orion and I want it to have 2 webservers for failsafe and load balancing. In the past I've used load balancing routers, like the Web Server Director. Has anyone had good experience with clustering in a production environment? What are the pros and cons of hardware vs software clustering? Thanks, Neal
Re: Clustering and load balancing Howto
Hi, Its already out heh..I gotta go get it. Where ideally should loadbalancer.jar be executed? Obviously if it is running on one of the machines in the cluster it isn't so good.. sort of defeats the fail-safe purposes... So should it have it's own machine? Or am I just missing something. From what Magnus told me ( I think it was he), it is ok to run it on the same server, but as you said, it defeats the purpose. Ideally, you would run it on its own box, and have it communicate on the same port/ip multi-cast as the two or more orion servers for load-balancing. I have a question on this matter. What if I want one load-balancer feeding multiple islands? Can this program load-balance properly between multiple Orion islands? I recall Karl teaching me (and others on the list) about how Orion can work as mutliple islands. The reason this is helpful is that if you have 10 servers on one island, each HttpSession of each server is replicated to all 10 servers. First, this can take a little more time to send all the objects of each servers HttpSession to the other 9 servers for replication. Second, the memory of each server would need to be able to handle the number of objects for all 10 HttpSessions. As Karl pointed out, using an island with say, 2 or 3 servers, but having multiple islands, will reduce the memory footprint needed, as well as increase performance since each island only replicates the HttpSession data within the servers of its island. So, being that this load-balancer program is Orion aware, is it possible to set up multiple islands and does it distribute the load evenly through each island, and each server in each island? Excellent! BUT. when I start up the dead server again... it gets detected by the loadbalancer... starts receiving updates from the other server... so I kill of Server #2 it dies... and the counter returns to 1 even though the counter value DID get passed (listed in the debug messages)... for some reason it creates a new session. Any ideas here? That worries me. I hope this is just a bug or something. In fact after the first successful fail-over ... I can't get it to do it again without stopping the loadbalancer... and then both servers... then starting the load balancer... then both the servers again. It seems to only work once... then not anymore... even though it LOOKS like it should work. Any help is greatly appreciated! I am using Orion 1.3.3 since that's what the autoupdate gave me... the HOWTO DOES say to use 1.3.5+ but I don't know where that is. Really? I thought in 1.2.9 the load-balancer was functional. I haven't tried it yet, but I was told 1.2.9 is a stable release, and that is what I intend on doing production with. OrionTeam...is 1.3.5+ a stable release?
Re: Clustering problems.
Thursday, September 07, 2000, 9:29:42 PM, you wrote: Hi all. I am having some trouble getting clustering working on a fairly simple setup. I am hoping someone can give me some hints as to what I am doing wrong. I have two machines each running Orion 1.2.9 with JDK 1.3.0RC on Solaris. One is Intel and the other is Sparc. Both of these machines have two ethernet interfaces, one for the public Internet and one for the private network (which is [Clustering Woes Snipped] Also, do I really need to add cluster-config / to my orion-web.xml files? Isn't there a place I can say "make all apps clusterable by default"? I currently have about 20 apps installed and this makes it kinda annoying :) Anyway, thanks for the help. I have been beating my head against this for a few days. I know exactly where you are coming from. Myself and a few others are exactly at the stage you are right now... the banging head on wall stage... and are desperate for some documentation on clustering (and other areas) from Orion. We've been promised docs a few times... First a document would be out soon... then it would take longer but a 'condensed' clustering document would be out in a few days (almost 2 weeks ago now)... now the 'condensed' document is forgotten... and the original promised doc is delayed again to include load-balancing info... who knows when we will actually see something. Lack of documentation is killing my opinion of this company. Not complete lack. Just lack. And it isn't like it isn't a known problem. Almost every review of Orion I have seen points out this glaring fact. And this mailing list is seething with people patiently waiting for something that should be already written. How about the whole orion team just STOPS coding for a week... (I don't care about 1.2.10!!!)... and fill in the gaps in the documentation. I think it would be a very productive move. Yes, I know the "price is right"... but come *ON*... inexpensive means nothing if the features you need are available but undocumented. Dylan Parker
Re: Clustering and load balancing Howto
First question! Oo! Oo! Anyways, you say: -- If you want to add clustering for the whole website (for all web-applications), edit the orion-web.xml of the default web-application (NOTE: it will not be applied to all web-applications previous to Orion 1.3.6). This file is normally located in orion/application-deployments/default/defaultWebApp/orion-web.xml. -- Do you perhaps mean global-web-application.xml in orion/config? My set up doesn't even reference defaultWebApp because I have no use for it. Or am I missing something here? Thanks! P.S. Great doc by the way. Figured most of this out today while interrogating Magnus, but it's good to have it all in one place! - Original Message - From: "Karl Avedal" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Friday, September 08, 2000 3:57 PM Subject: Clustering and load balancing Howto Hello, Finally, the first version of the "Orion Clustering and Load Distribution" document is up. You can read it at http://www.orionserver.com/howtos/orion-clustering.html We will not link it from the site until tomorrow since we want to do some more testing on it before we have everyone waste their time trying it, just to run into a simple stumbling block. However, you are free to read it and try it now, but no guarantees on it being 100 % correct until tomorrow (ok, 100% can be hard to guarantee at any time...). Suggestions for improvements are happily accepted to [EMAIL PROTECTED] Regards, Karl Avedal
Re: Clustering problems.
Hello Dylan, (... about lack of documentation) And it isn't like it isn't a known problem. Almost every review of Orion I have seen points out this glaring fact. And this mailing list is seething with people patiently waiting for something that should be already written. Absolutely, documentation is our biggest and most important task (as I've pointed out many times on this list) How about the whole orion team just STOPS coding for a week... (I don't care about 1.2.10!!!)... and fill in the gaps in the documentation. I think it would be a very productive move. Well, even though you might not care about getting new versions every day (of course noone cares for every update) there are many people who are running Orion on their production sites serving thousands of people, or are in the process of going live, and if they find a bug we try to help them with it. We get an enormous amount of reports and requests for enhancements and new features and if we stopped developing for a whole week we would get far behind on helping our customers, and believe me, a week of documentation isn't enough to improve documentation in that many areas that it makes it worth to stop responding to everyone. All I can say is that we are working on documentation (when we're not working on explaining that we are working on documentation ;) ) and that we are aware of the amounts of documentation that you need to work with a product of this complexity. A big problem is also that things are moving so fast. We make something available as a preview (like EJB 2.0) and of course people want documentation and examples the day after (understandable), but it's a tough task to work that fast. Yes, I know the "price is right"... but come *ON*... inexpensive means nothing if the features you need are available but undocumented. Of course. We are working like this: When we have a new feature we start out by giving a little documentation on it so that everything is at least documented (although very briefly) and then we follow up with more complete documentation, but those usually take a fair bit longer to produce. Examples are SSL, Clustering and user management that have had very sparse documentation so far (but Clustering was improved today), and we are working on providing complete tutorials and how-to's about these subjects. We understand that you need complete and good documentation to work with our product, and if you can not live with the state of the current documentation, you should of course look at other products that fit your needs better. We are doing our best to make sure that Orion is the best J2EE server and we certainly are working on making sure that everyone can use it, and I think we've taken big steps in this direction lately, with a few noticable additions like the Bugzilla, the improvements to the Changelog and the new documentation that's starting to pop up, like the clustering doc, The start to the GUI tools tutorial, the start to the Filter tutorial, The CMP Primer (not on the site yet, but available at www.jollem.com/orion-cmp-primer/ (yeah, Ernst is writing some documentation for Orion "officially" now)) and a few other docs that are in the later stages of production. Eventually we will get there. Regards, Karl Avedal
Re: Clustering and load balancing Howto
Second Question! Woo! Hoo! =) Hello, karl, Excellent! Awesome! Great! I burned through your document and have a functional setup. A few questions : Where ideally should loadbalancer.jar be executed? Obviously if it is running on one of the machines in the cluster it isn't so good.. sort of defeats the fail-safe purposes... So should it have it's own machine? Or am I just missing something. The current setup I tried is this : 2 machines in the cluster. A third machine has a mapped drive to one of the machines and is the loadbalancer. I start the loadbalancer in debug mode. It says it is initialized. I start the two backend servers in debug mode (as outlined in the HOWTO)... they start yakking away apparently over multicast... things like : = HTTP-clustering service started... Created cluster-listener for 230.0.0.1/230.0.0.1:9128 as 1249865300... Adding clustering service 'defaultWebApp'... HTTP-Clustering service initializing... Received cluster-message: defaultWebApp... HTTP-Clustering sent "I want sessions" request... Received cluster-message: defaultWebApp... Receiving HTTP-cluster send-sessions goahead from 597745668... Received cluster-message: defaultWebApp... Receiving HTTP-cluster sessions... Received cluster-message: defaultWebApp... Receiving HTTP-cluster send-sessions request... Received cluster-message: defaultWebApp... Receiving HTTP-cluster session value update... Created cluster-listener for 230.0.0.2/230.0.0.2:27512 as 1... Adding clustering service 'islands'... Orion/1.3.3 initialized = The second "cluster-listener" is created when the LoadBalancer 'discovers' that machine. Is it alright that two listeners are created? ALright... then both machines are up... I go to the servlet/SessionServlet and LoadBalancer binds the session and chooses a server for me.. so far so good... I get the counter up a bit (and watch the machine send the other counter updates)... then I kill that server (kill the process through Task Manager).. I click refresh in the browser and lo and behold... the LoadBalancer re-routes the connection and I'm now on the other machine with the correct data. Excellent! BUT. when I start up the dead server again... it gets detected by the loadbalancer... starts receiving updates from the other server... so I kill of Server #2 it dies... and the counter returns to 1 even though the counter value DID get passed (listed in the debug messages)... for some reason it creates a new session. Any ideas here? In fact after the first successful fail-over ... I can't get it to do it again without stopping the loadbalancer... and then both servers... then starting the load balancer... then both the servers again. It seems to only work once... then not anymore... even though it LOOKS like it should work. Any help is greatly appreciated! I am using Orion 1.3.3 since that's what the autoupdate gave me... the HOWTO DOES say to use 1.3.5+ but I don't know where that is. Thanks, Dylan Hello, Finally, the first version of the "Orion Clustering and Load Distribution" document is up. You can read it at http://www.orionserver.com/howtos/orion-clustering.html We will not link it from the site until tomorrow since we want to do some more testing on it before we have everyone waste their time trying it, just to run into a simple stumbling block. However, you are free to read it and try it now, but no guarantees on it being 100 % correct until tomorrow (ok, 100% can be hard to guarantee at any time...). Suggestions for improvements are happily accepted to [EMAIL PROTECTED] Regards, Karl Avedal
RE: Clustering problems.
Come on guys, give the team a break. I too am waiting patiently for docs, but let me tell you all something (I am sure many of you know this), while Orion may not be as robust as WebLogic, WebSphere and some others, I have thus far not seen any app server as complete (hell..over complete if you include ejb 2.0 and servlet 2.3 pre-implementation), as Orion. I have not been able to touch the ease of setting up Orion (with a little help sometimes) compared to WebLogic, OAS, WebSphere, IAS and others. I have not seen the speed from any app server, let alone the full J2EE spec implemented in any app server out there. Nor have I seen any app server as affordable that can do 1/2 as much as Orion. Orion is one of the only app servers that is free to user for everything except production, and it doesn't lock you out if you don't have a concurrent license servlet or some other security lock that prevents full use of it. I think for all of you complaining about the docs taking so long..you need to understand that these guys have done an amazing job with the product already, and are on top of bugs, latest specs, and more. They are also a fairly new company and have already beat the competition by a large margin as much as I can tell. Sure..this may be my opinion, but I have thus far only seen one person stop using it, while most have continued to complain...but still use it. I started a little documentation initiative a few weeks ago and got no responses back (ok..maybe one from the guy that runs the orionsupport.com site). I don't have much time either, but for what the Orion team gives you, how about helping out a little. If you have problems, ask, someone will most likely help you out..then try writing up a little doc on it. Maybe with all of us contributing we can help them along. Who knows..if you contribute maybe you'll get a free license or two to use for your own use. :) Go Orion! P.S. Can I get an X-Large t-shirt...that medium makes me look like I am trying to show off what muscles I pretend to have. ;) -Original Message- From: Karl Avedal [mailto:[EMAIL PROTECTED]] Sent: Friday, September 08, 2000 4:31 PM To: Orion-Interest Subject: Re: Clustering problems. Hello Dylan, (... about lack of documentation) And it isn't like it isn't a known problem. Almost every review of Orion I have seen points out this glaring fact. And this mailing list is seething with people patiently waiting for something that should be already written. Absolutely, documentation is our biggest and most important task (as I've pointed out many times on this list) How about the whole orion team just STOPS coding for a week... (I don't care about 1.2.10!!!)... and fill in the gaps in the documentation. I think it would be a very productive move. Well, even though you might not care about getting new versions every day (of course noone cares for every update) there are many people who are running Orion on their production sites serving thousands of people, or are in the process of going live, and if they find a bug we try to help them with it. We get an enormous amount of reports and requests for enhancements and new features and if we stopped developing for a whole week we would get far behind on helping our customers, and believe me, a week of documentation isn't enough to improve documentation in that many areas that it makes it worth to stop responding to everyone. All I can say is that we are working on documentation (when we're not working on explaining that we are working on documentation ;) ) and that we are aware of the amounts of documentation that you need to work with a product of this complexity. A big problem is also that things are moving so fast. We make something available as a preview (like EJB 2.0) and of course people want documentation and examples the day after (understandable), but it's a tough task to work that fast. Yes, I know the "price is right"... but come *ON*... inexpensive means nothing if the features you need are available but undocumented. Of course. We are working like this: When we have a new feature we start out by giving a little documentation on it so that everything is at least documented (although very briefly) and then we follow up with more complete documentation, but those usually take a fair bit longer to produce. Examples are SSL, Clustering and user management that have had very sparse documentation so far (but Clustering was improved today), and we are working on providing complete tutorials and how-to's about these subjects. We understand that you need complete and good documentation to work with our product, and if you can not live with the state of the current documentation, you should of course look at other products that fit your needs better. We are doing our best to make sure that Orion is the best J2EE server and we certainly are working on making sure that everyone can use
RE: clustering/load balancing
Yes. Its very easy. Look in the /docs folder for clustering info, but basically you do this. IN /config/server.xml, add the line cluster id="X" / where X is a unique number on EACH server of the cluster. Thus, each server has Orion running on it, X will be different on each of these copies of Orion. Then, in the WEB-INF dir of a web-app, you'll see an orion-web.xml file, add cluster-config / to that file. your set! The one thing I haven't been able to test yet is if I shut down one clustered server, then restart it, if the session data gets replicated to it again automatically. It should, but I have yet to see if that works.
Re: clustering/load balancing
Kevin, I thought it was in interesting question as well. Team Orion, how bout it? Mike snip/ The one thing I haven't been able to test yet is if I shut down one clustered server, then restart it, if the session data gets replicated to it again automatically. It should, but I have yet to see if that works.
RE: clustering/load balancing
Heh..yeah. I have clustered two servers. When I hit one IP to one of the servers, the session objects show up in both. However, I did shut down on server, then restart it, and the session data no longer shows up on that server. Even though I am not using a load-balancer, I would assume that as soon as the server starts up, it gets in the loop of that multi-cast thing that gets sent out. I also am not sure, but I thought that each server broadcasts every so often, like every 15 seconds or something (is this configurable?). So, if that is the case, when a new server starts up (whether its an addition to the farm, or a server that died and was restarted), it should be picked up by other server(s) on the farm (island as Karl called it) and then get session data replicated to it automatically. I would think this should work even without using a load-balancer, but I could be wrong. I haven't tried the round-robing DNS approach, so I am not sure if this is a bug with Orion, it doesn't support it, or it requires a load-balancer to properly work. As Mike said..how about it Orion Team? I know I am still waiting for a document Karl said would be done last week. Haven't checked the site myself yet but I assume by the questions still coming, the document isn't done yet? Thanks. -Original Message-From: Mike Sick [mailto:[EMAIL PROTECTED]]Sent: Wednesday, September 06, 2000 11:50 AMTo: Orion-InterestSubject: Re: clustering/load balancing Kevin, I thought it was in interesting question as well. Team Orion, how bout it? Mike snip/ The one thing I haven't been able to test yet is if I shut down one clustered server, then restart it, if the session data gets replicated to it again automatically. It should, but I have yet to see if that works.
RE: Clustering in Orion
Title: RE: Clustering in Orion I'm somewhat confused here My WEB-INF directory has a web.xml file in it. The docs say that to cluster it, it should have distributable / in it. Now, what's the difference between web.xml and orion-web.xml? Which should my webapp have in its WEB-INF directory? In fact, I've noticed the same kind of difference with applications, with orion-application and application. the non orion- versions of the files are documented, while I can't seem to find docs for the orion- ones... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Duffey Sent: Thursday, August 17, 2000 6:16 PM To: Orion-Interest Subject: Re: Clustering in Orion I have clustered Orion, but there is alot I don't know about it. I have learned that Orion does session replication to every server in the cluster farm. I have not been able to test it with a load-balancer yet. Anyone happen to know of a free software load-balancer that can be used to test multiple servers with? Clustering with Orion is easy. You just add a cluster id=x / to server.xml on each server in the Orion/config dir. x is equal to a unique number on each server. then you add a cluster-config / to each orion-web.xml in the WEB-INF dir of a web app. That should cluster it. There are a number of issues I am not sure of however. If you run orion with the -console2 option, it brings up a SWING based admin console, and you can open the http tree and see the web-apps running, then look at sessions in each of those apps. When I cluster two servers, and hit one, the session data appears in both servers. However, on the server that the session was not created on, the values of the objects in the session are not available. This confuses me because I figured if I hit the other server that has been replicated to, and passed along the session ID (jsessionid=xxx), that it would automatically make that session available to me. However, one of our engineers mentioned that a session is stored via the ip address being hit. Thus, even though the session data is saved on two servers, trying to access the same session from two different ip addresses won't work. My only dilema here is..if a server goes down (say the one the session data was created on), so only one is left, does that automatically take over? I can't get this to work because I don't have a load balancer. I assume using a load-balancer is easy enough and this would work. Anyone from the Orion team care to respond..that would be great if you could explain how this is done. Thanks. - Original Message - From: Joseph B. Ottinger [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Cc: Orion-Interest [EMAIL PROTECTED] Sent: Thursday, August 17, 2000 9:55 AM Subject: Re: Clustering in Orion If I had any information about it, sure. I only have one machine; clustering isn't really an option for me. On Thu, 17 Aug 2000, Pedro Garcia Lopez wrote: Hello Joseph, Congratulation for your interesting site about Orion. My question is about clustering ? Do you plan to include some help in this issue ? Regards, Pedro --- Joseph B. Ottinger [EMAIL PROTECTED] http://cupid.suninternet.com/~joeo HOMES.COM Developer
RE: Clustering in Orion
Title: RE: Clustering in Orion There are docs in the /docs folder on orion-web and orion-application. You brought up a point though that I am not aware of...I have to manually put in the cluster-config / in orion-web.xml. Maybe by putting in distributable / in web.xml, Orion automatically puts in the cluster-config / into orion-web.xml. orion-web.xml is created by Orion when the web-app is deployed. I know you generally put in the cluster stuff in server.xml, and since I don't change anything in the orion-web.xml..i just use the default, I am now not sure if I am supposed to do that manually or not. If I delete it, Oroin regenerates another orion-web.xml next time i start it..but it doesn't put in the cluser-config / setting again. Also, don't you have to do some special programming when using the distributable / in web.xml? Any documentation on what it is you have to do when using this? Thanks. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hani SuleimanSent: Friday, August 18, 2000 8:53 AMTo: Orion-InterestSubject: RE: Clustering in Orion I'm somewhat confused here My WEB-INF directory has a web.xml file in it. The docs say that to cluster it, it should have distributable / in it. Now, what's the difference between web.xml and orion-web.xml? Which should my webapp have in its WEB-INF directory? In fact, I've noticed the same kind of difference with applications, with orion-application and application. the non orion- versions of the files are documented, while I can't seem to find docs for the orion- ones... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Duffey Sent: Thursday, August 17, 2000 6:16 PM To: Orion-Interest Subject: Re: Clustering in Orion I have clustered Orion, but there is alot I don't know about it. I have learned that Orion does session replication to every server in the cluster farm. I have not been able to test it with a load-balancer yet. Anyone happen to know of a "free" software load-balancer that can be used to test multiple servers with? Clustering with Orion is easy. You just add a cluster id="x" / to server.xml on each server in the Orion/config dir. x is equal to a unique number on each server. then you add a cluster-config / to each orion-web.xml in the WEB-INF dir of a web app. That should cluster it. There are a number of issues I am not sure of however. If you run orion with the -console2 option, it brings up a SWING based admin console, and you can open the http tree and see the web-apps running, then look at sessions in each of those apps. When I cluster two servers, and hit one, the session data appears in both servers. However, on the server that the session was not created on, the values of the objects in the session are not available. This confuses me because I figured if I hit the other server that has been replicated to, and passed along the session ID (jsessionid=xxx), that it would automatically make that session available to me. However, one of our engineers mentioned that a session is stored via the ip address being hit. Thus, even though the session data is saved on two servers, trying to access the same session from two different ip addresses won't work. My only dilema here is..if a server goes down (say the one the session data was created on), so only one is left, does that automatically take over? I can't get this to work because I don't have a load balancer. I assume using a load-balancer is easy enough and this would work. Anyone from the Orion team care to respond..that would be great if you could explain how this is done. Thanks. - Original Message - From: "Joseph B. Ottinger" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Cc: "Orion-Interest" [EMAIL PROTECTED] Sent: Thursday, August 17, 2000 9:55 AM Subject: Re: Clustering in Orion If I had any information about it, sure. I only have one machine; clustering isn't really an option for me. On Thu, 17 Aug 2000, Pedro Garcia Lopez wrote: Hello Joseph, Congratulation for your interesting site about Orion.My question is about clustering ? Do you plan to include some help in this issue ? Regards, Pedro --- Joseph B. Ottinger [EMAIL PROTECTED] http://cupid.suninternet.com/~joeo HOMES.COM Developer
RE: Clustering in Orion
That is a good way to test without a load-balancer. Thanks. However, the other dilema I have..and maybe you can check this in the short-term with an email or post here, but when you shut down one server, then restart it, does the session data in the other running server get replicated back to the newly added (or restarted) server? If so..how long does it take, does it require any special settings, etc? I ask because when I restarted my server, Orion started fine, but even after clicking around the site, I only see the contents of the server I am hitting changing, and I don't see any new sessions created on the newly started server. I am concerned that if one server goes down and then then restarts, then the other one went down, the sessions end up not getting replicated to save them. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Joel Shellman Sent: Thursday, August 17, 2000 5:21 PM To: Orion-Interest Subject: Re: Clustering in Orion Quick and dirty "load balancing" is round robin DNS. I just did a quick test the other day and set up two machines with our app. Hit the URL once and logged in (keeps object in session). Killed the app on one machine and hit reload. I was still logged in on the other machine. I got some errors as Netscape didn't choose to look at the other IP (in RR DNS you specify multiple IPs for a single domain name) right off. But it did show that session failover worked. -- Joel Shellman Chief Software Architect The virally-driven B2B marketplace for outsourcing projects http://www.ants.com/90589781 Kevin Duffey wrote: I have clustered Orion, but there is alot I don't know about it. I have learned that Orion does session replication to every server in the cluster farm. I have not been able to test it with a load-balancer yet. Anyone happen to know of a "free" software load-balancer that can be used to test multiple servers with? Clustering with Orion is easy. You just add a cluster id="x" / to server.xml on each server in the Orion/config dir. x is equal to a unique number on each server. then you add a cluster-config / to each orion-web.xml in the WEB-INF dir of a web app. That should cluster it. There are a number of issues I am not sure of however. If you run orion with the -console2 option, it brings up a SWING based admin console, and you can open the http tree and see the web-apps running, then look at sessions in each of those apps. When I cluster two servers, and hit one, the session data appears in both servers. However, on the server that the session was not created on, the values of the objects in the session are not available. This confuses me because I figured if I hit the other server that has been replicated to, and passed along the session ID (jsessionid=xxx), that it would automatically make that session available to me. However, one of our engineers mentioned that a session is stored via the ip address being hit. Thus, even though the session data is saved on two servers, trying to access the same session from two different ip addresses won't work. My only dilema here is..if a server goes down (say the one the session data was created on), so only one is left, does that automatically take over? I can't get this to work because I don't have a load balancer. I assume using a load-balancer is easy enough and this would work. Anyone from the Orion team care to respond..that would be great if you could explain how this is done.
Re: Clustering in Orion
If I had any information about it, sure. I only have one machine; clustering isn't really an option for me. On Thu, 17 Aug 2000, Pedro Garcia Lopez wrote: Hello Joseph, Congratulation for your interesting site about Orion. My question is about clustering ? Do you plan to include some help in this issue ? Regards, Pedro --- Joseph B. Ottinger [EMAIL PROTECTED] http://cupid.suninternet.com/~joeo HOMES.COM Developer
Re: Clustering in Orion
I have clustered Orion, but there is alot I don't know about it. I have learned that Orion does session replication to every server in the cluster farm. I have not been able to test it with a load-balancer yet. Anyone happen to know of a "free" software load-balancer that can be used to test multiple servers with? Clustering with Orion is easy. You just add a cluster id="x" / to server.xml on each server in the Orion/config dir. x is equal to a unique number on each server. then you add a cluster-config / to each orion-web.xml in the WEB-INF dir of a web app. That should cluster it. There are a number of issues I am not sure of however. If you run orion with the -console2 option, it brings up a SWING based admin console, and you can open the http tree and see the web-apps running, then look at sessions in each of those apps. When I cluster two servers, and hit one, the session data appears in both servers. However, on the server that the session was not created on, the values of the objects in the session are not available. This confuses me because I figured if I hit the other server that has been replicated to, and passed along the session ID (jsessionid=xxx), that it would automatically make that session available to me. However, one of our engineers mentioned that a session is stored via the ip address being hit. Thus, even though the session data is saved on two servers, trying to access the same session from two different ip addresses won't work. My only dilema here is..if a server goes down (say the one the session data was created on), so only one is left, does that automatically take over? I can't get this to work because I don't have a load balancer. I assume using a load-balancer is easy enough and this would work. Anyone from the Orion team care to respond..that would be great if you could explain how this is done. Thanks. - Original Message - From: "Joseph B. Ottinger" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Cc: "Orion-Interest" [EMAIL PROTECTED] Sent: Thursday, August 17, 2000 9:55 AM Subject: Re: Clustering in Orion If I had any information about it, sure. I only have one machine; clustering isn't really an option for me. On Thu, 17 Aug 2000, Pedro Garcia Lopez wrote: Hello Joseph, Congratulation for your interesting site about Orion. My question is about clustering ? Do you plan to include some help in this issue ? Regards, Pedro --- Joseph B. Ottinger [EMAIL PROTECTED] http://cupid.suninternet.com/~joeo HOMES.COM Developer
Re: Clustering in Orion
Quick and dirty "load balancing" is round robin DNS. I just did a quick test the other day and set up two machines with our app. Hit the URL once and logged in (keeps object in session). Killed the app on one machine and hit reload. I was still logged in on the other machine. I got some errors as Netscape didn't choose to look at the other IP (in RR DNS you specify multiple IPs for a single domain name) right off. But it did show that session failover worked. -- Joel Shellman Chief Software Architect The virally-driven B2B marketplace for outsourcing projects http://www.ants.com/90589781 Kevin Duffey wrote: I have clustered Orion, but there is alot I don't know about it. I have learned that Orion does session replication to every server in the cluster farm. I have not been able to test it with a load-balancer yet. Anyone happen to know of a "free" software load-balancer that can be used to test multiple servers with? Clustering with Orion is easy. You just add a cluster id="x" / to server.xml on each server in the Orion/config dir. x is equal to a unique number on each server. then you add a cluster-config / to each orion-web.xml in the WEB-INF dir of a web app. That should cluster it. There are a number of issues I am not sure of however. If you run orion with the -console2 option, it brings up a SWING based admin console, and you can open the http tree and see the web-apps running, then look at sessions in each of those apps. When I cluster two servers, and hit one, the session data appears in both servers. However, on the server that the session was not created on, the values of the objects in the session are not available. This confuses me because I figured if I hit the other server that has been replicated to, and passed along the session ID (jsessionid=xxx), that it would automatically make that session available to me. However, one of our engineers mentioned that a session is stored via the ip address being hit. Thus, even though the session data is saved on two servers, trying to access the same session from two different ip addresses won't work. My only dilema here is..if a server goes down (say the one the session data was created on), so only one is left, does that automatically take over? I can't get this to work because I don't have a load balancer. I assume using a load-balancer is easy enough and this would work. Anyone from the Orion team care to respond..that would be great if you could explain how this is done.
RE: Clustering help..
Title: RE: Clustering help.. How does JMS factor into this? Is it load-balanced? Here is my scenario: I would like to deploy Orion across a number of servers (4 or so). Each server uses heavy caching of database objects, which in a few some cases need to be synchronized across all servers. I'm considering using lightweight JMS messages to achieve this, but I'm not entirely sure on what the best setup would be. Ideally, it'd be the same config files for every server, and within each instance of Orion, the caches would talk to ormi://localhost to publish and receive, with the servers themselves 'somehow' talking to each other. If the servers don't automagically talk to each other, then I'd have to put in all servers in every config file, and all the publishers would either publish to all servers/subscribe only to itself, or subscribe to all servers/publish only to itself. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bernard Sauterel Sent: Saturday, August 12, 2000 5:57 PM To: Orion-Interest Subject: Re: Clustering help.. I needs urgently more information on clustering features of Orion: - Session Beans Not clustered, can be used from multiple nodes and can be serviced from multiple nodes but there is no failover of data if one node goes down yet. - Entity beans Not clustered, must be serviced from one node but can be used from multiple nodes. - Servlets ServletContext and session data are replicated, the data (beans) must be serializable or EJB references or similar, this will be specified in detail in the Servlet 2.3 spec. - JNDI JNDI is clustered within a cluster so a lookup finds an instance if it resides in any of the nodes in the cluster. - Client applications Clients can have multiple ORMI urls specified in provider.url (comma separated) to try other hosts if one goes down. I readed on your http-clustering-howto.html, we needs an external (non-orion) IP dispatching solution for production use: - is it mandatory ? Yes. - if so, I plan to use RedHat High Availability Server - is it a right solution ? We havent tried that one so we dont know. If it forwards incoming socket requests in a round-robin or other manner then yes, it should work. On Sam, 12 aoû 2000, Keven Duffey [EMAIL PROTECTED] wrote: Hi, I have yet to figure out how to cluster Orion. The documentation still leaves a lot to be desired. If I have two separate machines, how do I get two Orion servers to talk with one another? Can I have one be the servlet engine, and one be th ejb engine? How about fail-over? Ideally I want two (or more) web server/servlet engine front-end boxes, and two or more EJB boxes. Can someone shed some light on how to get this to work. Initially I need the fail-over servlet engines, because I am not doing the EJB stuff yet. So how would I set up two boxes to be fail-over, scalable and load-balanced with Orion? How do I add more computers to one tier? Thanks. +--++ | Bernard Sauterel | sauterel.net | +--++ email | [EMAIL PROTECTED]
Re: Clustering help..
Hate to just chime in, but I would love some information on this as well. Not only instructions and documentation for it, but a list of clustering features that are supported would be great too. - Original Message - From: "Keven Duffey" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Saturday, August 12, 2000 5:28 PM Subject: Clustering help.. Hi, I have yet to figure out how to cluster Orion. The documentation still leaves a lot to be desired. If I have two separate machines, how do I get two Orion servers to talk with one another? Can I have one be the servlet engine, and one be th ejb engine? How about fail-over? Ideally I want two (or more) web server/servlet engine front-end boxes, and two or more EJB boxes. Can someone shed some light on how to get this to work. Initially I need the fail-over servlet engines, because I am not doing the EJB stuff yet. So how would I set up two boxes to be fail-over, scalable and load-balanced with Orion? How do I add more computers to one tier? Thanks.
RE: Clustering
Set the RMI to clustering , than the EJB can be clustering, like this cluster password="123" name="admin" / You need the username and password to let clusters to talk, so admin would be OK. Since no official document mention about ejb clustering, I am not sure this is right. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mark Causer Sent: Wednesday, June 28, 2000 10:21 PM To: Orion-Interest Subject: Clustering Have been looking at using Orion for Clustering and I am getting very confused. Some Questions: 1. Ive looked at the example quoted in http://www.orionserver.com/docs/http-clustering-howto.html - Why do I have to pass the sessionid to the second server ? Shouldn't the clustering keep that data in sync ? - 2. EJB Clustering. Is this supported in Orion ? If so how do I set it up ? 3. Why is there a cluster id in server.xml and rmi.xml ?? 4. What is the server host="the.remote.server.com" password="123" port="23791" username="admin" / tag in rmi.xml used for ? Sorry if I appear dense, but if anyone could explain this I would be very grateful Thanks Mark Causer
RE: CLUSTERING ¨?
I too would like to know about this... do reply back to orion-interest. Dean Mao (catch23) -Original Message- From: David Sierra Fernandez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 07, 2000 1:23 PM To: Orion-Interest Subject: CLUSTERING ¨? I want to know ASAP if orion supports replication and failover for: * home interfaces * stateless beans and what about: * servlets * JNDI * HTTP request * JSPs (I think it is useless to have the beans replicated if the server that fails is the only one which contains the JNDI) THANK YOU VERY MUCH. - David Sierra Fern ndez E.T.S.I. Telecomunicaci¢n Universidad de ValladolidAULA CEDETEL Campus Miguel Delibes E-Mail: [EMAIL PROTECTED] 47011 Valladolid (SPAIN) -- -- Sierr@ --
RE: CLUSTERING ¨?
http://www.orionserver.com/docs/http-clustering-howto.html -Original Message- From: Mao, Dean [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 08, 2000 5:10 AM To: Orion-Interest Subject: RE: CLUSTERING ¨? I too would like to know about this... do reply back to orion-interest. Dean Mao (catch23) -Original Message- From: David Sierra Fernandez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 07, 2000 1:23 PM To: Orion-Interest Subject: CLUSTERING ¨? I want to know ASAP if orion supports replication and failover for: * home interfaces * stateless beans and what about: * servlets * JNDI * HTTP request * JSPs (I think it is useless to have the beans replicated if the server that fails is the only one which contains the JNDI) THANK YOU VERY MUCH. - David Sierra Fern ndez E.T.S.I. Telecomunicaci¢n Universidad de ValladolidAULA CEDETEL Campus Miguel Delibes E-Mail: [EMAIL PROTECTED] 47011 Valladolid (SPAIN) -- -- Sierr@ --
Re: Clustering
Hello Roy, To try out clustering, check out http://www.orionserver.com/docs/http-clustering-howto.html We will soon give you some more info on how to build a production cluster using different solutions. A simple solution you could try is simply adding a load-balancig DNS server for your site and add the cluster-config/ tag to all your nodes (so that session info gets propagated correctly). Stay tuned for info on how to do more advanced clustering. Also, make sure you get the lastest jar by doing an auto-update (java -jar autoupdate.jar) before using clustering, since certain things have recently changed in the config of clustering. (And before doing an auto-update, make sure you backup your own code/config in the orion dirs) Regards, Karl Avedal "Lou, Roy" wrote: Hi! My name is Roy Lou. I am new to orion-interest. Could you shed some light on the topic of how to set up clustering for servlet and jsp? Is there any document about how to do it? Thanks. Roy Lou SPSS Inc.
Re: Clustering
How do I actually set up the clustering? I have played with the orion-web.xml file and all I tend to get is an unable to connect error! Anyone got any ideas? Dan - Original Message - From: Scott Lawrence [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Friday, March 03, 2000 6:17 PM Subject: Clustering I know that there is a cluster id setting in server.xml but how do we actually use clustering? Also, what is Orion's definition of clustering in terms of JSP's and Servlets? I know that EJB clustering isn't available yet (in the FAQ).
