Ok, but then tell me how do I effectively protect each single chunck of data using the servlet security mechanism if the data is not served by tomcat? The problem is that my customer wants every single image, html, pdf and what so ever be directly protected. In other words if someone directly enters a specific url to a pdf for example he should be redirected to a login page (using form based login) unless he is already logged in.
Bjoern > -----Ursprüngliche Nachricht----- > Von: Duan, Nick [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 23. November 2005 21:22 > An: Tomcat Users List > Betreff: RE: Where should I store my static content in a > clustered environment > > A simple solution would be to have all static pages hosted on > an Apache httpd server in front of tomcat clusters. If you > need more performance, just cluster the httpds. Tomcat is not > really designed to server static pages. Apache httpd can > also serve as a LB. In this case, certainly you have to > treat static pages separately from dynamic webapps. In other > words, you can't bundle static pages with your war files. > > ND > > -----Original Message----- > From: Eickvonder Bjoern [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 23, 2005 4:23 AM > To: users@tomcat.apache.org > Subject: Where should I store my static content in a > clustered environment > > Hi, > > lets start with describing my current task where I would > appreciate any advice from you. > I have to construct a clustered system (with lots of > webservers) that has few dynamic pages but a lot of static > ones, whereby all resources have to be protected by > security-constraints of a webapp (so letting Apache deliver > this content won't work). Moreover there should be the > possibility to upload/delete static components via a web > form. My main problem is now where should I store the static > data (mainly html pages, images, ...; but over 4 GB(!) large > in total)? > > As far as now I'm considering the following solutions: > > 1.) Storing the content within the webapp of each webserver. > This would include that the servers know each other as the > upload/delete operations must be propagated from one server > to all the others. Moreover the update of the dynamic parts > would not be as easy any more as just uploading a new > war-file as this requires deleting the old webapp directory > (that contains the content is this case as well). > > 2.) Storing the content in a separate directory but still on > each webserver. This would still include that servers must > know each other, but updating the dynamic part would be > easier. The downside is that I would have to write a servlet > that delivers all static content with all the problems of > mime-types, character encoding and so on which I would have > to handle myself. > > 3.) Storing the content in a database on a separate server. > The advantage would be that webservers only need to know > their database server and updating the webapps would be easy > (just uploading new war-files). The downside here is that I > need a servlet too and I think it's maybe not the fastest > solution as all requests of all servers to each single chuck > of static content would require a connection to the database server. > > 4.) As 3.) but storing data on a single separate server in > the filesystem. The advantages/disadvantages should be > similar to 3.) whereby I do not know which solution might be faster. > > 5.) As 3.)/4.) but additionally implementing a > caching-mechanism on the webservers. This means if a > webserver gets a request for a specific page for the first > time he connects the database server to retrieve that page, > then stores it in its webapp directory and then let tomcat > deliver that page. On the second request it is just checked > if that page is already there and if so it is delivered > directly. Of course I must implement some mechanism such that > the webservers get to know if their cached data is outdated > but so far this seems to me the best solution. > > Anyone ever faced this kind of problem? Any kind of remark to > my possible solutions or any other possibilities you might > know of are appreciated. > > Thanks you in advance for your help. > > Bjoern > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
