cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <g-froehl...@gmx.de>
Subject RE: cvs commit: MRUMemoryStore.java FilesystemQueueObject.java
Date Mon, 28 Jan 2002 20:48:04 GMT
Hi,

>From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
>
>> From: Gerhard Froehlich [mailto:g-froehlich@gmx.de]
>> 
>> Hi,
>> 
>> >-----Original Message-----
>> >From: Britton, Colin [mailto:cbritton@metatomix.com]
>> >Sent: Monday, January 28, 2002 5:59 PM
>> >To: cocoon-dev@xml.apache.org
>> >Subject: RE: cvs commit: MRUMemoryStore.java
>FilesystemQueueObject.java
>> >
>> >
>> >For our application I want to not only cache from memory, but also
>store
>> >the objects on the fileSystem (as the cost of generation in our app
>can
>> >be high). With the change so that items are only written to the file
>> >system when the number of memory objects reaches max and this.free()
>is
>> >called it seems that we loose this capability unless we set the
>memory
>> >objects to a small number (which defeats the objective of the cache
>and
>> >having lots of memory). One of the benefits of the old way was that
>if
>> >the VM unexpectedly quits we had the file system cache for all the
>items
>> >that were in memory. Also all memory objects are lost after shutdown,
>> >maybe it would also be also a good idea to write the memory objects
>to
>> >disk on a formal shutdown (this was not needed with the old method)
>if
>> >the queue method is not returned.
>> 
>> You can't imagine how much thoughts I wasted for that issue. I will
>> explain you them (again):
>> 
>> a) The old way stored every object twice. First in Memory, Second on
>the
>> Filesystem. That was a very _expensive_ operation. We needed an extra
>> thread which did all that serialization and he eated performance.
>> The only real advantage was to have the objects persistent after a JVM
>> restart. Therefor I never had a good feeling about that. This are too
>> little advantages.
>> 
>> And besides, how often crashes the JVM. Every day, weekly, monthly.
>How long
>> does it take till the old caching status is reached? The first user
>gets
>> a slow page. The next a quick one.
>> 
>> I wanna have a clean implementation. This other issues are parts of
>the
>> adaptive
>> caching or something else I say. It must be simple!
>> 
>> b) The new way behaves more like a normal OS cache. First everything
>is
>> handeld
>> in memory. If this is running, old ones are swapped out to make room
>for
>> others.
>
>New store implementation - does it swaps to file system when removing
>items from the stores?

Yep it does. When the free() method is called, the oldest object is swapped
to Filsystem. That's the main difference here.

>> At least I see no way how to handle a formal shutdown. Did would be
>the
>> best. Then we could catch this event and save the memory store down to
>> the Filesystem.
>
>No problems with this. Implement Disposable interface. 

Does it catch "ctlr-c" or "kill" under Unix, when I shutdown for i.e. Tomcat
>Vadim
  Gerhard 
-------------------------------------------
Beer is God's way of showing us he loves us 
and wants us to be happy...
-------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message