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 EJB tier (so 
> scalability on the EJB
> tier or the front-end WEB tier is equally as easy)?
> 
> 
> Thanks.
> 

Reply via email to