tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Serving static files in a cluster
Date Sun, 21 Feb 2010 15:21:18 GMT
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 

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:
For additional commands, e-mail:

View raw message