New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scale annotations are leaking #828

Open
hvelarde opened this Issue Sep 17, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@hvelarde
Member

hvelarde commented Sep 17, 2018

I was checking annotations on one cover object and I found the following:

>>> len([k for k in IAnnotations(obj) if k.startswith('plone.tiles.data')])
85
>>> len([k for k in IAnnotations(obj) if k.startswith('plone.tiles.configuration')])
61
>>> len([k for k in IAnnotations(obj) if k.startswith('plone.tiles.scale')])
200

that means we have annotations for 200 scales but only 28 of them seem to be related with existing tiles:

>>> scales = {k.split('.')[3] for k in IAnnotations(obj) if k.startswith('plone.tiles.scale')}
>>> tiles = {k.split('.')[3] for k in IAnnotations(obj) if k.startswith('plone.tiles.data')}
>>> len(scales & tiles)
28

@hvelarde hvelarde added the bug label Sep 17, 2018

@hvelarde

This comment has been minimized.

Member

hvelarde commented Sep 18, 2018

I did the following test using collective.revisionmanager:

  • calculate statistics and getting information about the object
  • purge all but 5 revisions
  • recalculate statistics

object size is reduced, but we have the same number of annotations present; this seems to me as an issue with versioning.

before
after

@rafaelbco

This comment has been minimized.

rafaelbco commented Sep 21, 2018

The code in the first comment only gets the annotations for the current object. After erasing revisions the object and it's annotations are expected to remain intact. Does that makes sense or am I missing some detail?

@idgserpro

This comment has been minimized.

Member

idgserpro commented Sep 21, 2018

This is just another example of why #742 is not that trivial...

@hvelarde

This comment has been minimized.

Member

hvelarde commented Sep 21, 2018

that's right; I think the problem is versioning: versions store their data in annotations on the same base object and, when they are removed, annotations remain in place.

@idgserpro

This comment has been minimized.

Member

idgserpro commented Sep 21, 2018

Since we don't have a properly CMFEditions configuration, is https://github.com/collective/collective.cover/blob/f66adb50d2834301ff7023a4f1bfe23bd0438039/src/collective/cover/profiles/default/repositorytool.xml really necessary? Do you think it may be the reason we're having this leakage?

@hvelarde

This comment has been minimized.

Member

hvelarde commented Sep 21, 2018

I have no idea :)

@rafaelbco

This comment has been minimized.

rafaelbco commented Sep 22, 2018

I have an idea, which is only tangentially related to this issue, but it would solve it if
implemented.

I think setups where scales are heavily used (think site front pages) and where a cache frontend is used (Varnish), image scales could be stored only in a RAM cache without losing much performance.

In a RAM cache things expire and are evicted from the cache. So the scales storage should be able to rebuild a requested scale when needed.

I have an idea on how to implement it. If you like this approach I'd appreciate feedback
on this: plone/plone.scale#32

For now I wrote a CMFEditions modifier which prevents image scales from being versioned. I can provide the code if you need it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment