I forgot to add:

We are using the HTML5 History API to push state to the (bookmarkable) URL,
so a page can be re-created with *all* state from the URL alone.

Thomas

On Thu, Jan 12, 2017 at 11:47 AM, Thomas Heigl <tho...@umschalt.com> wrote:

> Hi all,
>
> I'm looking for a solution to avoid serialization of bookmarkable pages.
>
> These are yesterday's metrics from an instrumented version of 
> Fast2WicketSerializer:
>
> "WicketSerializer.deserialize" : {
>>   "count" : 4084,
>>   "max" : 0.030842162000000003,
>>   "mean" : 0.005861568417930906,
>>   "min" : 0.0014487450000000002,
>>   "mean_rate" : 0.01926885221303454,
>>   "duration_units" : "seconds",
>>   "rate_units" : "calls/second"
>> },
>> "WicketSerializer.serialize" : {
>>   "count" : 498884,
>>   "max" : 0.007742393,
>>   "mean" : 0.002135383760700826,
>>   "min" : 8.211500000000001E-4,
>>   "mean_rate" : 2.3538006959615907,
>>   "duration_units" : "seconds",
>>   "rate_units" : "calls/second"
>> }
>
>
> As you can see, Wicket serialized about 500.000 pages, but only 4000 were ever
> de-serialized. The deserialization is caused by users who use multiple tabs 
> and
> then trigger an ajax action on one of them.
>
> All my pages are unversioned, bookmarkable and mounted in a way that strips
> version parameters from the URL.
>
> What I would like to do is completely disable HttpSessionDataStore, rely only
> on the application level cache that (from looking at the metrics is sufficient
> in the vast majority of cases) and recreate the bookmarkable page for the
> remaining cases instead of de-serializing a stored version.
>
> I know this is possible with stateless pages, but my application is very large
> and converting it all to stateless would require a massive effort.
>
> Is there a way to implement this with Wicket 7.6?
>
> I'm aware of the flags "setRecreateBookmarkablePagesAfterExpiry" and 
> "setCallListenerInterfaceAfterExpiry"
> but I'm not sure they apply to bookmarkable pages and Ajax calls.
>
> Any ideas would be greatly appreciated!
>
>
> Best regards,
>
> Thomas
>
>

Reply via email to