Hi awarnier, I was not aware that you could delegate authorization decisions to tomcat through apache. If this is the case that is good to hear, and means I can use httpd to serve my files and with all the advantages you described. I would certainly like to explore how to do this, please forward me any information u may have offline, if ur uncomfortable discussing on this forum.
The only question I have with regard to using this approach (more out of curiosity than immediate need), is what is the approach you would use if u had 2 httpd instances load balancing across multiple tomcat instances? How do u deal with the same problems you experience with tomcat accessing a single NFS server? Hasan, the approach you described is one that I was also considering to keep things consistent across tomcat instances (btw, there is no modifications occurring to existing files). I was considering using an approach whereby after a file is uploaded by a user, I run rsysnc to synchronize across the nodes. However my concern with this approach is that there will be a some delay before the file is available on other nodes (files can be up to couple 100MBs in size). In our case although the user uploads the file in one session (we use sticky sessions), quite soon afterwards, a standalone application may potentially be forwarded to the other tomcat instance, which hasnt yet got the entire file. Cheers, Imran awarnier wrote: > > imrank wrote: >> Hey, >> >> Thanks for ur prompt reply. >> >> Unfortunately, the approach you described wouldn't work in our case >> because >> our app needs to do some custom authorization logic before a file can be >> downloaded (sorry should've mentioned that). I dont think I can get httpd >> to >> perform this authorization logic. > > I have not yet met an authorization logic that can be done with Tomcat > and can't be done with Apache httpd (but I would be curious about the > details of yours, just to verify). > > This being said, with us being on a Tomcat forum and that sort of thing, > it is maybe not the right place for that kind of discussion. > (I am available off-list if you would like to explore this however). > So let's for now suppose that the authorization logic is unmovable and > has to happen at the Tomcat level.. > >> >> Can I use the approach of having all the files sitting on a single NFS >> file >> server and have the different tomcat instances read/write the files to >> that >> server's filesystem? I guess theres gonna be some cost in terms of >> network >> latency... > > You can certainly do that on the base of symbolic links and NFS mounts > for instance. Each Tomcat would contain something like : > > (tomcat_dir)/webapps/your_app/the_docs --> /mnt/NFS/somedir_with_docs > > Unless your network is really slow or these files really large, nowadays > network latency is probably not going to be the main concern. > The problem may be file and directory locking however, in a multi-user > and multi-Tomcat instances context. > You would have to make sure that no two Tomcats (and webapps within > these Tomcats) could conceivably be one reading, one writing the same > file at the same time. Through NFS this is not so easy. Note that you > would have the same kind of issue even if you did this through NFS at > the Apache level, but it may be easier because there is only one Apache > host. > > > Also, just to get you thinking on the subject of > authentication/authorization : > > 1) It is possible to conceive an AAA method at the Apache level, that > uses Tomcat as the AAA back-end. The basic idea is this : > - at the Tomcat level, you create a webapp that is basically a dummy, > and does nothing else than authentication/authorizing a request to it. > Its answer is a simple plain text response "yes" or "no". > - at the Apache level, whenever you need an authorization, you send a > background request to Tomcat and this dummy webapp, and read the > response (which could also be the user-id, instead of just "yes"). > Then if the response is positive, you proceed; else you return > "forbidden". > > 2) if you have an Apache front-end anyway, you can do /all/ the > authentication/authorization at the Apache level, thus freeing Tomcat(s) > for more interesting things. If Apache authenticates a request, it can > forward the obtained user-id to Tomcat when it proxies the request. > Check the "tomcatAuthentication" attribute to the <Connector> tag. > > > What ultimately makes more sense and is more efficient and is easier to > maintain, is a decision for you to make in function of your knowledge of > the setup and the usage patterns of the application. > > Instinctively, if your configuration is as follows : > > browser <--> Apache + connector <--> Tomcat + NFS <--> NFS fileserver > > then the megabits have to circulate through more network and more code > than if the configuration is like this : > > browser <--> Apache + NFS <--> NFS fileserver > > For example, in the first case, if your Apache front-end and Tomcats and > the NFS fileserver are on the same network cable, then the same file may > end up being transferred several times over that cable, before it is > sent to the browser. > > Also, if the serving of the static files is done at the Apache level, > you may be able to use one of the caching modules available at the > Apache level, to avoid even more network traffic. > But again that depends on the application, and how often the same files > would be requested over a period of time. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -- View this message in context: http://old.nabble.com/Serving-static-files-in-a-cluster-tp27672008p27677298.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
