Ticket #2052 (new defect)

Opened 10 years ago

Last modified 10 years ago

Disappearing portlet

Reported by: gracinet Owned by: jmorliaguet
Priority: P1 Milestone: CPS 3.4.10
Component: CPSPortlets Version: TRUNK
Severity: critical Keywords: lookup cache
Cc:

Description

On one of my sites, a local portlet disappears after a while. This is recurrent.

It seems to be related to the lookup RAM cache, since invalidation of the cache solves the problem. The lookup RAM cache code is identical in 3.4 branch and trunk

Change History

comment:1 Changed 10 years ago by gracinet

  • Milestone changed from CPS 3.4.9 to CPS 3.4.10

Could not reproduce since I've put more logging in the instance I care for. I can confirm though that the portlet in question disappears from the cache. Don't know why yet.

comment:2 Changed 10 years ago by gracinet

Potential lead: the portlet visibility depends on the context and its situation in the object tree with respect to the bottom-most folder, whereas the cache key depends on the bottom-most folder (BMF) only.

Therefore one can imagine that the conjunction of a call from a context deeper than the BMF, i.e. a document, for which the portlet is not visible (true in my case) and a cache miss would set a wrong value into cache.

If this is right, conclusion: the context rpath should be used as cache key, not the BMF's

Will try to make a test out of the above scenario.

comment:3 Changed 10 years ago by gracinet

Références: method _isPortletVisible() and call to _setPortletLookupCache() in Portlets Tool

comment:4 Changed 10 years ago by gracinet

Just succeded reproducing the scenario in portlets tool integration tests. Indeed using the context rpath as a cache key instead of bmf rpath solves the issue (at least for this test).

Now I'm a bit concerned that using the context rpath might introduced lots and lots of cache keys, in effectivity making the cache very inefficient. Cases where indeed the bmf rpath and context rpath are equivalent make up the vast majority (that's why it took over 6 months to notice this).

OTOH, this visibility check is based on the comparison between the context and BMF rpaths, together with retrieval of the visibility_range for all portlets. Since the latter will likely be loaded anyway for display (or could be lifted as metadata from the catalog), I think that the visibility range stuff should be kept out of the lookup cache.

Another option would be to make a first, cached, visibility check based on BMF rpath and to conclude with the actual context rpath. Sounds like the typical bad idea..

Opinions ?

comment:5 Changed 10 years ago by madarche

Nice you have found the problem.

I would go for the "using rpath as cache key" option and not for a too complex cocktail.

After one could run bench tests with and without lookup RAM cache enabled to determine whether the cache remains a good solution in all cases. The numbers obtained in the bench tests could be compared with the result obtained in #1800 : "On a CPS default site the improvement is around 5% in page average rendering time. And on a big web site featuring many portlets the improvement is of 16% in page average rendering time."

Note: See TracTickets for help on using tickets.