On 2 Mar 2004, at 05:29, Mircea Toma wrote:
Stefano Mazzocchi wrote:
We were using Jisp and Scott's decision makes it clear that we either:
- have to maintain Jisp 2.x ourselves
or
- use something else
How about http://jdbm.sourceforge.net/ ? It implements the B+Tree
algorithm. B+Tree is a bett
Stefano Mazzocchi wrote:
We were using Jisp and Scott's decision makes it clear that we either:
- have to maintain Jisp 2.x ourselves
or
- use something else
How about http://jdbm.sourceforge.net/ ? It implements the B+Tree
algorithm. B+Tree is a better indexing mechanism than BTree, because
Geoff Howard wrote:
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
On 29 Feb 2004, at 21:58, Antonio Gallardo wrote:
Pier Fumagalli dijo:
On 29 Feb 2004, at 19:25, Geoff Howard wrote:
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?
Pier Fumagalli dijo:
> On 29 Feb 2004, at 19:25, Geoff Howard wrote:
>
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 looki
On 29 Feb 2004, at 19:25, Geoff Howard wrote:
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
m
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, incompat
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 ter
Le Mardi, 24 fév 2004, à 08:44 Europe/Zurich, Carsten Ziegeler a écrit :
...Exactly, we already tried out a store that simply used the
filesystem
(with converting a key to several directories). This Filesystem store
is still available somewhere and could be used.
BUT there were several problems (k
Antonio Gallardo wrote:
>
> Hi:
>
> I think a cache storage system is IMHO a very good idea. A
> piece of history:
>
> 1- Initial idea of using jisp:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100781998632619&w=2
>
> 2-is this is still valid?: "B-Tree indexed file vs filesystem
> dire
Thanks, Stefano.
This is very valuable information!
Stefano Mazzocchi wrote:
On Feb 23, 2004, at 10:59, Hochsteger Andreas /INFO-MA wrote:
Wouldn't it then be possible to serve valid content directly from the
apache
webserver by using the cache on the disk?
This is an entire different problem,
Hi:
I think a cache storage system is IMHO a very good idea. A piece of history:
1- Initial idea of using jisp:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100781998632619&w=2
2-is this is still valid?: "B-Tree indexed file vs filesystem directory"
http://marc.theaimsgroup.com/?l=xml-cocoon
On 23.02.2004 16:47, Stefano Mazzocchi wrote:
We were using Jisp and Scott's decision makes it clear that we either:
- have to maintain Jisp 2.x ourselves
or
- use something else
Here I would like to ask you a much easier question: do we really need
it? can't we just our storage into a bunch
On Feb 23, 2004, at 11:27, Bertrand Delacretaz wrote:
Le Lundi, 23 fév 2004, à 17:20 Europe/Zurich, Scott Robert Ladd a
écrit :
...When I've written cache system, I've always used the file system
directly. The only catch is that some operating systems limit the
number of files on disk or in a
On Feb 23, 2004, at 11:20, Scott Robert Ladd wrote:
Hunsberger, Peter wrote:
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).
Makes sense to me: from what I understand of the
On Feb 23, 2004, at 10:59, Hochsteger Andreas /INFO-MA wrote:
Wouldn't it then be possible to serve valid content directly from the
apache
webserver by using the cache on the disk?
This is an entire different problem, Andreas.
You get the best performance boost, if you don't have to bother cocoo
Bertrand Delacretaz wrote:
Le Lundi, 23 fév 2004, à 17:20 Europe/Zurich, Scott Robert Ladd a écrit :
...When I've written cache system, I've always used the file system
directly. The only catch is that some operating systems limit the
number of files on disk or in a directory; a very active ser
Le Lundi, 23 fév 2004, à 17:20 Europe/Zurich, Scott Robert Ladd a écrit
:
...When I've written cache system, I've always used the file system
directly. The only catch is that some operating systems limit the
number of files on disk or in a directory; a very active server could
hit those limits
Hunsberger, Peter wrote:
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).
Makes sense to me: from what I understand of the issue the store is
(mostly?) not updatable (you eithe
Stefano Mazzocchi <[EMAIL PROTECTED]> writes:
>
> We were using Jisp and Scott's decision makes it clear that we either:
>
> - have to maintain Jisp 2.x ourselves
>
> or
>
> - use something else
>
> Here I would like to ask you a much easier question: do we
> really need
> it? can't we
> To: Apache Cocoon
> Subject: [RT] rethinking the cache storage system
>
>
> We were using Jisp and Scott's decision makes it clear that we either:
>
> - have to maintain Jisp 2.x ourselves
>
> or
>
> - use something else
>
> Here I would lik
Stefano Mazzocchi wrote:
We were using Jisp and Scott's decision makes it clear that we either:
- have to maintain Jisp 2.x ourselves
No. I have stated that I am more than willing to maintain and support
Jisp 2.x, under the libpng license, specifically for Cocoon.
I am not willing to relicense
We were using Jisp and Scott's decision makes it clear that we either:
- have to maintain Jisp 2.x ourselves
or
- use something else
Here I would like to ask you a much easier question: do we really need
it? can't we just our storage into a bunch directories and use that as a
file system? t
23 matches
Mail list logo
