Revert JCS, Re: XSP not working in CVS head?

[Vadim Gritsenko <va...@reverycodes.com>]

Unico Hommes wrote:

>Carsten Ziegeler <cziegeler <at> s-und-n.de> writes:
>
>  
>
>>It seems this is due to the move to JCS :(
>>
>>The logicsheet is put into the cache and JCS casts this to
>>Serializable in org.apache.jcs.access.CacheAccess.put().
>>
>>So, what do we do now...
>>
>>    
>>
>
>Yes, JCS requires objects to implement Serializable (quite acceptable
>requirement for a cache ).
>

It's acceptable only for *persistent* cache, but not for transient 
*object* cache. Cocoon requires transient cache for it to work 
(Templates caching etc), while persistent cache is optional.


>The same problem occurred with Pagesheet from the
>Paginator transformer. I've made both Logicsheet and Pagesheet implement
>Serializable. Alternatively we could let the JCSStore implementation check
>whether the object to store implements Serializable and if not wrap the object
>in a Serializable wrapper (at the cost of some performance).
>

What purpose would that serve? It will store empty wrappers on the hard 
drive and retrieve those empty wrappers and hand over back to Cocoon, 
and all kinds of failures (NullPointerExceptions) will start happening 
all over the place.

The only viable solution currently is rollback to Excalibur's memory 
cache - unless JCS becomes something which can work as in-memory object 
cache (with optional overflow to disk).

Vadim

Re: Revert JCS, Re: XSP not working in CVS head?

[Antonio Gallardo <ag...@agssa.net>]

Vadim Gritsenko dijo:
> Unico Hommes wrote:
>
>>Vadim Gritsenko <vadim <at> reverycodes.com> writes:
>>
>>
>>
>>>Unico Hommes wrote:
>>>
>>>It's acceptable only for *persistent* cache, but not for transient
>>>*object* cache. Cocoon requires transient cache for it to work
>>>(Templates caching etc), while persistent cache is optional.
>>>
>>>
>>>
>>
>>You are right. This should be the correct behavior. I am going to see how
>> JCS
>>can manage that and else see if EHCache manages it.
>>
>>
>
> I took a look at org.apache.jcs.access.CacheAccess, and it has 9 casts
> to Serializable, even when not needed. And CacheElement object contains
> two Serializables as key and value, not Objects.
>
> It seems it will be extensive API change for JCS to change all
> Serializables to Objects. I don't know wether they are in position to do
> such change (and wether they will want to do this change) or not.

I already posted a message to JCS developers:

http://nagoya.apache.org/eyebrowse/BrowseList?listName=turbine-jcs-dev@jakarta.apache.org&by=thread&from=769203

I hope it will be solved. :-D

Best Regards,

Antonio Gallardo

Re: Revert JCS, Re: XSP not working in CVS head?

[Unico Hommes <un...@hippo.nl>]

Vadim Gritsenko <vadim <at> reverycodes.com> writes:

> 
> >Vadim Gritsenko <vadim <at> reverycodes.com> writes:
> 
> I took a look at org.apache.jcs.access.CacheAccess, and it has 9 casts 
> to Serializable, even when not needed. And CacheElement object contains 
> two Serializables as key and value, not Objects.
> 

Plus the fact that JCS wraps the key and value in some kind of CacheElement
object that only accepts serializable objects... EHCache does the same.

--
Unico

Re: Revert JCS, Re: XSP not working in CVS head?

[Vadim Gritsenko <va...@reverycodes.com>]

Unico Hommes wrote:

>Vadim Gritsenko <vadim <at> reverycodes.com> writes:
>
>  
>
>>Unico Hommes wrote:
>>
>>It's acceptable only for *persistent* cache, but not for transient 
>>*object* cache. Cocoon requires transient cache for it to work 
>>(Templates caching etc), while persistent cache is optional.
>>
>>    
>>
>
>You are right. This should be the correct behavior. I am going to see how JCS
>can manage that and else see if EHCache manages it.
>  
>

I took a look at org.apache.jcs.access.CacheAccess, and it has 9 casts 
to Serializable, even when not needed. And CacheElement object contains 
two Serializables as key and value, not Objects.

It seems it will be extensive API change for JCS to change all 
Serializables to Objects. I don't know wether they are in position to do 
such change (and wether they will want to do this change) or not.

Vadim

Re: Revert JCS, Re: XSP not working in CVS head?

[Unico Hommes <un...@hippo.nl>]

Vadim Gritsenko <vadim <at> reverycodes.com> writes:

> 
> Unico Hommes wrote:
> 
> It's acceptable only for *persistent* cache, but not for transient 
> *object* cache. Cocoon requires transient cache for it to work 
> (Templates caching etc), while persistent cache is optional.
> 

You are right. This should be the correct behavior. I am going to see how JCS
can manage that and else see if EHCache manages it.

--
Unico

Re: Revert JCS, Re: XSP not working in CVS head?

[Ugo Cei <u....@cbim.it>]

Vadim Gritsenko wrote:
> Ok, but your original plan requires couple of changes due to ehcache 
> inability to store objects... EHCache can take place of PersistentStore, 
> but not Store or TransientStore.

Yes, this was my plan but it will have to be postponed until we resolve 
this issue with EHCache. In any case, what I would like to have is a 
_single_ store implementation with a minimum of configuration required. 
If this is based on JCS, EHCache or something new, I don't know and 
don't care, as long as it's the simplest.

	Ugo

Re: Revert JCS, Re: XSP not working in CVS head?

[Upayavira <uv...@upaya.co.uk>]

Vadim Gritsenko wrote:

> Ugo Cei wrote:
>
>>>> Vadim Gritsenko wrote:
>>>>
>>>>> Why then we need EHCache at all? MRUMemoryStore works well and 
>>>>> does not require extra jar files. What EHCache gives us?
>>>>
> ...
>
>> Overflowing to disk when the memory store fills, all with a single
>> implementation, IF you configure the disk store with a 
>> greater-than-zero size, which requires changing a parameter in 
>> cocoon.xconf, since - as shipped - it defaults to "memory only".
>>
>> Hope it is clearer, now :-).
>
> Ok, but your original plan requires couple of changes due to ehcache 
> inability to store objects... EHCache can take place of 
> PersistentStore, but not Store or TransientStore.

