Option to restrict text measurement cache to session scope

[eclipse-rap]

Option to restrict text measurement cache to session scope

[ifurnadjiev]

With your suggestion every session will be overloaded with a lot of text-size-determination requests, which will trigger the UI re-layout (flickering). As a result the server performance will degrade with too many sessions in parallel.

[ceisserer]

Agreed, this won't come for free - that is why this cache was implemented in the first place. However it was proposed to make it optional via a switch and leave caching enabled by default, so in case users experience problems, they at least have the ability to turn it off instead of restarting the application regulary.

The reason my proposal is so drastic is that current implementation simply isn't robust - measure text once and if it matches take for granted the client will render all other texts the same way too requires some luck ;)

The only solution I can think if to make it really solid and keep caching in place is to re-validate each cached measurement again on the client and re-measure / re-layout in case a mismatch is detected. However I guess this would mean quite a lot of infrastructure work within rwt...

[ifurnadjiev]

Clemens, as it seems that you already have a "solution" in hands, it will not hurt to provide a patch (pull request) and discuss the details on top of it.

[ceisserer]

I implemented it a few years ago for a customer where the cache caused issues with session-replication inside a cluster (requests were randomly redirected to different cluster-nodes by the load-balancer which caused endless re-measure/re-layout loops). I'll dig it out and try to port it.

[ifurnadjiev]

Something came to my mind. In RAP theming the default font is defined as "family" of fonts like:
font: 14px Verdana, "Lucida Sans", Arial, Helvetica, sans-serif;
Is it possible that the text size measurement is different for Verdana vs Arial vs Helvetica in different systems (browsers)? The overall RAP font probe size will be the same (cached), but if one browser is using Verdana and other Arial and the sizes differ than the described issue is possible.

[ifurnadjiev]

@ceisserer Did you ever try with single font name?

[ceisserer]

@ifurnadjiev I thought about this scenario, but I guess it is handled correctly by the probe approach.
In case one browser falls back to Helvetica instead of Arial, this will already happen when the initial probe is computed. So the server-side cache would detect this browser measures differently compared to all other browsers which were using Arial and returned the same result for the probe, whereas this one returned a different initial-probe-result for Arial.

[ceisserer]

@ifurnadjiev I've opened a pull request to illustrate how storing the text meausrements in the session could work. I had deployed this approach in a production environment ~2017.