Ard Schrijvers wrote:
1) How it works and its intention (I think :-) ): The StoreJanitor is
originally invented to monitor cocoon's memory useage and does this by
checking some memory values every X (default 10) seconds. Beside the fact
that I doubt users know that it is quite important to
Vadim,
I think you are reasoning from a POV of the cocoon cache, but I think you are
in the minority compared to the number of users which are using EHCache.
I tried to explain the inevitable OOM of the StoreJanitor in combination of
EHCache and
the event registry in a high volume site.
Ard Schrijvers wrote:
Vadim,
I think you are reasoning from a POV of the cocoon cache, but I think you are
in the minority compared to the number of users which are using EHCache.
Yes because it is stable and works better and at the time I last looked into it
JCS was really not an option
Configurable Store registration with StoreJanitor alleviates
somewhat that
problem, but not solves completely as you still have to
properly configure all
your cache sizes correctly to avoid OOM.
I think you can try combining Cocoon's MRU cache and EHCache
to get best of both
Hello,
Ard Schrijvers wrote:
i would be glad to share the code and my ideas, for example
about this whole
StoreJanitor idea :-) )
Just curious, what did you mean by this whole StoreJanitor idea?
Before I say things that are wrong, please consider that the StoreJanitor was
invented
/snip
?? my mail got sended by accident :Sfinishing it now
be implemented quite easily, but might take long start up times)
6) JCSCache has a complex configuration IMO. Therefor, I
added default configurations to choose from, for example:
store logger=core.store
parameter
Ard Schrijvers wrote:
i would be glad to share the code and my ideas, for example about this whole
StoreJanitor idea :-) )
Just curious, what did you mean by this whole StoreJanitor idea?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Oops, should have read it in full...
Reinhard Poetz wrote:
I can think of setting the expires parameter to -1 and using a
background-refresher but this seems to be overly
Hello,
regarding the cache-expires and async thing in the cachingsource block, there
are some things that are strange and seem bugs to me:
1) The expires value is always -1 (eternal), no matter what you define in the
queryString. You can see this happen in getSource of the
Ard Schrijvers wrote:
Hello,
regarding the cache-expires and async thing in the cachingsource block, there
are some things that are strange and seem bugs to me:
1) The expires value is always -1 (eternal), no matter what you define in the queryString. You can see this happen in getSource of
This if statement checks if a parameter starts with
cocoon:cache and if yes,
it add it to the params object and removes it from the
normal request
parameters. It looks fine for me and the expires value is set
correctly at the
source AFAICS. BTW, I'm working on trunk.
Yes I saw
Hello Reinhard,
The repository block contains a the CachingSource. Does
anybody have experiences
with it?
Yes, we do have a lot of experience with it (though we have a slightly
different version (Max Pfingsthorn changed it: the public SourceValidity
getValidity() returns an
Ard Schrijvers wrote:
Hello Reinhard,
The repository block contains a the CachingSource. Does
anybody have experiences
with it?
Yes, we do have a lot of experience with it (though we have a slightly different version (Max Pfingsthorn changed it: the public SourceValidity getValidity()
yes, the broken connection scenario is that what I want. If
you say that it
doesn't really fit into the caching source, what do you
propose instead?
It does fit in the current caching source without touching the caching source I
think :-)
Writing
another source wrapping source
Reinhard Poetz wrote:
The repository block contains a the CachingSource. Does anybody have
experiences with it?
Yes.
I wonder how I can configure it so that the cached source expires e.g.
after 5 minutes but if it can't be updated (e.g. the wrapped source
isn't available), the expired
Oops, should have read it in full...
Reinhard Poetz wrote:
I can think of setting the expires parameter to -1 and using a
background-refresher but this seems to be overly complex for this simple task.
Yes async will do the trick. And IMHO it should be Ok to alter sync
implementation to keep
Vadim Gritsenko wrote:
Oops, should have read it in full...
Reinhard Poetz wrote:
I can think of setting the expires parameter to -1 and using a
background-refresher but this seems to be overly complex for this
simple task.
Yes async will do the trick. And IMHO it should be Ok to alter
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Oops, should have read it in full...
Reinhard Poetz wrote:
I can think of setting the expires parameter to -1 and using a
background-refresher but this seems to be overly complex for this
simple task.
Yes async will do the trick. And IMHO it
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Oops, should have read it in full...
Reinhard Poetz wrote:
I can think of setting the expires parameter to -1 and using a
background-refresher but this seems to be overly complex for this
simple task.
Yes async will do
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Oops, should have read it in full...
Reinhard Poetz wrote:
I can think of setting the expires parameter to -1 and using a
background-refresher but this seems to be overly complex for this
simple
Reinhard Poetz napisał(a):
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Actually it already should be working this way? See CachingSource line
427.
I guess with some additional configuration it should be possible to get
this stuff working but ...
TBH, I only want to have a url like
21 matches
Mail list logo
