Re: [Zope-dev] Session Errors (read conflicts)
On Mon, 2003-03-17 at 20:34, John Eikenberry wrote: John Eikenberry wrote: Toby Dickenson wrote: Read conflicts occur if a change is committed in between the start of a transaction, and the transaction needing to load the object. A workaround to reduce the number of read conflicts is to touch the objects that are likely to change early in the transaction. Thanks for the tip. My sessions test script had a sleep() call right after the transaction commit, thus making it right at the beginning of the next transaction. Moving it to right before the commit (after all the session tests) pretty much eliminated all the read conflict errors. Just get a standard ConflictError occasionally now (not nearly as often). This turned out to be better than I thought. After nearly 3 hours of constant abuse I have yet to see a ReadConflictError and have yet to get either the load() or get() KeyErrors, previously I could force one of these in a 2-3 minutes of abuse. Our live sessions code uses the sessions about half to two-thirds of the way through the transaction. Given what can happen in that first half, there is easily plenty of time for read conflicts. I think I might be able to move our session use to the beginning of the transaction (just storing stuff in the REQUEST object for later usage) and hopefully fix our issue. Interesting, and I'm very glad you got it working reliably. But I'm not sure I understand why touching an object at the start of a transaction would fix the consistency problem. If a object A is read at the beginning of a transaction that uses the data from object A during write of object B and later object A changes and is invalidated by another transaction (before the first finishes), no conflict errors will be raised. Isn't there the potential for the first transaction to write inconsistent data into object B? In my mind, this is the same thing as using a low conflict connection (ie. you are essentially turning off read conflicts, albeit by circumstance rather than by code). I guess the question boils down to: why *don't* you see consistency problems now? I would expect to continue to see the get errors you reported earlier. I think this exact problem is being discussed on ZODB-Dev under the title Database Read Conflicts -- neither safe nor robust. The KeyErrors happen under similar circumstances to the ReadConflictErrors. The significant difference being that the KeyErrors happen after the transience timeout has occured. When I am running with the LowConflictConnection disabled the KeyErrors occur in the Connection.setstate method at line 509, before the ReadConflictError check. Is this the same KeyError you reported as coming out of TemporaryStorage.load? So say you have 2 threads; A and B. If A starts first, hits the session code and triggers a _housekeep() call during which time B has started but has not reached the Sessions code until after _housekeep() has finished. When it does reach the sessions code, you get the KeyErrors. Would you mind restating that? I think this is important, and I'm not sure I understand the second sentence above. Thanks! - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Session Errors
On Mon, 2003-03-17 at 15:02, Dieter Maurer wrote: You know that we use a Transience implementation with minimal (and not very essential) administrative data which is immune to inconsistencies and can be used across several ZEO clients (although we do not use that). We have good experience with this implementation. Does this package implement a similar API as the existing Transience package? Would you be willing to send it to me? The problem might also be the MountPoint -- with the connection to the TemporaryStorage not correctly synchronized with the transaction. Good point, thanks. - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Session Errors (read conflicts)
On Tuesday 18 March 2003 3:24 pm, Chris McDonough wrote: Our live sessions code uses the sessions about half to two-thirds of the way through the transaction. Given what can happen in that first half, there is easily plenty of time for read conflicts. I think I might be able to move our session use to the beginning of the transaction (just storing stuff in the REQUEST object for later usage) and hopefully fix our issue. Depending on what your sessioning involves, you might not need to change when you do all the work. Possibly just touching (an attribute of) the persistent session object will be enough. But I'm not sure I understand why touching an object at the start of a transaction would fix the consistency problem. If a object A is read at the beginning of a transaction that uses the data from object A during write of object B and later object A changes and is invalidated by another transaction (before the first finishes), no conflict errors will be raised. Isn't there the potential for the first transaction to write inconsistent data into object B? Today you are guaranteed that your transaction reads a consistent initial state of A and B. That is, there is no chance that you only see half the changes of a recent transaction that modified both. Yes, it is possible for one transaction to modify A and a concurrent transaction to modify B. This is what Deiter describes as not safe in that zodb-dev thread. IMO, it is only not safe if you are not aware of it. And it is critical for performance with concurrency - consider these two transactions occuring on different zeo nodes. In my mind, this is the same thing as using a low conflict connection (ie. you are essentially turning off read conflicts, albeit by circumstance rather than by code). There is a significant difference. The low conflict connection permits the possibility of seeing half the changes of a recent transaction that modified both objects. low conflict connection is a misleadnig name. The conflicts are still there - just not reported as exceptions. low consistency connection would be more accurate ;-) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Merging the new-install-branch
Fred L. Drake, Jr. wrote: I'm planning to merge the new-install-branch efforts recently discussed on this list into the Zope 2 trunk tomorrow. There will be things to do after the merge, but the basic functionality will be more easily testable and easier to contribute to. Will I have to change the way Zope is built and/or the etsts are run? If so, where could I find otu what they now need to look like? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Merging the new-install-branch
Chris Withers writes: Will I have to change the way Zope is built and/or the etsts are run? Yes. If so, where could I find otu what they now need to look like? There is a scenario for Linux in the newinstallbranch.xml in Packages/TestScripts; I'll test it again before the merge takes place. I don't know about the Windows scenario, but it's probably OK for now. It may need to change in the future (I'll try to help as much as possible; Tim just tried the new-install-branch tests on Windows and we found one buglet there). I won't be in front of a Windows box myself until tonight. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: [Zope-Coders] Merging the new-install-branch
[Fred L. Drake, Jr.] I'm planning to merge the new-install-branch efforts recently discussed on this list into the Zope 2 trunk tomorrow. ... http://mail.zope.org/pipermail/zope-dev/2003-March/018999.html Perhaps the most immediate change is that the Windows tests may become completely wedged, since we've not had time to do any testing on Windows yet. If anyone has time to do so (and a suitable platform), please don't hesitate to send bug reports before the merge! I'm running the Windows tests on this branch (Python 2.2.2 + new-install-branch + Win2000), and it's going well. We found one Windows-specific problem, and Fred checked in a fix for that. Two ZEO tests are failing, but that appears to be a cross-platform problem introduced yesterday and not unique to the branch. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Session Errors (read conflicts)
Today you are guaranteed that your transaction reads a consistent initial state of A and B. That is, there is no chance that you only see half the changes of a recent transaction that modified both. Yes, it is possible for one transaction to modify A and a concurrent transaction to modify B. This is what Deiter describes as not safe in that zodb-dev thread. IMO, it is only not safe if you are not aware of it. And it is critical for performance with concurrency - consider these two transactions occuring on different zeo nodes. Right, I understand now, thank you. In my mind, this is the same thing as using a low conflict connection (ie. you are essentially turning off read conflicts, albeit by circumstance rather than by code). There is a significant difference. The low conflict connection permits the possibility of seeing half the changes of a recent transaction that modified both objects. low conflict connection is a misleadnig name. The conflicts are still there - just not reported as exceptions. low consistency connection would be more accurate ;-) Yup. Maybe I should rename it? ;-) So... I'm wondering what the hell I should do. ;-) Obviously I need to deactivate the low consistency connection in the default setup. I'm thinking that I also may just need to move the housekeeping duties to a separate scheduled thread that only happens when the system is not busy (e.g. when the asyncore poll select timeout is reached maybe) in order to reduce the potential for conflicts. But I'm not sure what else to do, and I still don't understand what is causing the KeyErrors in the storage code. Sigh. - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Session Errors (read conflicts)
On Tuesday 18 March 2003 6:12 pm, Chris McDonough wrote: I'm thinking that I also may just need to move the housekeeping duties to a separate scheduled thread that only happens when the system is not busy (e.g. when the asyncore poll select timeout is reached maybe) in order to reduce the potential for conflicts. Thats hard to define, when zeo is installed. But I'm not sure what else to do, and I still don't understand what is causing the KeyErrors in the storage code. Sigh. Ive never looked at nor used your Sessioning support, but I am interested in things that can cause (POS)KeyErrors in Storages. This might not be a storage bug. There are several known corner cases in zodb that mean semi-legitimate applications can cause KeyErrors. DirectoryStorage tries to guard against them, and will raise a DanglingReferenceError rather than commit a transaction that will cause a POSKeyError when read. Can the problem be reproduced using DirectoryStorage? (without the low consistency connection) -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Session Errors (read conflicts)
On Tue, 2003-03-18 at 14:01, Toby Dickenson wrote: On Tuesday 18 March 2003 6:12 pm, Chris McDonough wrote: I'm thinking that I also may just need to move the housekeeping duties to a separate scheduled thread that only happens when the system is not busy (e.g. when the asyncore poll select timeout is reached maybe) in order to reduce the potential for conflicts. Thats hard to define, when zeo is installed. It would only make sense for shared session data if the housekeeping thread was enabled on a single ZEO client in a cluster. Of course this scenario has its own configuration and management difficulties. But I'm not sure what else to do, and I still don't understand what is causing the KeyErrors in the storage code. Sigh. Ive never looked at nor used your Sessioning support, but I am interested in things that can cause (POS)KeyErrors in Storages. This might not be a storage bug. There are several known corner cases in zodb that mean semi-legitimate applications can cause KeyErrors. DirectoryStorage tries to guard against them, and will raise a DanglingReferenceError rather than commit a transaction that will cause a POSKeyError when read. Can the problem be reproduced using DirectoryStorage? (without the low consistency connection) That's a fine question. ;-) John, did you see these Key Errors happen under a storage other than TemporaryStorage (e.g. if the session data container is in the main database)? I will check myself as well when possible. Dieter also observed that this may be a behavior specific to mounted storages, so I will need to try that as well. - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope-Coders] Merging the new-install-branch
I wrote: I'll send a note to the zope-coders list before I actually start the merge. For a description of the changes (and the ensuing discussion), refer to this thread: http://mail.zope.org/pipermail/zope-dev/2003-March/018999.html The unit tests work on Windows for the branch at this point, so I don't expect any real surprises there just yet. I'm starting the mechanics of the merge into the trunk now; I'll send another email when the merge is complete. Anyone running an automated test of the Zope 2 trunk should review this message to determine what impact this will have on the test process: http://mail.zope.org/pipermail/zope-coders/2003-March/003450.html -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] XMLRPC with varargs
Marco Catunda wrote at 2003-3-17 19:39 -0300: I have tried call a function via XMLRPC with * and ** args with no success! XMLRPC is a cross language technology. It does not support Python specialities such as * and ** arguments. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope-Coders] Merging the new-install-branch
Fred L. Drake, Jr. writes: I'm starting the mechanics of the merge into the trunk now; I'll send another email when the merge is complete. I'm done. The new-install-branch is now dead. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Session Errors (read conflicts)
Chris McDonough wrote: On Mon, 2003-03-17 at 20:34, John Eikenberry wrote: The KeyErrors happen under similar circumstances to the ReadConflictErrors. The significant difference being that the KeyErrors happen after the transience timeout has occured. When I am running with the LowConflictConnection disabled the KeyErrors occur in the Connection.setstate method at line 509, before the ReadConflictError check. Is this the same KeyError you reported as coming out of TemporaryStorage.load? Yes. I'm referring to the traceback I reported in a previous mail: http://mail.zope.org/pipermail/zope-dev/2003-March/019118.html The error occurs on the same line in TemporaryStorage.load(), whether it gets called from ZODB/Connection.py or TemporaryFolder/LowConflictConnection.py. So say you have 2 threads; A and B. If A starts first, hits the session code and triggers a _housekeep() call during which time B has started but has not reached the Sessions code until after _housekeep() has finished. When it does reach the sessions code, you get the KeyErrors. Would you mind restating that? I think this is important, and I'm not sure I understand the second sentence above. I'm working off the idea that the load() KeyErrors went away when the ReadConflictErrors did. So it seemed like they were probably triggered by similar scenarios. The difference being that for the former, the timeout had been reached and the _housekeep() code had been run (and possibly some additional code in _getCurrentBucket). Now given Toby's description of how ReadConflicts occur [1], it seems that instead of a change being committed to the object it is instead deleted (in _housekeep). Thus instead of getting the object and seeing it is marked as invalid, it cannot get the object at all when it expects to be able to... resulting in the KeyError in load(). [1] Read conflicts occur if a change is committed in between the start of a transaction, and the transaction needing to load the object. A workaround to reduce the number of read conflicts is to touch the objects that are likely to change early in the transaction. -- John Eikenberry [EMAIL PROTECTED] __ A society that will trade a little liberty for a little order will deserve neither and lose both. --B. Franklin ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposed installation changes for review
Small problem. The 'make install' step creates files in the source tree. It probably shouldn't do this, because if you want to do this as root (sudo make install to install under /usr/local, say), these file are created as root. This is impolite more than anything else. The build and install targets just call setup.py, so is this a bug in the distutils? a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposed installation changes for review
Adrian van den Dries writes: The 'make install' step creates files in the source tree. It probably shouldn't do this, because if you want to do this as root (sudo make install to install under /usr/local, say), these file are created as root. This is impolite more than anything else. The build and install targets just call setup.py, so is this a bug in the distutils? This still essentially does an in place build, which is what the previous Makefile did as well. Offhand, I'm not sure how difficult it would be to support both in-place and out-of-place builds; I may be able to look into it tomorrow. How important is it to support out-of-place builds? -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposed installation changes for review
On March 19, Fred L. Drake, Jr. wrote: How important is it to support out-of-place builds? http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration configure; make; make install source package installation process and some form of INSTANCE_HOME installation thereafter. INSTANCE_HOME setup becomes the default kind of installation. Is this still current? a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposed installation changes for review
Adrian van den Dries writes: On March 19, Fred L. Drake, Jr. wrote: How important is it to support out-of-place builds? http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration Ok, I'm too tired to read that now; I'll look at it tomorrow between meetings. configure; make; make install source package installation process and some form of INSTANCE_HOME installation thereafter. INSTANCE_HOME setup becomes the default kind of installation. Is this still current? Can't say about the wiki offhand, but the quoted statement still applies. doc/INSTALL.txt has been updated; see the section Building Zope for the relevant procedure. (The Quick Start section uses an abbreviated procedure that creates an instance home in the source directory.) Time for me to get some sleep. ;-) -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposed installation changes for review
On March 19, Fred L. Drake, Jr. wrote: (The Quick Start section uses an abbreviated procedure that creates an instance home in the source directory.) It calls configure with --prefix=/where/to/install/zope which is then unused. a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
