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