RE: HA tomcat ( was: RE: 5.0 proposal)
Mathias, It would be great to see some details on your experiences with load-balancing Tomcat, and any tricks you've come up with would be much appreciated by the community (well, at least my part of it ;) We also run Tomcat 4.0 in production, behind a hardware load balancer. It's working great thus far, but we don't have nearly the traffic to require even the setup we have now, so I can't contribute an aweful lot except to say 'works-for-me' Aaron Dunlop -Original Message- From: Mathias Herberts [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 11:23 AM To: Tomcat Developers List Subject: Re: HA tomcat ( was: RE: 5.0 proposal) [snip] Well, I know quite a few people who managed to get tomcat in production on a variety of sites ( including very large loads). I run Tomcat on 20 or so production web sites, with volumes in the 2/3 million hits per day mark. I've been running Tomcat since march 2000, starting with 3.2.1. I think with a little of involvment it is easy to set up a high availability environment using Apache/Tomcat and maybe hardware load balancers. Maybe what is missing is a good tutorial on such a setup. Maybe I could start thinking about writing something about our setup. We came up with neat tricks to handle live application upgrade and this sort of things. I don't know where this could fit in but it is definitely the kind of HOWTO that could be good for the spread of Tomcat on production environments. As for the pure servlet speed Tomcat can deliver, from what I see everyday, the bottleneck is usually in the data tier and not in the application server, so this is a purely sterile debate in my opinion. Just my 2 cents of euro worth. Mathias. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: shutdown code
Title: RE: shutdown code The servlet 2.3 specification (implemented by Tomcat 4) allows the user to register as an event listener for container events like application startup/shutdown, session create, session invalidate/timeout, etc. The proposed final draft of the servlet 2.3 spec can be downloaded from http://java.sun.com/products/servlet/download.html Of course that doesn't help you much unless you can use Tomcat 4 :) Aaron Dunlop -Original Message- From: Stepan Kalichkin [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 4:15 AM To: [EMAIL PROTECTED] Subject: shutdown code Hi all. How I can start servlet or any metod in java class before shudown tomcat is finished (when I run shutdown.sh) I must make some operation for resource free but I don't know how I can do this. May be sombody know??? Thanks.
RE: Use of Apache proxy module to connect to Tomcat
Title: RE: Use of Apache proxy module to connect to Tomcat Yes - it seems to work just fine with Tomcat. I've been experimenting with it as a possible authentication and firewall solution, and we may consider it as a method for load-balancing as well. We're thinking of having Apache segment our webspace by sending requests to different apps to different servers (e.g. a production server and a demonstration/sales server, both accessible from the same domain) Also, apache can authenticate access to certain pages using an LDAP database. I'm not sure this is the best solution, and Paulo's probably right that AJP would be more efficient, but it seems to be working so far. Just my $.02 Aaron Dunlop -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 10, 2001 1:59 PM To: [EMAIL PROTECTED] Subject: Re: Use of Apache proxy module to connect to Tomcat on 4/10/01 1:59 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: Is this possible for Tomcat too? Pros and cons? Thanks and have fun, Paulo Gaspar Of course it is. Proxy HTTP is probably not as efficient as a lightweight protocol (ie: AJP), especially if the two systems are running on the same box (ie: local sockets). It also doesn't solve the configuration issues. All you are doing in this case is putting another layer in front of the Tomcat HTTPd. I don't see a reason to do that when the Tomcat HTTPd works just fine. All you are gaining is the Apache module features (like mod_rewrite). -jon
Re: TC3.3m1 Possible bug with session.invalidate
Title: Re: TC3.3m1 Possible bug with session.invalidate I seem to be having a similar problem. My app also uses session information to track logins, and calls session.invalidate() when a user logs out. So far I'm seeing that if a user starts up a new browser, logs in, logs out, and attempts to login again as a different user, they get the session from their first login as if they had never logged out. Logging off again appears to fix the problem, and subsequent logins from the browser work fine. The problem recurs when a new browser is started. I don't see any references to this problem in Bugzilla, so I'll dive into the code and see what I can find. But if by chance someone has already fixed this problem somewhere, please let me know. --- Environment: Server: Tomcat 3.3m1 standalone on Solaris 2.7 IBM JDK 1.2.2 Client: NT 4.0 SP 5 IE 5.5 or Netscape 4.7 - same symptoms Thanks, Aaron Dunlop [EMAIL PROTECTED] -- From: [EMAIL PROTECTED] Hi, I seem to be having a problem with session.invalidate(). I'm using this for users to log out of my web site but it seems to take two attemps before the user is properly logged out! I am using JDBCRealms for authentication BTW. I have set up a simple four page web site: test/jsp/index.jsp front page % response.setHeader(Cache-Control,no-cache); //HTTP 1.1 response.setHeader(Pragma,no-cache); //HTTP 1.0 response.setDateHeader (Expires, 0); //prevents caching at the proxy server % html body %=request.toString()%br %=request.getSession (false)%br %=request.getRemoteUser()%br %=request.getUserPrincipal()%br h2a href=protected/index.jspLogin/ah2 /body /html test/jsp/protected/index.jsp --- protected page % response.setHeader(Cache-Control,no-cache); //HTTP 1.1 response.setHeader(Pragma,no-cache); //HTTP 1.0 response.setDateHeader (Expires, 0); //prevents caching at the proxy server % html body %=request.toString()%br %=request.getSession (false)%br h2you are currently logged in as %= request.getRemoteUser() %/h2 h3a href=logout.jspLogout/a/h3 /body /html test/jsp/protected/logout.jsp --- logout page % response.setHeader(Cache-Control,no-cache); //HTTP 1.1 response.setHeader(Pragma,no-cache); //HTTP 1.0 response.setDateHeader (Expires, 0); //prevents caching at the proxy server % html body %=request.toString()%br %=request.getSession (false)%br %=request.getRemoteUser()%br %=request.getUserPrincipal()%br % session.invalidate (); % %=request.getSession (false)%br %=request.toString()%br %=request.getRemoteUser()%br %=request.getUserPrincipal()%br a href=../index.jsphome/a. /body /html test/jsp/login/login.jsp --- login page used by FORM based authentication. html body h1Login page /h1 form method=POST action=j_security_check Username: input type=text name=j_usernamebr Password: input type=password name=j_passwordbr br input type=submit value=login name=j_security_check /form /body /html The problem occurs like this: The first time around the request for protected/index.jsp is detected and you have to log in. From there, access the logout page which does a % session.invalidate();%. Then back to jsp/index.jsp, try and access the protected page from here -- straight in as still authenticated. Accessing the log out page again, actually logs out this time! Is this a known problem? Any possible work arounds? Thanks, Sam. PS. This work fine on TC3.2.1