Apart from the fact that it doesn't persist through restarts, which our 
current implementation does. As I say, not so useful for servlets, 
extremely valuable for CLI, and I wouldn't like to loose that option.

Upayavira

Re: Revert JCS, Re: XSP not working in CVS head?

[Vadim Gritsenko <va...@reverycodes.com>]

Ugo Cei wrote:

> Vadim Gritsenko wrote:
>
>> Ugo Cei wrote:
>>
>>> Vadim Gritsenko wrote:
>>>
>>>> Why then we need EHCache at all? MRUMemoryStore works well and does 
>>>> not require extra jar files. What EHCache gives us?
>>>
...

> Overflowing to disk when the memory store fills, all with a single
> implementation, IF you configure the disk store with a 
> greater-than-zero size, which requires changing a parameter in 
> cocoon.xconf, since - as shipped - it defaults to "memory only".
>
> Hope it is clearer, now :-).


Ok, but your original plan requires couple of changes due to ehcache 
inability to store objects... EHCache can take place of PersistentStore, 
but not Store or TransientStore.

Vadim

Re: Revert JCS, Re: XSP not working in CVS head?

[Ugo Cei <u....@cbim.it>]

Vadim Gritsenko wrote:
> Ugo Cei wrote:
> 
>> Vadim Gritsenko wrote:
>>
>>> Why then we need EHCache at all? MRUMemoryStore works well and does 
>>> not require extra jar files. What EHCache gives us?
>>
>>
>>
>> Overflowing to disk when the memory store fills, all with a single 
>> implementation.
> 
> 
> 
> Please re-read email. You omitted a quote:
> 
>> 3) Configure EHCache with a ZERO-sized disk store.
> 
> 
> 
> 
> Now, assuming above, what does it give us?

Overflowing to disk when the memory store fills, all with a single
implementation, IF you configure the disk store with a greater-than-zero 
size, which requires changing a parameter in cocoon.xconf, since - as 
shipped - it defaults to "memory only".

Hope it is clearer, now :-).

	Ugo

Re: Revert JCS, Re: XSP not working in CVS head?

[Vadim Gritsenko <va...@reverycodes.com>]

Ugo Cei wrote:

> Vadim Gritsenko wrote:
>
>> Why then we need EHCache at all? MRUMemoryStore works well and does 
>> not require extra jar files. What EHCache gives us?
>
>
> Overflowing to disk when the memory store fills, all with a single 
> implementation.


Please re-read email. You omitted a quote:

> 3) Configure EHCache with a ZERO-sized disk store.



Now, assuming above, what does it give us?


Vadim

Re: Revert JCS, Re: XSP not working in CVS head?

[Ugo Cei <u....@cbim.it>]

Vadim Gritsenko wrote:
> Why then we need EHCache at all? MRUMemoryStore works well and does not 
> require extra jar files. What EHCache gives us?

Overflowing to disk when the memory store fills, all with a single 
implementation.

Well, that was my plan, but it seems to be harder than I hoped for.

	Ugo

Re: Revert JCS, Re: XSP not working in CVS head?

[Unico Hommes <un...@hippo.nl>]

Vadim Gritsenko <vadim <at> reverycodes.com> writes:

