Tim Peters wrote:
it knew about. To support this, a persistent ZEO cache stores the
value of the largest tid the ZEO client knew about in the cache file.
Hmmm, didn't think I was using a persistent client cache here...
...well, there are .zec files in the var directory, so I guess I must
We're missing 16 days worth of content.
Python 2.3.5, Zope 2.8.4, Plone 2.1.2, and a host of other products. ZEO
configuration. Persistent disk caching is on.
Yesterday everything was fine. All the content was there and accessible.
Today I try to log in and the server doesn't respond. I go out
Florent Guillaume wrote:
base._p_activate() # make sure we're not a ghost
base.__setstate__(state) # change the state
base._p_changed = True # marke object as dirty
OK, this is the code I went with.
Well the C code is pretty clear, it does a PyDict_Clear before doing
What about permissions on the Data.fs? If ZEO could not write the Data.fs
but could maintain the persistent cache, that would explain what you
observed.
On Mon, 1 May 2006, Jim Fulton wrote:
Michael Havard wrote:
We're missing 16 days worth of content.
Python 2.3.5, Zope 2.8.4,
David Pratt wrote:
Jim, what do you think?
In principal, I'd libe to be able to leverage Twised in ZEO's
networking layer. I would not want to make it a requirement.
It's not something I'd want to see until there was a more basic
refactoring.
Do you think you could
give us a place to
Michael Havard wrote at 2006-5-1 06:57 -0500:
Python 2.3.5, Zope 2.8.4, Plone 2.1.2, and a host of other products. ZEO
configuration. Persistent disk caching is on.
Yesterday everything was fine. All the content was there and accessible.
Today I try to log in and the server doesn't respond. I go
Chris Withers wrote at 2006-5-1 11:34 +0100:
...
...well, there are .zec files in the var directory, so I guess I must
be. What controls whether a persistent or temporary client cache is used?
Your Zope configuration file, of course ;-)
It is the client option of the zeoclient section.
You
Tim Peters wrote:
[Christian Theune]
Hmm. Sorry, but could you point out where the API is defined? I might
not have looked hard enough. I only found internals to exploit. :(
[Jim Fulton]
I wish I could. I'm almost certain that Chris McDonough implemented
one at PyCon 2005 and that
Dennis Allison wrote:
What about permissions on the Data.fs? If ZEO could not write the Data.fs
but could maintain the persistent cache, that would explain what you
observed.
No. If the storage server couldn't write to the file, it would fail.
Only the server writes to Data.fs. The
The backup data.fs for the last 16 days has a timestamp of 4/14/2006 and
has not changed in size. Noone has restored from backup during the last 16
days. And, that I'm aware of, noone has moved files. The data.fs.index and
data.fs.lock are both timestamped at 4/17 and haven't changed in any of
On Monday 01 May 2006 14:14, Jim Fulton wrote:
I suggest that:
- The storage should be required to return OIDs in the
database at aproximately time the call was made. It should
be acceptable to omit recent items. The idea is that OIDs
generated while the request is being satisfied
At:
http://www.zope.org/Wikis/ZODB/FixupDependencies
I've created a proposal for sorting out the dependencies in ZODB.
If you commit changes to ZODB, please pay attention to this proposal
and don't add code that breaks these dependencies further.
Comments and questions are welcome.
Jim
12 matches
Mail list logo
