-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lb,
lightbulb432 wrote: > >> Don't forget that you can't be stateless if you >> need logins of some type (unless you use BASIC auth, which looks ugly >> from a user point of view). > > Why is this? Others who answered to this thread and discussions in general > around web applications describe statelessness as an option for > fully-functional webapps, which I imagine includes login functionality. Well, Tomcat must keep authentication information somewhere in memory after you login, even if it doesn't use a session to manage it (which I'm sure it does, though I think the auth information is not stored /in/ the session, but rather associated with it in some other way). If you aren't replicating sessions between Tomcat instances, you can't switch instances without logging-in again. >> I'm not convinced you can reasonably do authenticated transactions >> (using Tomcat's auth) without stateful connections. You can hack around >> with storing login cookies or doing your own auth management, but I like >> the simplicity of using J2EE auth. > > Could you describe the limitations of statelessness as it relates to > Tomcat's authorization? See above. > If you use your own custom login functionality then > I see how there's no problem (just check the cookie or database for the > current session ID for the right credentials, then allow access) Actually, this might not be possible if you're trying to use session information (without a few hacks). Since Tomcat will respond to an invalid session id request by creating a new session (new id), switching instances will result in the old session cookie being replaced by the new one. You will end up constantly re-writing the session id in the database you use to maintain login information. > but is the > same mechanism not possible or available when trying to use the Tomcat or > standard Servlet authentication mechanism? Unless you write your own Realm, I don't think this is possible. > What's Tomcat's algorithm for load-balancing while taking into account > session affinity? I don't believe that Tomcat does any load balancing at all. Also, with session affinity, there's no balancing going on once you are assigned to a server (unless that one goes down). For info on lb algorithms, you'd need to look at your load balancer. I believe that mod_jk can be configured to use one of several types, including an estimated "load" to try and route new visitors to the more-idle members in the cluster. > I remember in the response to another of my threads on this list people > saying that it's generally outdated to use connectors and front Tomcat with > Apache. I just want to confirm that it's the connector mechanism by which > load balancing is possible with Tomcat, right? Well, it's one way. You can certainly use a hardware load balancer, too, which is probably better in the long run. > On what machine is the connector software usually on? It's always on the web server. > If you have 5 machines > with Tomcat on each, would you have the load balancer on one of those, on a > dedicated machine, or would you have some other setup? What's generally done > in production for high-availability sites? It's really up to you and the requirements of your software. Some applications can actually run within the DMZ and so it doesn't matter if you run, say, Apache httpd on one of the app servers along with Tomcat. Or, you could even run it on all of them. Most often, you'll see that the web servers live in the DMZ and are directly accessible from the Internet, while the application servers live on a private subnet in the back, and can only be accessed from within the DMZ or that private subnet. The lbs can be anywhere, but generally sit way out at the front, and are the only things accessible from the Internet. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1EL99CaO5/Lv0PARAj9lAKChBbFkMRLdSfO4x2xXFFFxY88t4QCgm7gc cjQWB4jdTbFTdSvbDpaUy44= =hlNZ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
