[jira] Closed: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys

[Antonio Gallardo (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1885?page=all ]

Antonio Gallardo closed COCOON-1885.


Fix Version/s: 2.2-dev (Current SVN)
   2.1.10-dev (current SVN)
   Resolution: Fixed

Thanks for the patch. It was applied with minor changes. Feel free to reopen 
the issue if needed.

> The EHDefaultStore returns in the size() method the wrong number of keys
> 
>
> Key: COCOON-1885
> URL: http://issues.apache.org/jira/browse/COCOON-1885
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.1.9
>Reporter: Ard Schrijvers
> Assigned To: Antonio Gallardo
>Priority: Critical
> Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
>
> Attachments: EHDefaultStore.patch
>
>
> The excalibut store interface defines a size() method for a store: 
> /**
>  * Returns count of the objects in the store, or -1 if could not be
>  * obtained.
>  */
> int size();
> What it not explicitely says, is that it is the number of keys in memoryStore 
> (so not the diskStore) is needed. The StoreJanitor uses this size() to free 
> some memory from cache when the JVM is low on memory. Since the current 
> EHDefaultStore returns with size() ALL cachekeys (memoryStoreSize + 
> diskStoreSize), it is quite likely when having a large cache that the 
> StoreJanitor removes all cachekeys in memoryStore. Simply changing the size() 
> method of EHDefaultStore to return the number of keys in memoryStore is 
> sufficient.  The JCSDefaultStore did implement it correctly already (though I 
> do not see it in the cocoon trunk anymore..?)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[continuum] BUILD FAILURE: Portal Block Sample

[[EMAIL PROTECTED]]

Online report : 
http://localhost:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/206/buildId/414
Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Wed, 26 Jul 2006 03:26:45 +
  Finished at: Wed, 26 Jul 2006 03:28:01 +
  Total time: 1m 15s
  Build Trigger: Schedule
  Exit code: 1
  Building machine hostname: cocoon.zones.apache.org
  Operating system : SunOS(unknown)
  Java version : 1.4.2_06(Sun Microsystems Inc.)

Changes
 cziegeler  Create new portal auth block to host the portal 
related stuff from the cauth block
 /cocoon/trunk/blocks/cocoon-portal/cocoon-portal-auth-imp
/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-auth-imp/pom.xml
/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-auth-imp/src
/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-auth-imp/src/main

/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-auth-imp/src/main/java
/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-sample/pom.xml
/cocoon/trunk/blocks/cocoon-portal/pom.xml
   cziegeler  Fix portal sample
 
/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portal/persistence/castor/CastorSourceConverter.java

/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-sample/src/main/resources/COB-INF/profiles/copletdata/portal.xml

/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-sample/src/main/resources/COB-INF/profiles/copletinstancedata/portal-user-cocoon.xml

/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-sample/src/main/resources/COB-INF/profiles/layout/portal-user-cocoon.xml
   cziegeler  Cleanup
 
/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portal/event/subscriber

/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portal/factory

/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portal/resources

/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portlet
/cocoon/trunk/blocks/cocoon-portal/cocoon-portal-sample/pom.xml


Output:

[INFO] Scanning for projects...
[INFO] 

[INFO] Building Portal Block Sample
[INFO]task-segment: [clean, install]
[INFO] 

[INFO] [clean:clean]
[INFO] Deleting directory 
/home/maven/continuum-1.0.3/apps/continuum/working-directory/206/target
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading: 
http://ibiblio.org/maven2/org/springframework/spring-core/2.0-rc2/spring-core-2.0-rc2.pom
[WARNING] Unable to get resource from repository central 
(http://ibiblio.org/maven2)
Downloading: 
http://svn.apache.org/maven-snapshot-repository/org/springframework/spring-core/2.0-rc2/spring-core-2.0-rc2.pom
[WARNING] Unable to get resource from repository apache.snapshot 
(http://svn.apache.org/maven-snapshot-repository)
Downloading: 
http://svn.apache.org/repository/org.springframework/poms/spring-core-2.0-rc2.pom
[WARNING] Unable to get resource from repository apache-cvs 
(http://svn.apache.org/repository)
Downloading: 
http://ibiblio.org/maven2/org/springframework/spring-beans/2.0-rc2/spring-beans-2.0-rc2.pom
[WARNING] Unable to get resource from repository central 
(http://ibiblio.org/maven2)
Downloading: 
http://svn.apache.org/maven-snapshot-repository/org/springframework/spring-beans/2.0-rc2/spring-beans-2.0-rc2.pom
[WARNING] Unable to get resource from repository apache.snapshot 
(http://svn.apache.org/maven-snapshot-repository)
Downloading: 
http://svn.apache.org/repository/org.springframework/poms/spring-beans-2.0-rc2.pom
[WARNING] Unable to get resource from repository apache-cvs 
(http://svn.apache.org/repository)
Downloading: 
http://ibiblio.org/maven2/org/springframework/spring-web/2.0-rc2/spring-web-2.0-rc2.pom
[WARNING] Unable to get resource from repository central 
(http://ibiblio.org/maven2)
Downloading: 
http://svn.apache.org/maven-snapshot-repository/org/springframework/spring-web/2.0-rc2/spring-web-2.0-rc2.pom
[WARNING] Unable to get resource from repository apache.snapshot 
(http://svn.apache.org/maven-snapshot-repository)
Downloading: 
http://svn.apache.org/repository/org.springframework/poms/spring-web-2.0-rc2.pom
[WARNING] Unable to get resource from repository apache-cvs 
(http://svn.apache.org/repository)
Downloading: 
http://ibiblio.org/maven2/org/springframework/spring-aop/2.0-rc2/spring-aop-2.0-rc2.pom
[WARNING] Unable to get resource from repository central 
(http://ibi

Another docs question...

[Mark Lundquist]

Are the docs on the Daisy site for 2.2, or for 2.1.X?

I think I read somewhere just recently that they're for 2.2.  It might 
have been in one of Bruno's replies to one of my questions... :-)  but 
I can't rememeber...


—ml—

Compiling classloader

[Mark Lundquist]

Didn't there used to be a compiling classloader way back in the day, 
like, 2.1.4?  Or am I hepped up on goofballs?

—ml—

Re: [jira] Created: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys

[Antonio Gallardo]

Ard Schrijvers escribió:


  

If there are better alternatives to ehcache we should consider them of
course. Personally I would like that this work will be done in trunk
only. We could build an own maven project for each cache 
implementation

which will reduce the dependencies for a user and makes
switching/choosing fairly easy.

But if we provide alternatives we should have at least some guidelines
explaining when to choose which implementation.



I will try to see if whirlycache meets our goals better (especially I want to look at the way the diskStore behaves (I want to be able to limit the diskStore keys), and wether we can access the eviction policy from within our classes, to be able to free some memory from cache in a sensible way). I think those guidelines should be in the document I am planning (sry...still in planning phase) to write on caching and best practices. Also the many store configurations, in which errors are easily made should be (will be I hope) documented transparently. 
  

From your provided link [1], the last section said:

"JCS limits the number of keys that can be kept for the disk cache. EH 
cannot do this."




I am not sure if supporting many cache implementation is good practice. If 
there is a large difference between the caches, where cache1 performs much 
better in memoryStore, and cache2 much better in diskStore, and cache3 is 
avergae in both, then I suppose supporting different caches might be a good 
option (though, an easy lookup of which cache impl suits your app best should 
be available. Then again, this documentation ofcourse is outdated after every 
cache impl release)
  
Dunno too, but from a practicl POV, supporting different caches would 
make easier to use the same cache in combination with other libraries. 
ie: Apache ojb or hibernate. For this reason, I am +1 to support 
different caches. ;-)


Best Regards,

Antonio Gallardo.

[1] http://jakarta.apache.org/jcs/JCSvsEHCache.html
  

RE: [jira] Created: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys

[Ard Schrijvers]

> 
> If there are better alternatives to ehcache we should consider them of
> course. Personally I would like that this work will be done in trunk
> only. We could build an own maven project for each cache 
> implementation
> which will reduce the dependencies for a user and makes
> switching/choosing fairly easy.
> 
> But if we provide alternatives we should have at least some guidelines
> explaining when to choose which implementation.

I will try to see if whirlycache meets our goals better (especially I want to 
look at the way the diskStore behaves (I want to be able to limit the diskStore 
keys), and wether we can access the eviction policy from within our classes, to 
be able to free some memory from cache in a sensible way). I think those 
guidelines should be in the document I am planning (sry...still in planning 
phase) to write on caching and best practices. Also the many store 
configurations, in which errors are easily made should be (will be I hope) 
documented transparently. 

I am not sure if supporting many cache implementation is good practice. If 
there is a large difference between the caches, where cache1 performs much 
better in memoryStore, and cache2 much better in diskStore, and cache3 is 
avergae in both, then I suppose supporting different caches might be a good 
option (though, an easy lookup of which cache impl suits your app best should 
be available. Then again, this documentation ofcourse is outdated after every 
cache impl release)

I hope to see one cache being superior in every facet. That would make choices 
easiest.

Regards Ard

> 
> 
> Carsten
> -- 
> Carsten Ziegeler - Open Source Group, S&N AG
> http://www.s-und-n.de
> http://www.osoco.org/weblogs/rael/
> 

Re: [jira] Created: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys

[Carsten Ziegeler]

Antonio Gallardo wrote:
> Ard Schrijvers escribió:
>> Thx!!
>>
>> You do not happen to know where the JCSDefaultStore went in trunk..?? I read 
>> some stuff about it outperforming ehcache in almost every way (and that it 
>> might be easier to implement the eviction policy driven freeing of 
>> cachekeys).
>>   
> WARINIG: I am far to be a cocoon expert. I guess Carsten may answer this 
> question a long way better than me.  But let me do a try digging into my 
> memory:
> 
:)

As Antonio outlined, the switch to JCS at that time was a bad idea; it
had several problems, so we switched to ehcache.
Now, Cocoon is using far too many other open source projects and we often
provide several alternatives for a specific problem without providing
good guidelines on what to use when. That's the main reason why we
decided later on to remove the old JCS code from trunk. But the code is
still in the 2.1.x branch, so it shouldn't be a problem to reactivate it
for trunk; it should run there without changes anyway.

If there are better alternatives to ehcache we should consider them of
course. Personally I would like that this work will be done in trunk
only. We could build an own maven project for each cache implementation
which will reduce the dependencies for a user and makes
switching/choosing fairly easy.

But if we provide alternatives we should have at least some guidelines
explaining when to choose which implementation.


Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [jira] Created: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys

[Antonio Gallardo]

Ard Schrijvers escribió:
You do not happen to know where the JCSDefaultStore went in 
  
trunk..?? I read some stuff about it outperforming ehcache in 
almost every way (and that it might be easier to implement 
the eviction policy driven freeing of cachekeys).

  
  
WARINIG: I am far to be a cocoon expert. I guess Carsten may 
answer this 
question a long way better than me.  But let me do a try 
digging into my 
memory:


Apache JCS based cocoon cache was introduced as a replacement 
for jisp 
[1], we dropped out jisp based cache because the jisp owner 
changed his 
license in the newer versions and there were some big flaws 
in the jisp 
version used in cocoon. At that time, JCS was not the cache 
nirvana, but 
we saw it as a nice fast repleacement, because it was under the same 
apache umbrella. JCS had some problems too (problems that I 
don't know 
if they are already fixed now - but I hope so. One of the 
problems with 
JCS is that his community is very small (very few developers - 3 or 
less), because JCS is the kind of projects that everybody 
wants to use 
and nobody wants to develop. You know. ;-)



It merely surprised me because I just read http://jakarta.apache.org/jcs/JCSvsEHCache.html, but of course, I did not measure it myself :-) 
  
Thanks for the link. JCS 1.2.7 was used for the benchmark. IIRC, in 
cocoon the least used jcs version was 1.2.5. Based on my jcs experience, 
a 1.2.7 release is not just a simple bug fixing release, there are some 
enhancements. Hence a good idea try jcs 1.2.7 or a jcs newer version.
  
At the same time ehcache was emerging as a new kid on the 
cache block. 
Everybody talked about it, how faster ehcache is and so on. AFAIK, 
basically ehcache origin is a stripped down forked old 
version of Apache 
JCS . Thanks to some cocoon community request, ehcache 
community agreed 
to have a dual license using ASF and this allowed us to use 
his library 
in cocoon. This is how the ehcache got into cocoon as another cache 
implementation.


Few cocoon releases ago, due the (memory leaks?) problems in 
apache jcs 
base cache, the cocoon community decided to switch to ehcache as our 
default implementation. As part of the new idea to strip down 
cocoon to 
avoid confusing users, the JCS based cache support has been 
droppped out.


Now, given the current situation, I wonder if was a smart 
move to remove 
the jcs cache based cache implementation from cocoon at all. 
Perhaps we 
might keep it into our code as another implementation and let 
the user 
decide wich one use. Do you think makes sense to ask our 
community if we 
can continue supporting jcs-base cache?


I hear there is another very interesting cache implementation. It is 
called whirlycache[2], but there is no cocoon support yet. 
Perhaps makes 
sense to give him a try.** 



Quite a nice historical overview! I certainly consider it worthy to check out this 
whirlycache. In the first place, I like this principle that says "Disk overflow 
becomes a bad idea very quickly". We have sites around consuming multiple Gb of 
diskStore with ehcache, this afternoon I stumbled apon a site having 25.000+ cachekeys 
(combination of an old EHDefaultStore impl not implementing [EMAIL PROTECTED] though), 
etc etc. This in combination with the StoreJanitor trying to free memory from caches when 
low on memory, but the EHDefaultStore or JCSDefaultStore are not capable of doing this 
according the correct eviction policy, makes that for us the cache implementations have 
to many short comings. Turning overflow-to-disk to false for sites seem to let them run 
more stable! But then I could use MRUMemoryStore as well, and throw away ehcache. Another 
problem with ehcache is that you cannot set a limit to the number of keys in diskStore. 
This number can grow indefinetly.

I am going to check out if the wirlycache does not have this short comings.
  
It sounds great! Please share with us your experience with whirlycache. 
I hear some folks from Lenya already used it with very nice results. If 
this is the same for you, please consider to provide a patch to include 
it in our nice framework. ;-)


Many thanks in advance.

Best Regards,

Antonio Gallardo

RE: [jira] Created: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys

[Ard Schrijvers]

> > You do not happen to know where the JCSDefaultStore went in 
> trunk..?? I read some stuff about it outperforming ehcache in 
> almost every way (and that it might be easier to implement 
> the eviction policy driven freeing of cachekeys).
> >   
> WARINIG: I am far to be a cocoon expert. I guess Carsten may 
> answer this 
> question a long way better than me.  But let me do a try 
> digging into my 
> memory:
> 
> Apache JCS based cocoon cache was introduced as a replacement 
> for jisp 
> [1], we dropped out jisp based cache because the jisp owner 
> changed his 
> license in the newer versions and there were some big flaws 
> in the jisp 
> version used in cocoon. At that time, JCS was not the cache 
> nirvana, but 
> we saw it as a nice fast repleacement, because it was under the same 
> apache umbrella. JCS had some problems too (problems that I 
> don't know 
> if they are already fixed now - but I hope so. One of the 
> problems with 
> JCS is that his community is very small (very few developers - 3 or 
> less), because JCS is the kind of projects that everybody 
> wants to use 
> and nobody wants to develop. You know. ;-)

It merely surprised me because I just read 
http://jakarta.apache.org/jcs/JCSvsEHCache.html, but of course, I did not 
measure it myself :-) 

> 
> At the same time ehcache was emerging as a new kid on the 
> cache block. 
> Everybody talked about it, how faster ehcache is and so on. AFAIK, 
> basically ehcache origin is a stripped down forked old 
> version of Apache 
> JCS . Thanks to some cocoon community request, ehcache 
> community agreed 
> to have a dual license using ASF and this allowed us to use 
> his library 
> in cocoon. This is how the ehcache got into cocoon as another cache 
> implementation.
> 
> Few cocoon releases ago, due the (memory leaks?) problems in 
> apache jcs 
> base cache, the cocoon community decided to switch to ehcache as our 
> default implementation. As part of the new idea to strip down 
> cocoon to 
> avoid confusing users, the JCS based cache support has been 
> droppped out.
> 
> Now, given the current situation, I wonder if was a smart 
> move to remove 
> the jcs cache based cache implementation from cocoon at all. 
> Perhaps we 
> might keep it into our code as another implementation and let 
> the user 
> decide wich one use. Do you think makes sense to ask our 
> community if we 
> can continue supporting jcs-base cache?
> 
> I hear there is another very interesting cache implementation. It is 
> called whirlycache[2], but there is no cocoon support yet. 
> Perhaps makes 
> sense to give him a try.** 

Quite a nice historical overview! I certainly consider it worthy to check out 
this whirlycache. In the first place, I like this principle that says "Disk 
overflow becomes a bad idea very quickly". We have sites around consuming 
multiple Gb of diskStore with ehcache, this afternoon I stumbled apon a site 
having 25.000+ cachekeys (combination of an old EHDefaultStore impl not 
implementing [EMAIL PROTECTED] though), etc etc. This in combination with the 
StoreJanitor trying to free memory from caches when low on memory, but the 
EHDefaultStore or JCSDefaultStore are not capable of doing this according the 
correct eviction policy, makes that for us the cache implementations have to 
many short comings. Turning overflow-to-disk to false for sites seem to let 
them run more stable! But then I could use MRUMemoryStore as well, and throw 
away ehcache. Another problem with ehcache is that you cannot set a limit to 
the number of keys in diskStore. This number can grow indefinetly.

I am going to check out if the wirlycache does not have this short comings.

Thx pointing it out,

Regards Ard

> 
> Best Regards,
> 
> Antonio Gallardo
> 
> [1] http://www.coyotegulch.com/products/jisp/
> [2] https://whirlycache.dev.java.net/
> > Regards Ard 
> >
> >   > 

Building Trunk from snapshot tar

[Martin Geissler]

Hello,
today I have successfully build cocoon tunk (2.2).

This was a hard work for me, so I want to show some pointers for
others.
Perhaps someone will find this usefull.

My OS: Windows XP Pro
JAVA : Sun jdk 1.4.2_11
Maven 2.0.4
cocoon: cocoon_20060724041732.tar.gz

Step one maven:
configured the proxy,
configured anti virus scanner (java was not allowed to connect to the
internet)
configured mirror as described in readme.txt
Tried a little example from the maven tutorial, worked.

Step two: the cocoon*.tar.gz file:
Do not try to work with the tool filzip, won't work!
It seems that you got some folders out and no error messages, but the
folder structure is 
not applicable for maven to do something right.
After some guessing I tried it wit GNUTar to Un-tar the tar file.
The folder structure is correct now, but the last letters from some
filenames are dropped!?
Example: Something.jav instead of Something.java,
also occures with: *.xma, *.xs, *.j, *.xm -files (Right should be
*.xmap, *.xsl, *.js, *.xml)
(Perhaps GNUTar is also not the correct tool?)

After correcting most of this misspelled file-names, 
mvn -Dmaven.test.skip=true install 
mvn cocoon:deploy
and 
mvn jetty6:run
worked!

After a first look I have  found this message 
FATAL: Could not load 'cocoon.forms.CFormsForm'; last tried
'__package__.js'
at this side
http://localhost:/blocks/cocoon-forms-sample/form1
But today I have no more time to investigate this further.

Regards

Martin

Re: [jira] Created: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys

[Antonio Gallardo]

Ard Schrijvers escribió:

Thx!!

You do not happen to know where the JCSDefaultStore went in trunk..?? I read 
some stuff about it outperforming ehcache in almost every way (and that it 
might be easier to implement the eviction policy driven freeing of cachekeys).
  
WARINIG: I am far to be a cocoon expert. I guess Carsten may answer this 
question a long way better than me.  But let me do a try digging into my 
memory:


Apache JCS based cocoon cache was introduced as a replacement for jisp 
[1], we dropped out jisp based cache because the jisp owner changed his 
license in the newer versions and there were some big flaws in the jisp 
version used in cocoon. At that time, JCS was not the cache nirvana, but 
we saw it as a nice fast repleacement, because it was under the same 
apache umbrella. JCS had some problems too (problems that I don't know 
if they are already fixed now - but I hope so. One of the problems with 
JCS is that his community is very small (very few developers - 3 or 
less), because JCS is the kind of projects that everybody wants to use 
and nobody wants to develop. You know. ;-)


At the same time ehcache was emerging as a new kid on the cache block. 
Everybody talked about it, how faster ehcache is and so on. AFAIK, 
basically ehcache origin is a stripped down forked old version of Apache 
JCS . Thanks to some cocoon community request, ehcache community agreed 
to have a dual license using ASF and this allowed us to use his library 
in cocoon. This is how the ehcache got into cocoon as another cache 
implementation.


Few cocoon releases ago, due the (memory leaks?) problems in apache jcs 
base cache, the cocoon community decided to switch to ehcache as our 
default implementation. As part of the new idea to strip down cocoon to 
avoid confusing users, the JCS based cache support has been droppped out.


Now, given the current situation, I wonder if was a smart move to remove 
the jcs cache based cache implementation from cocoon at all. Perhaps we 
might keep it into our code as another implementation and let the user 
decide wich one use. Do you think makes sense to ask our community if we 
can continue supporting jcs-base cache?


I hear there is another very interesting cache implementation. It is 
called whirlycache[2], but there is no cocoon support yet. Perhaps makes 
sense to give him a try.** 


Best Regards,

Antonio Gallardo

[1] http://www.coyotegulch.com/products/jisp/
[2] https://whirlycache.dev.java.net/
Regards Ard 

  

Thanks Ard. I will apply this patch today after work. :-)

Best Regards,

Antonio Gallardo

Ard Schrijvers escribió:

This is a partial fix of a larger problem that I am not yet 
  
capable of fixing: removing cachekeys according the correct 
eviction policy. 

This fix at least fixes the flaw, that the StoreJanitor 
  
could delete the entire memoryStore part from ehcache. In the 
JCSDefaultStore, this size() method was already correct. I 
just noticed, that JCSDefaultStore is not in the cocoon trunk 
anymore. Is there specific reason for it? Did it move?


Regards Ard Schrijvers

  
  
The EHDefaultStore returns in the size() method the wrong 
number of keys

--
--

 Key: COCOON-1885
 URL: 


http://issues.apache.org/jira/browse/COCOON-1885


 Project: Cocoon
  Issue Type: Bug
  Components: * Cocoon Core
Affects Versions: 2.1.9
Reporter: Ard Schrijvers
Priority: Critical


The excalibut store interface defines a size() method for a store: 


/**
 * Returns count of the objects in the store, or -1 if 
could not be

 * obtained.
 */
int size();

What it not explicitely says, is that it is the number of 
keys in memoryStore (so not the diskStore) is needed. The 
StoreJanitor uses this size() to free some memory from cache 
when the JVM is low on memory. Since the current 
EHDefaultStore returns with size() ALL cachekeys 
(memoryStoreSize + diskStoreSize), it is quite likely when 
having a large cache that the StoreJanitor removes all 
cachekeys in memoryStore. Simply changing the size() method 
of EHDefaultStore to return the number of keys in memoryStore 
is sufficient.  The JCSDefaultStore did implement it 
correctly already (though I do not see it in the cocoon trunk 
anymore..?)






--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the 
administrators: 



http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: 
  

http://www.atlassian.com/software/jira


  
  

RE: [jira] Created: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys

[Ard Schrijvers]

Thx!!

You do not happen to know where the JCSDefaultStore went in trunk..?? I read 
some stuff about it outperforming ehcache in almost every way (and that it 
might be easier to implement the eviction policy driven freeing of cachekeys).

Regards Ard 

> 
> 
> Thanks Ard. I will apply this patch today after work. :-)
> 
> Best Regards,
> 
> Antonio Gallardo
> 
> Ard Schrijvers escribió:
> > This is a partial fix of a larger problem that I am not yet 
> capable of fixing: removing cachekeys according the correct 
> eviction policy. 
> >
> > This fix at least fixes the flaw, that the StoreJanitor 
> could delete the entire memoryStore part from ehcache. In the 
> JCSDefaultStore, this size() method was already correct. I 
> just noticed, that JCSDefaultStore is not in the cocoon trunk 
> anymore. Is there specific reason for it? Did it move?
> >
> > Regards Ard Schrijvers
> >
> >   
> >> The EHDefaultStore returns in the size() method the wrong 
> >> number of keys
> >> --
> >> --
> >>
> >>  Key: COCOON-1885
> >>  URL: 
> http://issues.apache.org/jira/browse/COCOON-1885
> >>  Project: Cocoon
> >>   Issue Type: Bug
> >>   Components: * Cocoon Core
> >> Affects Versions: 2.1.9
> >> Reporter: Ard Schrijvers
> >> Priority: Critical
> >>
> >>
> >> The excalibut store interface defines a size() method for a store: 
> >>
> >> /**
> >>  * Returns count of the objects in the store, or -1 if 
> >> could not be
> >>  * obtained.
> >>  */
> >> int size();
> >>
> >> What it not explicitely says, is that it is the number of 
> >> keys in memoryStore (so not the diskStore) is needed. The 
> >> StoreJanitor uses this size() to free some memory from cache 
> >> when the JVM is low on memory. Since the current 
> >> EHDefaultStore returns with size() ALL cachekeys 
> >> (memoryStoreSize + diskStoreSize), it is quite likely when 
> >> having a large cache that the StoreJanitor removes all 
> >> cachekeys in memoryStore. Simply changing the size() method 
> >> of EHDefaultStore to return the number of keys in memoryStore 
> >> is sufficient.  The JCSDefaultStore did implement it 
> >> correctly already (though I do not see it in the cocoon trunk 
> >> anymore..?)
> >>
> >>
> >>
> >>
> >>
> >> -- 
> >> This message is automatically generated by JIRA.
> >> -
> >> If you think it was sent incorrectly contact one of the 
> >> administrators: 
> >> 
> > http://issues.apache.org/jira/secure/Administrators.jspa
> > -
> > For more information on JIRA, see: 
> http://www.atlassian.com/software/jira
> >
> > 
> >   
> 
> 

[jira] Assigned: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys

[Antonio Gallardo (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1885?page=all ]

Antonio Gallardo reassigned COCOON-1885:


Assignee: Antonio Gallardo

> The EHDefaultStore returns in the size() method the wrong number of keys
> 
>
> Key: COCOON-1885
> URL: http://issues.apache.org/jira/browse/COCOON-1885
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.1.9
>Reporter: Ard Schrijvers
> Assigned To: Antonio Gallardo
>Priority: Critical
> Attachments: EHDefaultStore.patch
>
>
> The excalibut store interface defines a size() method for a store: 
> /**
>  * Returns count of the objects in the store, or -1 if could not be
>  * obtained.
>  */
> int size();
> What it not explicitely says, is that it is the number of keys in memoryStore 
> (so not the diskStore) is needed. The StoreJanitor uses this size() to free 
> some memory from cache when the JVM is low on memory. Since the current 
> EHDefaultStore returns with size() ALL cachekeys (memoryStoreSize + 
> diskStoreSize), it is quite likely when having a large cache that the 
> StoreJanitor removes all cachekeys in memoryStore. Simply changing the size() 
> method of EHDefaultStore to return the number of keys in memoryStore is 
> sufficient.  The JCSDefaultStore did implement it correctly already (though I 
> do not see it in the cocoon trunk anymore..?)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] Created: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys

[Antonio Gallardo]

Thanks Ard. I will apply this patch today after work. :-)

Best Regards,

Antonio Gallardo

Ard Schrijvers escribió:
This is a partial fix of a larger problem that I am not yet capable of fixing: removing cachekeys according the correct eviction policy. 


This fix at least fixes the flaw, that the StoreJanitor could delete the entire 
memoryStore part from ehcache. In the JCSDefaultStore, this size() method was 
already correct. I just noticed, that JCSDefaultStore is not in the cocoon 
trunk anymore. Is there specific reason for it? Did it move?

Regards Ard Schrijvers

  
The EHDefaultStore returns in the size() method the wrong 
number of keys

--
--

 Key: COCOON-1885
 URL: http://issues.apache.org/jira/browse/COCOON-1885
 Project: Cocoon
  Issue Type: Bug
  Components: * Cocoon Core
Affects Versions: 2.1.9
Reporter: Ard Schrijvers
Priority: Critical


The excalibut store interface defines a size() method for a store: 


/**
 * Returns count of the objects in the store, or -1 if 
could not be

 * obtained.
 */
int size();

What it not explicitely says, is that it is the number of 
keys in memoryStore (so not the diskStore) is needed. The 
StoreJanitor uses this size() to free some memory from cache 
when the JVM is low on memory. Since the current 
EHDefaultStore returns with size() ALL cachekeys 
(memoryStoreSize + diskStoreSize), it is quite likely when 
having a large cache that the StoreJanitor removes all 
cachekeys in memoryStore. Simply changing the size() method 
of EHDefaultStore to return the number of keys in memoryStore 
is sufficient.  The JCSDefaultStore did implement it 
correctly already (though I do not see it in the cocoon trunk 
anymore..?)






--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the 
administrators: 


http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira


  

Re: Add mime-type application/xhtml+xml to StreamGenerator

[Michael Wechner]

Jorg Heymans wrote:


On 7/22/06 11:54 AM, in article [EMAIL PROTECTED], "Michael
Wechner" <[EMAIL PROTECTED]> wrote:

 


Project ID: batik:batik-script

Reason: Error getting POM for 'batik:batik-script' from the repository:
Error transferring file
 batik:batik-script:pom:1.6

from the specified remote repositories:
 central (http://ibiblio.org/maven2),
 apache.snapshots (http://svn.apache.org/maven-snapshot-repository),
 apache.snapshot (http://svn.apache.org/maven-snapshot-repository),
 apache-cvs (http://svn.apache.org/repository)

   



I'ld say ibiblio has timed out on you again. Better use a european mirror
for doing builds, like eg mirrors.dotsrc.org.
 



thanks for the hint

Michi



Jorg



 




--
Michael Wechner
Wyona  -   Open Source Content Management   -Apache Lenya
http://www.wyona.com  http://lenya.apache.org
[EMAIL PROTECTED][EMAIL PROTECTED]
+41 44 272 91 61

RE: [jira] Created: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys

[Ard Schrijvers]

This is a partial fix of a larger problem that I am not yet capable of fixing: 
removing cachekeys according the correct eviction policy. 

This fix at least fixes the flaw, that the StoreJanitor could delete the entire 
memoryStore part from ehcache. In the JCSDefaultStore, this size() method was 
already correct. I just noticed, that JCSDefaultStore is not in the cocoon 
trunk anymore. Is there specific reason for it? Did it move?

Regards Ard Schrijvers

> 
> The EHDefaultStore returns in the size() method the wrong 
> number of keys
> --
> --
> 
>  Key: COCOON-1885
>  URL: http://issues.apache.org/jira/browse/COCOON-1885
>  Project: Cocoon
>   Issue Type: Bug
>   Components: * Cocoon Core
> Affects Versions: 2.1.9
> Reporter: Ard Schrijvers
> Priority: Critical
> 
> 
> The excalibut store interface defines a size() method for a store: 
> 
> /**
>  * Returns count of the objects in the store, or -1 if 
> could not be
>  * obtained.
>  */
> int size();
> 
> What it not explicitely says, is that it is the number of 
> keys in memoryStore (so not the diskStore) is needed. The 
> StoreJanitor uses this size() to free some memory from cache 
> when the JVM is low on memory. Since the current 
> EHDefaultStore returns with size() ALL cachekeys 
> (memoryStoreSize + diskStoreSize), it is quite likely when 
> having a large cache that the StoreJanitor removes all 
> cachekeys in memoryStore. Simply changing the size() method 
> of EHDefaultStore to return the number of keys in memoryStore 
> is sufficient.  The JCSDefaultStore did implement it 
> correctly already (though I do not see it in the cocoon trunk 
> anymore..?)
> 
> 
> 
> 
> 
> -- 
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the 
> administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys

[Ard Schrijvers (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1885?page=all ]

Ard Schrijvers updated COCOON-1885:
---

Attachment: EHDefaultStore.patch

Fix for EHDefaultStore returning wrong number in the size() method

> The EHDefaultStore returns in the size() method the wrong number of keys
> 
>
> Key: COCOON-1885
> URL: http://issues.apache.org/jira/browse/COCOON-1885
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.1.9
>Reporter: Ard Schrijvers
>Priority: Critical
> Attachments: EHDefaultStore.patch
>
>
> The excalibut store interface defines a size() method for a store: 
> /**
>  * Returns count of the objects in the store, or -1 if could not be
>  * obtained.
>  */
> int size();
> What it not explicitely says, is that it is the number of keys in memoryStore 
> (so not the diskStore) is needed. The StoreJanitor uses this size() to free 
> some memory from cache when the JVM is low on memory. Since the current 
> EHDefaultStore returns with size() ALL cachekeys (memoryStoreSize + 
> diskStoreSize), it is quite likely when having a large cache that the 
> StoreJanitor removes all cachekeys in memoryStore. Simply changing the size() 
> method of EHDefaultStore to return the number of keys in memoryStore is 
> sufficient.  The JCSDefaultStore did implement it correctly already (though I 
> do not see it in the cocoon trunk anymore..?)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys

[Ard Schrijvers (JIRA)]

The EHDefaultStore returns in the size() method the wrong number of keys


 Key: COCOON-1885
 URL: http://issues.apache.org/jira/browse/COCOON-1885
 Project: Cocoon
  Issue Type: Bug
  Components: * Cocoon Core
Affects Versions: 2.1.9
Reporter: Ard Schrijvers
Priority: Critical


The excalibut store interface defines a size() method for a store: 

/**
 * Returns count of the objects in the store, or -1 if could not be
 * obtained.
 */
int size();

What it not explicitely says, is that it is the number of keys in memoryStore 
(so not the diskStore) is needed. The StoreJanitor uses this size() to free 
some memory from cache when the JVM is low on memory. Since the current 
EHDefaultStore returns with size() ALL cachekeys (memoryStoreSize + 
diskStoreSize), it is quite likely when having a large cache that the 
StoreJanitor removes all cachekeys in memoryStore. Simply changing the size() 
method of EHDefaultStore to return the number of keys in memoryStore is 
sufficient.  The JCSDefaultStore did implement it correctly already (though I 
do not see it in the cocoon trunk anymore..?)





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira