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 16:54:12 GMT
Hassan Schroeder wrote:
> On Sun, Feb 21, 2010 at 7:36 AM, André Warnier <> wrote:
>> Not to mention possible inconsistencies between the different copies..
>> ;-)
>> Imagine you have 4 balanced Tomcats, each of which has its own file
>> repository, and each of which can potentially run the next upload request or
>> download request.  To/from where does the file get uploaded/downladed ?
>> (until all rsyncs have run).  And if the file is there twice, but different,
>> which one is correct ? (how would rsync know ?)
> Have you used rsync? 
Yes, quite a lot. But not necessarily all the options.

Because I'm not sure I'm understanding your
> questions. I don't see how downloads are relevant; 

What I meant was this : a user uploads a file. That file is uploaded to 
one Tomcat, and there is only a copy on that one Tomcat, until rsync has 
synchronised it to the other Tomcats.
If at that point a user (maybe even the same one, just to check) 
requests the file, this request ends up with one of the Tomcats, not 
necessarily the same one.  What if that Tomcat does not have the file yet ?

It may be that I am misunderstading how you would set up the rsync bit.

it's uploads that
> add a file to the file system on the Tomcat that processed the request.
> And that would be the source filesystem to rsync from.

Yes, but how often ? (again, maybe my incomplete knowledge of the rsync 
capabilities).  Each Tomcat would need to rsync is repository with each 
of the others, constantly, not so ? Isn't that in itself going to 
generate a lot of traffic ? And if each Tomcat "pulls" the files of the 
others via rsync, how does one rsync know that the new file he is seeing 
on this other Tomcat has finished uploading ?

Not polemical questions by the way, genuinely trying to learn new 
tricks, and inform the OP about alternatives.

In my opinion, the simplest and most reliable scheme is to have one 
single repository, which could itself be made as reliable as possible 
via a number of methods (hardware duplication, replication, 
snapshots,..). If there are locking issues, the single repository makes 
them easier to solve.  If there is only one "uploading host", that again 
makes it easier.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message