> Why then we need EHCache at all? MRUMemoryStore works well and does not 
> require extra jar files. What EHCache gives us?

Overflow to disk.

--
Unico

Re: Revert JCS, Re: XSP not working in CVS head?

[Vadim Gritsenko <va...@reverycodes.com>]

Ugo Cei wrote:

> Carsten Ziegeler wrote:
>
>> Now, the big question: does this work with EHCache?
>
>
...

> What I'd suggest to do at this point is:
>
> 1) Ship 2.1.5 with EHCache as the default store, configured with a 
> memory store large enough for at least running the samples with a 
> decent cache hit ratio.
> 2) Provide a few alternative, commented-out, configurations in 
> cocoon.xconf with estimates like: "If your JVM is started with 
> -Xmx256m use this value as a starting point".
> 3) Configure EHCache with a ZERO-sized disk store. What we're shipping 
> is a configuration suitable for first-time users, which don't need a 
> persistent store and should be shielded from having to configure it. 
> Expert users will know how to fine-tune their setup, if we document how.


Why then we need EHCache at all? MRUMemoryStore works well and does not 
require extra jar files. What EHCache gives us?

Vadim

Re: Revert JCS, Re: XSP not working in CVS head?

[Unico Hommes <un...@hippo.nl>]

Ugo Cei <u.cei <at> cbim.it> writes:

> 
> "The Disk Cache is not meant to be persistence mechanism. The data file 
> for each cache is deleted, if it exists, on startup. No data from a 
> previous instance of an application is persisted through the disk cache. 
>   The data file for each cache is also deleted on shutdown."
> 
> Given this, I'm afraid that both EHCache and JCS are not appropriate for 
> persisting objects like Logicsheet and Pagesheet to disk (I wonder how 
> JISP handles persisting non-serializable objects, in the first place).
> 

No Logicsheet and Pagesheet should NOT go into the persistent Store. The problem
we need to solve is the apparent requirement of both these packages that objects
need to implement Serializable even if we only want to cache them transiently.

> What I'd suggest to do at this point is:
> 
> 1) Ship 2.1.5 with EHCache as the default store, configured with a 
> memory store large enough for at least running the samples with a decent 
> cache hit ratio.

Either that or use JCS. For the problems we are considering it makes no diff. As
 the transient store we could use the current MRUMemoryStore so that components
such as XSP and Paginator won't break.

If you consider the "default" store role to be transient+persistent
Serializabitlity is a requirement for objects to store.

<snip otherwise gmane refuses to post it saying "new text is less than quoted
text..."/>

> 4) Drop the damn store janitor! I have the impression it's not needed 
> anymore. Please correct me if I'm wrong.

Is only used by org.apache.cocoon.components.store.impl.DefaultStore in order to
overflow org.apache.cocoon.components.store.impl.TransientStore to
o.a.c.c.s.i.PersistentStore . So if we use either JCS or EHCache as default
store it can be dropped, yes.

--
Unico

Re: Revert JCS, Re: XSP not working in CVS head?

[Ugo Cei <u....@cbim.it>]

