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/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?
>
>ew> oracle doesn't recommend using ssl at all with oc4j, because they want
>to use their apache/proxy frontend.
>
>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.
> >
