>
> I suggest that we don't register them at StoreJanitor by
> default anymore but
> make it configureable for users who rely on it in their custom Store
> implementations/configurations.
+1
>
> AFAIU, StoreJanitor only runs if at least one store is
> registered so we don't
> have to remove it.
>
> >> - fix EventRegistry
> >
</snip>
>
> I have to learn more about the EventRegistry in order to
> comment on your
> suggestions.
I will mail tonight or tomorrow morning all ins and outs, pros and cons (I know
of at least) of the current
eventRegistry and my suggested (implemented) fix (though we have to discuss
wether I can get it to work for EHCache and wether it needs to be
diskpersistent between JVM restarts)
>
> > 4) you have a memory leak in some custom component (a
> little vague yes :-) )
> > ....etc
>
> hehe, if we can implement an algorithm that can provide such
> analysis reliably,
> why not ;-)
I think this is extremely hard. Not for the pipeline caches because they store
the response in byte[], but for continuations, internal component maps (for
example i18n resource bundles I think, compiled jx), memory stores which
contain any complex non serializable objects, I think it is impossible to know
the amount of memory. I test these things the most dumb possible way you can
imagine: I crawl my site, and look in status page what happens. I have
many stores in my status page. I have a clear link for each seperate store, and
I look at the memory which gets
freed when clearing one store. This gives me a heuristic measurement of how
large my stores are and should be configured
>
> Are you suggesting some kind of online monitor? I think
> having a seperate
> component would be better than merging it into StoreJanitor.
> This component
> could also be made available as MBean.
See above, very complex I think...and if we fix the standard things that it is
harder for users to
get bugged by the StoreJanitor, and they want to take it to the next level,
there are always things
like yourkit profiler. But, perhaps I am not ambitious enough now :-)
>
>
> yes please, I would be interested in more comments too! Are
more comments like in wiki or in the cocoon.xconf more comment for different
configurations?
I can try to write extended documentation on what IMO is best for
configuration, and "tricks" to
avoid the StoreJanitor mechanism
> Ard and I right that
> we shouldn't register EHDefaultStore and MRUMemoryStore at
> StoreJanitor anymore
> by default and make it configureable instead?
In principle, you could see the StoreJanitor as a real last resort (but IMO, it
will never actually help).
The StoreJanitor might still run, and give proper warnings when low on memory.
Configuring your stores correctly
(and making sure no binary files of many Mb's end up in it), and certainly
having the maxdiskelements
configured should do the trick! Not running the StoreJanitor when JVM is low,
will result in a little faster OOM,
but in my opinion, it differs not much. I also think, the maxdiskelements
should have a sensible default, which
should be less then indefinitely (something like 30.000-50.000 should cover I
think almost everybodies apps)
>
> > Ard
> >
>
> the formatting is okay now, but it seems that your mails
> still don't set the
> in-reply-to header correctly.
Hmmm, I will start using Thunderbird on short notice (not yet today :-) )
>
> --
> Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
>
> {Software Engineering, Open Source, Web Applications, Apache Cocoon}
>
> web(log): http://www.poetz.cc
> --------------------------------------------------------------------
>
