Hi Korbinian,
> it was a real breeze. I'm very impressed!
thanks, glad to hear that.
You application is persisting pages in the Http session instead of disk.
Essentially what the wicketstuff's gae-initializer does too:
https://github.com/wicketstuff/core/blob/master/gae-initializer-parent/gae-initializer/src/main/java/org/wicketstuff/gae/GaePageManagerProvider.java
InsessionPageStore has a maxBytes constructor too.
Watch out for the override of the #getKey() method - I'm not happy with
that, but your question triggers me to look into that once again.
Have fun
Sven
On 10.11.21 12:05, Korbinian Bachl wrote:
Hi,
Im currently migrating our applications from wicket 8 to wicket 9.6 and so far
it was a real breeze. I'm very impressed!
One thing however that puzzles me is the following code I had in the
application init();
setPageManagerProvider(new DefaultPageManagerProvider(this) {
protected IDataStore newDataStore() {
return new HttpSessionDataStore(getPageManagerContext(),
new MemorySizeEvictionStrategy(Bytes.megabytes(24)));
}
});
getStoreSettings().setInmemoryCacheSize(0);
I honestly dont know from when this originated but I had to disable it as it
doesnt seem to exist anymore accorting to the migration guide.
So I just let de default settings now apply. The original solution was aimed at
maximum page delivery speed and didnt care much about RAM as we got plenty of
it. Any idea if I should let the default or can I squeeze out some milliseconds
by going pure in memory again?
Best,
KB
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
