Transient Object Containers (sessions) are not being flushed after expired time

1

We have a ZEO installation that's not flushing the Transient Object Containers used for sessions. When we check http://localhost:8080/temp_folder/session_data/manage_container, it grows until we hit the limit and need to restart the server.

[instance]
recipe = plone.recipe.zope2instance
user = xxxxxxxxxxxx:xxxxxxxxxxxxxx
effective-user = ${users:os}
http-address = ${ports:instance}
verbose-security = off
debug-mode = off
event-log-level = info
zodb-cache-size = 100000
zeo-client-cache-size = 512MB
zserver-threads = 2
blob-storage = ${blob:blob-storage}
enable-product-installation = off
shared-blob = on
zeo-client = yes
zeo-address = xxxxxxxxxxx:20000

zope-conf-additional =
    maximum-number-of-session-objects 13000
    session-timeout-minutes 60
    session-resolution-seconds 60

zodb-temporary-storage =
    <zodb_db temporary>
        <zeoclient>
          server ${instance:zeo-address}
          storage temp
          name zeostorage
          var ${buildout:directory}/var
        </zeoclient>
        mount-point /temp_folder
        container-class Products.TemporaryFolder.TemporaryContainer
    </zodb_db>

Anyone here has experienced something like this? What is the best approach to try to find the root cause of Zope not flushing the transient object containers after the defined timeout?

2

Interesting, so you are are moving the storage of sessions in a temporarystorage on the zeoserver instead of keeping the sessions on the individual zeoclients and using sticky sessions to keep users logged in? Rule thumb per the Plone documentation is that normally performance is better if you keep logged in users to their own zeoclient during the session: https://docs.plone.org/manage/deploying/stack.html#sticky-sessions but there are valid reasons/exceptions not to do so.

I see another example of this in a buildout config here, might nog be related at all to your site, but just as an example for others: https://github.com/interlegis/portalmodelo/blob/master/buildout.d/use-zeo.cfg

It could be that the temporarystorage because it's on the zeoserver is not flushing properly, or flushing at all until it restarts. And nobody else in the community notices this because the zeoclients get restarted regularly and the temporarystorage is flushed.

3

Sorry @fredvd, the storage is defined in the zeoclient, I've edited the first post to make it clear.

And nobody else in the community notices this because the zeoclients get restarted regularly and the temporarystorage is flushed.

Exactly, I would like to know the best approach to debug this and see why it's not being flushed. Should I patch the Zope code and log to see if flushing is really being called?

5

In a similar situation, we used collective.beaker but we had a standard session manager object. This caused the same problem: A call to a DTML page (used to signal "UP" to our varnish load balancer) resulted in a Zope session cookie, and a Transient object. This brought our site down after 3000 seconds (the varnish health check interval being one second).
A similar site with collective.beaker which had the proper "beaker session manager" object did not have this problem. The solution to replace the session manager object with a beaker session manager resolved the problem for us.

2 Likes