Hello,
I fully agree with Greg's message.
- We need to do it in pure Java
- we don't need to be 100% sticky (99.99% is enough)
- Let's make a first version that don't have fancy things but, at least, that
work!
- java.nio is the way (plus giving a doc about tuning the TCP stack such as
TIME_WAIT values and so on)
Cheers,
Sacha
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Greg
> Wilkins
> Envoye : vendredi, 8 mars 2002 03:35
> A : [EMAIL PROTECTED]
> Cc : [EMAIL PROTECTED]
> Objet : [JBoss-dev] Re: [jetty-discuss] HTTP loadbalancing
>
>
>
> While using DNS may well be a naive, I think it is more naive to
> think that user space code running on a general purpose computer is
> a good solution if you are concerned about load and/or failover.
>
> If you really want performance and reliability, then firmware is the
> solution for you and the 25K will do a little to help my Cisco shares :-)
>
> However, I do think we need a reasonable solution that works as a
> reasonable introduction to loadbalancing and failover.
>
> If my understanding of the clustering / session manager is
> correct, it does
> not really matter if sessions are not 100% sticky. The
> clustering stuff will
> cope, but it is just more efficient if it does not need to move
> everything to
> a new node.
>
> So this is the approach that I would like to take for this:
>
> + Write it in java, because we want to be 100% pure. If that is not
> fast enough - buy Cisco ( I will declare an interest here as
> Cisco are the
> prime sponsor of Jetty development !-)
>
> + Use java.nio as:
> * if you care about performance you should be using jdk1.4 anyway
> * if you want one machine to handle more connections than the sum of
> all your servers, then java.net.ServerSocket aint going
> to do the job!
> * I want to play with nio before I write the NioListener for Jetty!
>
> * Allow sticky sessions, sticky IP and sticky host options.
>
> * If sticky sessions are used, or all new connections look for
> "jsessionid=" in the first packet of the request and the
> response. If
> found, associate the ID with the current connecton allocation.
>
> * If sticky IP is set, use a hashmap of the source InetAddress
> to determine
> the connection association.
>
> * If sticky host option is set, use hashmap on
> InetAddress.getCanonicalHostName()
> to determine the connection association.
>
> * If multiple options are set, they are tried in the order they
> we defined
> until an association is found.
>
> * Stickyness applies to a listener, so you can have different
> settings for http and
> https ports.
>
> * If you have a new connection, an association to a server will
> be made via a
> pluggable balance policy. The default will be round robin
> or least connections.
>
> * If a connections are only re-associated as they break or fail
> to connect to
> a server.
>
> + A failing server will continue to be tried for new
> connections according to the
> balancing policy - so that it can come back into the fold.
> A fancy balancing policy may wish to exclude a failed server
> for a period of
> time, or until further notice.
>
> + At this stage, there will be no re-balancing of existing
> associations if the
> load becomes asymmetric due to random chance (or any other reason).
>
>
> How does that sound? It should at least be a start for load
> balancing and failover.
>
> I should have something working like this within a day or a month
> (Now there
> is a broad estimate for you). I'm happy to do this myself, but
> would also
> appreciate a keen buddy on this once the skeleton is in place.
>
>
> cheers
>
>
> Bill Burke wrote:
> > I was looking at the way Apache+Tomcat works. They use a
> protocol between
> > themselves. Apache decrypts the SSL message and extracts
> "sticky" session
> > information as well as SSL information and passes this over a
> load-balanced
> > socket over a proprietary protocol to the Tomcat instance. The message
> > contains the HTTP request as well as all the SSL information. Tomcat
> > unpacks the message, creates an HttpRequest, and sends the
> request on their
> > local "bus". I guess they call this a Tomcat Connector.
> >
> > ---
> >
> > Marc, I see no reason why you have to be separate from Apache.
> The issues
> > here aren't trivial and they've already done all the work and they're
> > open-source. Actually their license is much more liberal than
> LGPL. Plus
> > for this kind of stuff you probably want something written in C
> for speed as
> > Greg suggested. Jetty already leverages Jasper, why not mod_jk?
> >
> > ---
> >
> > As far as load-balancing based on client IP and AOL, it is even
> worse than
> > you think. Supposedly, a client's IP can change in the middle of the
> > session.(I said supposedly remember ;) You acutally have to
> stick on a mask
> > of the IP. Sure, client IP isn't the best way, but it was the
> only thing us
> > ignorant bloaks knew at the time :)
> >
> >
> >>-----Original Message-----
> >>From: Greg Wilkins [mailto:[EMAIL PROTECTED]]
> >>Sent: Thursday, March 07, 2002 6:05 AM
> >>To: [EMAIL PROTECTED]
> >>Subject: Re: [jetty-discuss] HTTP loadbalancing
> >>
> >>
> >>
> >>Chris,
> >>
> >>Your comments are correct (and user are the only ones who should post
> >>to jetty-discuss!-)
> >>
> >>There are two common solutions:
> >>
> >>As the load balancer is in your organization then you can give it
> >>the server certificate and it can terminate the SSL connection.
> >>The forwarded connection is then done using standard HTTP or some
> >>other protocol. It is not over the internet, so it is moderately
> >>secure (depending on the organizations network setup).
> >>
> >>The main problem with this setup, is that the server knows nothing
> >>about the SSL side of things. Thus the container rewrites URLs as
> >>http: rather than https:
> >>
> >>The other solution is to have the balancer work at the TCP/IP level,
> >>so that it does not decrypt the packet. As it cannot crack open
> >>the packets, it must use some other way of making sessions sticky.
> >>The common way to do this is a hash on the client IP address, so
> >>all connections from the same IP go to the same server.
> >>
> >>The problem with this one is that all AOL users may share the same
> >>HTTP proxy - thus the same source IP address.
> >>
> >>But then there is no such thing as a silver bullet!
> >>
> >>I'm about halfway through implementing the first solution - but it
> >>is complex and will take time.
> >>
> >>The second solution is easier and I'll try to find the day or two
> >>that will be needed to implement it. I already have most of the
> >>required infrastructure in the JettyExtra InetGateway class.
> >>
> >>cheers
> >>
> >>
> >>
> >>
> >>Chris Haynes wrote:
> >>
> >>>"Bill Burke" <[EMAIL PROTECTED]> wrote:
> >>>...
> >>>
> >>>
> >>>>Especially for HTTPs, since you have to decrypt the message to get
> >>>>
> >>>>
> >>>the
> >>>
> >>>
> >>>>session cookie.
> >>>>
> >>>>
> >>>
> >>>Forgive a mere user for intruding on jetty-discuss, but isn't there
> >>>something architecturally awry here.
> >>>
> >>>As I understand HTTPS, there can only be one server-end to the
> >>>SSL/TLS.
> >>>
> >>>Either the server-end is at the 'proxy' (with it holding the host
> >>>keystore etc.), or the proxy can't decrypt.
> >>>
> >>>If the proxy acts as the server-end, then how is the Servlet system at
> >>>the 'actual' server to supply the 'isSecure()' value to the Servlet?
> >>>
> >>>
> >>>Chris Haynes
> >>>
> >>>
> >>>
> >>>For the latest information about Jetty, please see
> >>>
> > http://jetty.mortbay.org
> >
> >>To alter your subscription to this list goto
> >>
> > http://groups.yahoo.com/group/jetty-discuss
> >
> >>Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>>
>>
>>
>
>
>
> --
> Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462
> Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631
> http://www.mortbay.com AU Phone: +61-(0)2 98107029
>
>
>
> For the latest information about Jetty, please see http://jetty.mortbay.org
>
> To alter your subscription to this list goto
> http://groups.yahoo.com/group/jetty-discuss
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
> ------------------------ Yahoo! Groups Sponsor ---------------------~-->
> Access Your PC from Anywhere
> Full setup in 2 minutes! - Free Download
> http://us.click.yahoo.com/Y8IZpD/2XkDAA/yigFAA/CefplB/TM
> ---------------------------------------------------------------------~->
>
> For the latest information about Jetty, please see http://jetty.mortbay.org
>
> To alter your subscription to this list goto
>http://groups.yahoo.com/group/jetty-discuss
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
--
Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462
Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631
http://www.mortbay.com AU Phone: +61-(0)2 98107029
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
