Hey there,
Recently, we've experienced multiple instances of broken Chameleon templates, causing mostly this type of error:
File "/home/zope/eggs/Chameleon-2.25-py2.7.egg/chameleon/template.py", line 171, in render
self._render(stream, econtext, rcontext)
File "/home/zope/......../var/chameleon-cache/a302fc11790624b3d8db763dfa2b251f.py", line 89, in render
__iterator = _static_140420322122128(getitem('view'), econtext, True, ('rsslinks', ))
TypeError: 'dict' object is not callable
See full traceback here: https://gist.github.com/jone/09eb072165921f6c5fb6fa82f8001cca
The error can usually be eliminated by restarting the affected ZEO-client. It usually only affects one ZEO-client at a time.
I do not understand the problem at this point and I'm wondering if anyone has experienced a similar problem. We've actually seen this problem on multiple Plone installations, where the custom code is very different apart from the Chameleon integration and Plone itself.
Versions:
Python 2.7.10 mostly
Plone 4.3.x (4.3.4; 4.3.15)
Chameleon 2.25 ; 3.1
five.pt 2.2.4
We have the problem on multiple deployments which do not have the same versions.
Background / Configuration:
At 4teamwork, we're using Chameleon in 200+ Plone 4 deployments, since about a year now. We use our own configuration layer, ftw.chameleon, allowing us to ship default behavior and opinionated customizations for all our deployments.
We especially want to make sure that all templates are compiled and loaded on boot up time [1]. Chameleon allows to set the CHAMELEON_EAGER environment variable for doing that, but it did not do what we wanted when combined with five.pt.
That's why we do our own precooking at boot time, executed in a separate thread in parallel:
We've configured Chameleon to use a shared cache directory for all ZEO clients in the buildout.
At the moment our suspicion is that the problem is caused when multiple processes are started more or less at the same time and may end up precompiling the same template at the same time. They will calculate the same file hash and therefore probably replace the file of the other process.
It seems thought that the Chameleon loader is implemented safe enough (writing to a tempfile, then renaming; acquiring the imp-lock around writing, byte-compiling and importing).
So: did someone have such a problem already and can give me a pointer where to dig?
Cheers
[1] This allows us to have smoother deployments, reducing errors for visitors when doing a zero-downtime-deployment.