Ugo Cei wrote:
> I don't advocate forking it unless it's the last resort. But if we must, 
> keep in mind that EHCache is just 11 classes (+2 for the Hibernate 
> plugin, which we don't need) with a comprehensive test suite, so if push 
> comes to shove, we would have no problems maintaining it ourselves.

By the way, EHCache 0.8 just came out with the following in the changelog:

"1. Modified the Apache license at the request of the Apache Cocoon 
project."

After this, I won't lobby for EHCache anymore, since I have no time to 
contribute actively. "He who does, decides" and if this means JCS, than 
let it be JCS.

	Ugo

Re: Revert JCS, Re: XSP not working in CVS head?

[Ugo Cei <u....@cbim.it>]

Antonio Gallardo wrote:
>>of luck unless we modify EHCache (shouldn't be too much work, but we
>>should ask the EHCache developers before doing a fork).
> 
> yet another fork? How many forks we will have for Cocoon:
> 
> Rhino
> Jisp (evaluated as a solution at a time).
> Now ehcache?
> 
> It is going to be very hard to mantain.... I think it is a bad idea.

Yes. It's a very bad idea. I'm sorry if I wasn't very clear. What I 
meant to say is: "we should ask the EHCache developers /instead of/ 
doing a fork".

I don't advocate forking it unless it's the last resort. But if we must, 
keep in mind that EHCache is just 11 classes (+2 for the Hibernate 
plugin, which we don't need) with a comprehensive test suite, so if push 
comes to shove, we would have no problems maintaining it ourselves.

	Ugo

Re: Revert JCS, Re: XSP not working in CVS head?

[Antonio Gallardo <ag...@agssa.net>]

Ugo Cei dijo:
> Ugo Cei wrote:
>> Carsten Ziegeler wrote:
>>
>>> Now, the big question: does this work with EHCache?
>> The documentation seems to imply that serializability is necessary only
>> for objects spooled to disk, but from looking at the source, I was
>
> I've checked and unfortunately, you can only add a
> net.sf.ehcache.Element to a cache, and all the constructors for Element
> take a Serializable as the type for the "value" parameter, so we're out
> of luck unless we modify EHCache (shouldn't be too much work, but we
> should ask the EHCache developers before doing a fork).

yet another fork? How many forks we will have for Cocoon:

Rhino
Jisp (evaluated as a solution at a time).
Now ehcache?

It is going to be very hard to mantain.... I think it is a bad idea.

Best Regards,

Antonio Gallardo

Re: Revert JCS, Re: XSP not working in CVS head?

[Ugo Cei <u....@cbim.it>]

Ugo Cei wrote:
> Carsten Ziegeler wrote:
> 
>> Now, the big question: does this work with EHCache?
> The documentation seems to imply that serializability is necessary only 
> for objects spooled to disk, but from looking at the source, I was 

I've checked and unfortunately, you can only add a 
net.sf.ehcache.Element to a cache, and all the constructors for Element 
take a Serializable as the type for the "value" parameter, so we're out 
of luck unless we modify EHCache (shouldn't be too much work, but we 
should ask the EHCache developers before doing a fork).

	Ugo

Re: Revert JCS, Re: XSP not working in CVS head?

[Ugo Cei <u....@cbim.it>]

Carsten Ziegeler wrote:
> Now, the big question: does this work with EHCache?

The documentation seems to imply that serializability is necessary only 
for objects spooled to disk, but from looking at the source, I was 
unable to ascertain what happens when an element is overflown from the 
memory store to the disk store. Probably it would be trivial to add a 
check and don't move the element to disk store if it's not an instance 
of Serializable.

BUT we should also consider this:

"The Disk Cache is not meant to be persistence mechanism. The data file 
for each cache is deleted, if it exists, on startup. No data from a 
previous instance of an application is persisted through the disk cache. 
  The data file for each cache is also deleted on shutdown."

Given this, I'm afraid that both EHCache and JCS are not appropriate for 
persisting objects like Logicsheet and Pagesheet to disk (I wonder how 
JISP handles persisting non-serializable objects, in the first place).

What I'd suggest to do at this point is:

1) Ship 2.1.5 with EHCache as the default store, configured with a 
memory store large enough for at least running the samples with a decent 
cache hit ratio.
2) Provide a few alternative, commented-out, configurations in 
cocoon.xconf with estimates like: "If your JVM is started with -Xmx256m 
use this value as a starting point".
3) Configure EHCache with a ZERO-sized disk store. What we're shipping 
is a configuration suitable for first-time users, which don't need a 
persistent store and should be shielded from having to configure it. 
Expert users will know how to fine-tune their setup, if we document how.
4) Drop the damn store janitor! I have the impression it's not needed 
anymore. Please correct me if I'm wrong.

	Ugo

RE: Revert JCS, Re: XSP not working in CVS head?

[Carsten Ziegeler <cz...@s-und-n.de>]

Vadim Gritsenko wrote:
> 
> Unico Hommes wrote:
> 
> >Carsten Ziegeler <cziegeler <at> s-und-n.de> writes:
> >
> >  
> >
> >>It seems this is due to the move to JCS :(
> >>
> >>The logicsheet is put into the cache and JCS casts this to 
> >>Serializable in org.apache.jcs.access.CacheAccess.put().
> >>
> >>So, what do we do now...
> >>
> >>    
> >>
> >
> >Yes, JCS requires objects to implement Serializable (quite 
> acceptable 
> >requirement for a cache ).
> >
> 
> It's acceptable only for *persistent* cache, but not for transient
> *object* cache. Cocoon requires transient cache for it to 
> work (Templates caching etc), while persistent cache is optional.
> 
> 
> >The same problem occurred with Pagesheet from the Paginator 
> >transformer. I've made both Logicsheet and Pagesheet implement 
> >Serializable. Alternatively we could let the JCSStore implementation 
> >check whether the object to store implements Serializable and if not 
> >wrap the object in a Serializable wrapper (at the cost of 
> some performance).
> >
> 
> What purpose would that serve? It will store empty wrappers 
> on the hard drive and retrieve those empty wrappers and hand 
> over back to Cocoon, and all kinds of failures 
> (NullPointerExceptions) will start happening all over the place.
> 
> The only viable solution currently is rollback to Excalibur's 
> memory cache - unless JCS becomes something which can work as 
> in-memory object cache (with optional overflow to disk).
> 
Yepp, I agree with Vadim here. A transient cache should store
more than just Serializable objects.

Now, the big question: does this work with EHCache?

Carsten