Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of pid@pidster.com designates
 209.85.215.179 as permitted sender)
Message-ID: <50F72256.8080309@pidster.com>
Date: Wed, 16 Jan 2013 21:57:42 +0000
From: Pid <pid@pidster.com>
Organization: Pidster Inc
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: docBase
References: 
 <D72C174D3CAC0A4E812FAD012D646E9F25052DAC7B@CMS1.enterprise.maricopa.gov>
 <50F6C6AB.3070809@pidster.com>
 <D72C174D3CAC0A4E812FAD012D646E9F25052DB8FD@CMS1.enterprise.maricopa.gov>
In-Reply-To: 
 <D72C174D3CAC0A4E812FAD012D646E9F25052DB8FD@CMS1.enterprise.maricopa.gov>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 16/01/2013 21:17, Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: Pid [mailto:pid@pidster.com]
>> Subject: Re: docBase
>>
>> On 11/01/2013 20:24, Leo Donahue - RDSA IT wrote:
>>> Tomcat 7.0.34
>>> Java 1.6.0_35
>>>
>>> Can the document base of a context be an administrative share?
>>
>> Yes.  But I would not encourage it.  2nd only to NFS for causing random errors.
>>
>> Unless you have a massive number of images totalling large amounts of data,
>> it would be better to arrange a periodic sync job to copy images across to each
>> node.
>>
>>
>> p
>>
> 
> Thank you sir.
> 
> What if one suffers from having conservatively configured nodes?  The amount of image cache we would want to create would not fit on any of our webservers.  Our web servers are virtualized and have only a few GB of storage.

If it can be publicly accessible, but CDNs are increasingly inexpensive.


> Moving off topic:
> 
> How does google do this:  http://mt1.google.com/vt/lyrs=m@205000000&hl=en&src=app&x=11&y=25&z=6&s=Ga  do you think these images are sitting on every node?  And what if google wanted to include an option to view aerial photos for each year for the past ten years?  That becomes a lot of data that lives on each node?  

No.  Custom CDN & some clever storage.


> In the example above, when a user requests an image tile from google, you can't tell whether that image lives on the webserver, or whether the webserver fetches that image from a share on another server.

No shares, lots of DNS routing and other nifty stuff.


> I have a lot of room on my NAS, but not on my webservers.  When we cache images for just our county, depending on how many scale levels I create and tile size, I can end up with several hundred GB for just a single year of aerial photos.  Reading those images on local (webserver) storage vs network storage is what I'm trying to decide.

That's quite a lot. :)

How many are in use at any given moment?  A caching app that was able to
preload adjacent image tiles would work if you wanted to build something.


p


-- 

[key:62590808]

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org