On Wed, Apr 9, 2014 at 9:27 AM, Martin Grigorov wrote:
> The second level cache is disabled now -
> https://issues.apache.org/jira/browse/WICKET-5554
Thanks Martin!
--
Guillaume
The second level cache is disabled now -
https://issues.apache.org/jira/browse/WICKET-5554
Martin Grigorov
Wicket Training and Consulting
On Tue, Apr 8, 2014 at 10:04 AM, Martin Grigorov wrote:
> More opinions here ?
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Mon, Apr 7, 2014
More opinions here ?
Martin Grigorov
Wicket Training and Consulting
On Mon, Apr 7, 2014 at 1:01 PM, Sven Meier wrote:
> +1
>
> I think this is the right direction. In the long term we should revisit
> some decisions/relicts of storing pages in Wicket.
>
> Sven
>
>
> On 04/04/2014 03:19 PM, Mar
+1
I think this is the right direction. In the long term we should revisit
some decisions/relicts of storing pages in Wicket.
Sven
On 04/04/2014 03:19 PM, Martin Grigorov wrote:
Hi Guillaume,
We have also disabled the second level cache for our main application for
the time being.
Maybe we
On Fri, Apr 4, 2014 at 3:19 PM, Martin Grigorov wrote:
> Maybe we should set 0 as the default cache size for 6.15.0 and explain this
> in the announcement + a blog + some tweets ?
> If an application wants to use the second level cache then it should enable
> it explicitly.
+1.
It might be usefu
Hi Guillaume,
We have also disabled the second level cache for our main application for
the time being.
Maybe we should set 0 as the default cache size for 6.15.0 and explain this
in the announcement + a blog + some tweets ?
If an application wants to use the second level cache then it should ena
Hi Martin,
Some feedback you might find useful about this.
On Thu, Mar 6, 2014 at 3:01 PM, Martin Grigorov wrote:
> A workaround to avoid the slowness caused by this is to set 0 or negative
> value to org.apache.wicket.settings.StoreSettings#setInmemoryCacheSize
We have a quite big application
ah.. ok. then this should work fine in most cases..
mm:)
Am 12.03.14 10:13, schrieb Martin Grigorov:
Thanks for the review, Michael!
SerializedPagesCache is the cache that is used in 6.14.0 with the problems
explained in the first mail in this thread.
Its initial max size is 40
(org.apache.wick
Thanks for the review, Michael!
SerializedPagesCache is the cache that is used in 6.14.0 with the problems
explained in the first mail in this thread.
Its initial max size is 40
(org.apache.wicket.settings.def.StoreSettings#DEFAULT_CACHE_SIZE).
That it it holds the last 40 used pages in the whole
Am 11.03.14 13:55, schrieb Martin Grigorov:
Any comments on
https://github.com/apache/wicket/compare/5527-inefficient-DefaultDataStoreare
very welcome!
Hmm.. SerializedPagesCache .. if one has many pages costs will go up..
but i am not sure, how big the cache will be in real life applications..
Hi,
On Wed, Mar 12, 2014 at 10:40 AM, Michael Mosmann wrote:
> a.. got it..
>
> https://github.com/apache/wicket/compare/master...5527-
> inefficient-DefaultDataStore
>
> Am 11.03.14 13:55, schrieb Martin Grigorov:
>
>> Any comments on
>> https://github.com/apache/wicket/compare/5527-inefficient-
Hi,
.. is the link correct?
mm:)
Am 11.03.14 13:55, schrieb Martin Grigorov:
Any comments on
https://github.com/apache/wicket/compare/5527-inefficient-DefaultDataStoreare
very welcome!
It should be relatively easy to roll custom impls based on
Guava/Hazelcast/... if needed/preferred.
Martin
a.. got it..
https://github.com/apache/wicket/compare/master...5527-inefficient-DefaultDataStore
Am 11.03.14 13:55, schrieb Martin Grigorov:
Any comments on
https://github.com/apache/wicket/compare/5527-inefficient-DefaultDataStoreare
very welcome!
It should be relatively easy to roll custom i
Any comments on
https://github.com/apache/wicket/compare/5527-inefficient-DefaultDataStoreare
very welcome!
It should be relatively easy to roll custom impls based on
Guava/Hazelcast/... if needed/preferred.
Martin Grigorov
Wicket Training and Consulting
On Mon, Mar 10, 2014 at 9:55 AM, Martin
I can see the benefits of adding dependency to Guava, but I can also see
many dependency conflicts caused by this.
Guava is not that strict in backward compatibility and this will lead to
problems like: an application depends on version X because of feature X1
and Wicket requires version Y that is
Having a flexible eviction policy would be nice, but if we decide to for
this way I would strongly recommend to NOT start implementing our own
cache solution. Instead, we should consider to adopt one of the existing
solutions (like Guava cache).
>
> An additional consideration: what about getPage(S
We could have second impl of org.apache.wicket.pageStore.IPageStore and you
can switch them by
overriding org.apache.wicket.DefaultPageManagerProvider#newPageStore
The question is: how useful this second level cache really is ?
The first level cache (all touched pages in the last request cycle be
Would it be possible to make this change available as a switchable option
in 6.x (in addition to 7.x), leaving the current store/mechanism in place.
The reason I ask is because this seems to be a very significant fundamental
change to Wicket, and while the analysis by the original poster was very
On 07.03.2014, at 14:14, Martin Grigorov wrote:
> On Fri, Mar 7, 2014 at 2:51 PM, Andrea Del Bene wrote:
>
>> Just my considerations (hopefully not to obvious) on caching inside
>> DefaultPageStore.SerializedPagesCache.
>>
>> -Using a LinkedList instead of ArrayList would bring better performa
On Fri, Mar 7, 2014 at 2:51 PM, Andrea Del Bene wrote:
> Just my considerations (hopefully not to obvious) on caching inside
> DefaultPageStore.SerializedPagesCache.
>
> -Using a LinkedList instead of ArrayList would bring better performances
> because we would avoid to recompating (using add/remo
Just my considerations (hopefully not to obvious) on caching inside
DefaultPageStore.SerializedPagesCache.
-Using a LinkedList instead of ArrayList would bring better performances
because we would avoid to recompating (using add/remove last/first element)
-Doing a deeper refactoring we could use o
On Fri, Mar 7, 2014 at 1:21 PM, Tom Götz wrote:
> Just curious:
> in 5527-inefficient-DefaultDataStore branch (8908b8f2) you are now using a
> ConcurrentLinkedDeque as a cache. Why not use a map here, e.g.
> ConcurrentSkipListMap with entries ordered by a timestamp or whatever?
>
This is what I'
Just curious:
in 5527-inefficient-DefaultDataStore branch (8908b8f2) you are now using a
ConcurrentLinkedDeque as a cache. Why not use a map here, e.g.
ConcurrentSkipListMap with entries ordered by a timestamp or whatever?
Plus: why is that cache global in terms of that it contains all pages of
Hi,
We have identified some problems in
org.apache.wicket.pageStore.DefaultPageStore.SerializedPagesCache.
Some history first:
At https://cwiki.apache.org/confluence/display/WICKET/Page+Storage I have
explained how the page storage management works in Wicket 1.5+
In brief:
First level cache/stor
24 matches
Mail list logo
