Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <40423CA5.8050503@leverageweb.com>
Date: Sun, 29 Feb 2004 14:25:25 -0500
From: Geoff Howard <cocoon@leverageweb.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] rethinking the cache storage system
References: <403A207D.7040704@apache.org>
 <B723D9F7-6AB9-11D8-8086-000A95984AEA@betaversion.org>
In-Reply-To: <B723D9F7-6AB9-11D8-8086-000A95984AEA@betaversion.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Pier Fumagalli wrote:

> On 23 Feb 2004, at 15:47, Stefano Mazzocchi wrote:
>
>>
>> My gut feelins is that having such a critical piece of our 
>> infrastructure so away from the metal is actually hurting us, both 
>> performance and complexity wise.
>
>
> +1
>
>> I would love to use BerkeleyDB, but it's native, incompatibly 
>> licensed and has terrible Java APIs. And all the problems of binary 
>> stores: you can't see inside from your shell!
>
>
> It's all right...
>
>> I think that a better use of the file system would yield much more 
>> performance, since JVM IO is pretty much optimized for file access 
>> anyway (and uses OS-level caching).
>>
>> thoughts?
>
>
> I've been looking at the java.nio stuff, especially in the area of 
> memory mapping some files :-P I can tell you that it's FAST, and 
> basically does the trick. See a file as a big array in ram, well, but 
> actually it's only a "fake" array mapped really on the disk, and 
> cached by kernel...


I've been thinking of that myself -- do I remember correctly that we've 
tossed around the idea of making 2.2 jdk1.4 only??

Geoff