[Zope-dev] ERROR(200) ZODB Couldn't load state for... Memory problem?

[Chris McDonough]

On Sun, 2004-07-25 at 12:43, Russ Ferriday wrote:

> Assume for now that I'm not naming my zeo-clients - this would
> bebegging for disaster - but all is not lost. For some arcane reason
> Ihave not yet tracked down, after running my 2 clients under load,
> Iget these...
> -rw-r--r--  1 plone  staff  10006534 25 Jul
> 05:30/usr/local/zope/instances/prodZope/etc/1-None-0
> -rw-r--r--  1 plone  staff   1404198 25 Jul
> 05:37/usr/local/zope/instances/prodZope/etc/1-None-1
> -rw-r--r--  1 plone  staff   5723516 25 Jul
> 05:02/usr/local/zope/instances/prodZope/log/1-None-0
> -rw-r--r--  1 plone  staff  10043763 25 Jul
> 04:20/usr/local/zope/instances/prodZope/log/1-None-1

That would be consistent with the bug we identified (that nontemporary
cache files are written even when they're not supposed to be in various
places on the filesystem) if your working directory was
"/usr/local/zope/instances/prodZope/log"  or
"/usr/local/zope/instances/prodZope/etc" at the time a Zope instance was
started.  You could confirm this by causing Zope to print "os.getcwd()"
during its startup process.  It's likely that you were just "cd'ed" into
these directories when you started Zope up.

And failing to name your zeo clients is hopefully not "begging for
disaster".. it's an explicit choice but it shouldn't have noticeably
negative effect other than perhaps requiring more time in general for
Zope to start and more load on the ZEO server during this starting
period.

> Nowhere have I asked it for cache files in either etc or log, but
> itsure makes sense that zope conspires to spread  them around like
> this. 

It doesn't make any sense at all except if you're running under 2.7.1
and take into account the bug in ClientCache.py that causes this kind of
symptom.  Hopefully that's what you're seeing.  If you're seeing this
under 2.7.2, it could be problematic, otherwise it's just a rehash of
the bug we've been rehashing for three days now that has apparently been
fixed for more than a week. ;-)

> Next for a little scat perusal of my own. We're talking 2.7.2 now.

.. scat perusal... I think that might belong on a different list....

> Here's the mystery.
> 
> I have never seen a cache file, in any of the recent 3 Zope
> versionsI've just tested, with a name other than *-None-*. Has anyone
> else?

Yes; well, before this I hadn't but now I have, due to investigations
prompted by your message! ;-)

> Note as well for anyone following on the Multi-Processor path,
> thatTres's tip about clienthome was slightly off, and yes, Paul
> Winklerwas nearer the mark.
> 
> Tres wrote.. 
>         # zope.conf.appserver1
>         %include zope.conf.common
>         clienthome /path/to/zope/var/appserver1 
> 
> Clienthome has no bearing on the cache file location. (AFAICT)

That appears to be correct.  I had always thought it was based on
clienthome too, but the code says "use the 'var' path in the <zeoclient>
section or use the current directory"; clienthome isn't consulted at all
for this (although it maybe should be).

> On 23 Jul 2004, at 18:38, Paul Winkler wrote:
> 
>         You mean this, from zope.conf.in?
>         
>         # Directive: zeo-client-name 
> 
> Yes, Paul. That's the way to go. And it should be pretty easy. Add
> asingle line to each conf file and restart.
> Not so. I never saw the names of my cache files change. And theystayed
> in etc, and log sub dirs.  

When you say they "stayed" there, were these file contents changed when
Zope was started and left running with a persistent cache file setting? 
I suspect they're just leftover from the last time you started Zope but
are otherwise unused (e.g. they won't get changed; they're "dead"). 
What happens if you delete these files and start Zope with the
"zeo-client-name" set?  I suspect they won't reappear.

> I walk through it here...
> 
> Starting in /ClientCache.py", line 142, at my pdb_trace() I
> believethat the client param should be the value ofzeo-client-name
> from my .conf file.  But I'm seeing 'None'. So wenever even try to
> make anything by temporary caches.
> 
> 

Grrr... ok, here's the deal.  zeo-client-name apparently no longer has
any effect on.. the ZEO client name. ;-)  I have no idea when this
happened; I'm sure interested parties can spelunk the CVS logs to find
out.

Instead, ZEO uses a "client" key in the <zeoclient> section of a
<zodb_db>, e.g.:

<zodb_db main>
    mount-point /
    cache-size 400000
   <zeoclient>
     cache-size 100000000
     server localhost:9999
     storage 1
     name zeostorage
     var $INSTANCE/var

     # here it is!
     client foo

   </zeoclient>
</zodb_db>

This effectively means that "zeo-client-name" is completely useless,
AFACIT.  It should be removed.

Once you start Zope with this client key set, you will see cache files
like "c1-foo-0.zec" and so on in your "var" directory.

> Any ideas? Anyone seen anything but *-None-* for cache files?
> 

If you see *-None-* for cache files and the first * doesn't start with a
"c" and the second * doesn't end with a ".zec", you're staring at the
symptom of the "temporary cache file settings produce real cache files"
bug or another bug that has the same symptom.

> Meanwhile, I'm going to see why zope gets creative about spreading
> thecache files around.

I think that particular mystery has been solved if you're only seeing it
under 2.7.1.

- C