Re: [Zope-dev] Session Errors
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. 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. 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. Sound reasonable? -- 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] XMLRPC with varargs
Hello,
Sorry, I made mistake on last patch...
I am sending the correct one
--- mapply.py 2003-03-17 20:11:23.0 -0300
+++ mapply.py.new 2003-03-17 20:11:16.0 -0300
@@ -13,6 +13,8 @@
"""Provide an apply-like facility that works with any mapping object
"""
+import inspect
+
def default_call_object(object, args, context):
result=apply(object,args) # Type s to step into published object.
return result
@@ -23,11 +25,15 @@
def default_handle_class(klass, context):
if hasattr(klass,'__init__'):
f=klass.__init__.im_func
-c=f.func_code
-names=c.co_varnames[1:c.co_argcount]
-return klass, names, f.func_defaults
+#c=f.func_code
+#names=c.co_varnames[1:c.co_argcount]
+spec=inpect.getargspec(f)
+names=spec[0][1:]
+defaults=spec[3]
+vargs=spec[1:3]
+return klass, names, defaults, vargs
else:
-return klass, (), ()
+return klass, (), (), []
def mapply(object, positional=(), keyword={},
debug=None, maybe=None,
@@ -37,7 +43,7 @@
):
if hasattr(object,'__bases__'):
-f, names, defaults = handle_class(object, context)
+f, names, defaults, vargs = handle_class(object, context)
else:
f=object
im=0
@@ -53,20 +59,25 @@
if im:
f=f.im_func
-c=f.func_code
-defaults=f.func_defaults
-names=c.co_varnames[1:c.co_argcount]
+#c=f.func_code
+#defaults=f.func_defaults
+#names=c.co_varnames[1:c.co_argcount]
+spec=inspect.getargspec(f)
+names=spec[0][1:]
+defaults=spec[3]
+vargs=spec[1:3]
else:
defaults=f.func_defaults
c=f.func_code
names=c.co_varnames[:c.co_argcount]
+vargs=None
nargs=len(names)
if positional:
positional=list(positional)
if bind and nargs and names[0]=='self':
positional.insert(0, missing_name('self', context))
-if len(positional) > nargs: raise TypeError, 'too many arguments'
+if (len(positional) > nargs) and not vargs: raise TypeError, 'too many
arguments'
args=positional
else:
if bind and nargs and names[0]=='self':
___
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
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). -- 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 )
[Zope-dev] XMLRPC with varargs
Hello,
I have tried call a function via XMLRPC with * and ** args
with no success!
The following error have appeared:
Unexpected Zope error value:
Traceback (most recent call last):
File
"/home/catunda/projetos/zope/cvs/zope/lib/python/ZPublisher/Publish.py",
line 150, in publish_module
response = publish(request, module_name, after_list, debug=debug)
File
"/home/catunda/projetos/zope/cvs/zope/lib/python/ZPublisher/Publish.py",
line 114, in publish
sys.exc_info()[2],
File
"/home/catunda/projetos/zope/cvs/zope/lib/python/ZPublisher/Publish.py",
line 98, in publish
request, bind=1)
File
"/home/catunda/projetos/zope/cvs/zope/lib/python/ZPublisher/mapply.py",
line 71, in mapply
if len(positional) > nargs: raise TypeError, 'too many arguments'
TypeError: too many arguments
I don't know if it's a bug but I debugged zope and changed
some things in mapply.py. The idea of this changes is
test if a function has *,** args or not using inspect
module. I don't know if this changes will affect other
things in zope.
Follow the patch of changes.
--- mapply.py 2003-03-17 19:30:12.0 -0300
+++ mapply.py.new 2003-03-17 18:59:54.0 -0300
@@ -13,6 +13,8 @@
"""Provide an apply-like facility that works with any mapping object
"""
+import inspect
+
def default_call_object(object, args, context):
result=apply(object,args) # Type s to step into published object.
return result
@@ -23,11 +25,15 @@
def default_handle_class(klass, context):
if hasattr(klass,'__init__'):
f=klass.__init__.im_func
-c=f.func_code
-names=c.co_varnames[1:c.co_argcount]
-return klass, names, f.func_defaults
+#c=f.func_code
+#names=c.co_varnames[1:c.co_argcount]
+spec=inpect.getargspec(f)
+names=spec[0][1:]
+defaults=spec[3]
+vargs=spec[1:3]
+return klass, names, defaults, vargs
else:
-return klass, (), ()
+return klass, (), (), []
def mapply(object, positional=(), keyword={},
debug=None, maybe=None,
@@ -37,7 +43,7 @@
):
if hasattr(object,'__bases__'):
-f, names, defaults = handle_class(object, context)
+f, names, defaults, vargs = handle_class(object, context)
else:
f=object
im=0
@@ -53,20 +59,28 @@
if im:
f=f.im_func
-c=f.func_code
-defaults=f.func_defaults
-names=c.co_varnames[1:c.co_argcount]
+#c=f.func_code
+#defaults=f.func_defaults
+#names=c.co_varnames[1:c.co_argcount]
+spec=inspect.getargspec(f)
+names=spec[0][1:]
+defaults=spec[3]
+vargs=spec[1:3]
else:
defaults=f.func_defaults
-c=f.func_code
-names=c.co_varnames[:c.co_argcount]
+#c=f.func_code
+#names=c.co_varnames[:c.co_argcount]
+spec=inspect.getargspec(f)
+names=spec[0]
+defaults=spec[3]
+vargs=spec[1:3]
nargs=len(names)
if positional:
positional=list(positional)
if bind and nargs and names[0]=='self':
positional.insert(0, missing_name('self', context))
-if len(positional) > nargs: raise TypeError, 'too many arguments'
+if (len(positional) > nargs) and not vargs: raise TypeError, 'too many
arguments'
args=positional
else:
if bind and nargs and names[0]=='self':
--
Marco Catunda
___
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] Merging the new-install-branch
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. There's a bit more testing to be done before the merge can occur; I'll be doing that tonight and tomorrow morning. 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 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! Checkout instructions are included in the message referenced above. -Fred -- Fred L. Drake, Jr. 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] Modification Help
On March 17, [EMAIL PROTECTED] wrote: > I am trying to develop a program that generates a top-level folder > within zope and then has one of its functions called to give permission > to access the folder, as opposed to using the standard Zope permission > system. As I understand it the only way to do this is to modify the core > zope software. Like everything else in Zope, assigning permissions and roles can be done programmatically. So, if you want to dynamically grant a role a particular permission (or conversely, grant a user a role), you could do it with a Python script that calls container.manage_permission or container.manage_role as appropriate, and give that script the Manager proxy role, ensuring it is only callable by appropriate users. But I strongly suspect there is a better way to solve your problem, probably with local roles. If you describe what you're really trying to achieve, perhaps we can help you achieve it in a more Zopish way. When you say "top-level folder", do you mean the root folder (which is not really a folder), or one level down? 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] Session Errors
Hi Chris, Chris McDonough wrote at 2003-3-15 12:40 -0500: > ... > - The first is that turning off read conflicts allows for the potential > for the session data bucket and the session data index to become out > of sync. I admit that I knew this already, but haven't figured out > a way around it yet without having massive numbers of conflicts. > That said, it may be that we can't avoid them and I may turn this > behavior off in the next revision. Another alternative is to > use a nonpersistent index, but that has other challenges ( it > could also prevent the shared use of session data between ZEO > clients). 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. > - The second is an unidentified (yet) bug in TemporaryStorage. Most of > the code for TemporaryStorage came right out of the Berkeley > "Packless" storage. I should probably try to replicate this under > load (this should not be difficult).To verify the assertion that > there really is a bug in TemporaryStorage without much trouble, > you could temporarily put your transient object container > (session_data) in the main database and point the session data > manager at it and run for a while under this config. This is > not recommended for production as it will cause main database > bloat, however. The problem might also be the "MountPoint" -- with the connection to the TemporaryStorage not correctly synchronized with the transaction. 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] Modification Help
On Mon, 2003-03-17 at 04:31, [EMAIL PROTECTED] wrote: > I am trying to develop a program that generates a top-level folder within zope and then has one of its functions called to give permission to access the folder, as opposed to using the standard Zope permission system. I don't think you really need this. Zope authentication/authorization machinery is so flexible that there's usually a way to code whatever you want to achieve thru it instead of around it. > As I understand it the only way to do this is to modify the core zope software. I don't think you need this either. Zope authentication machinery is very plugable. At the very worst, I think you could get around it by creating a class that inherits from Folder and instantiate from that instead. > Am I correct or is there another way to do it? There probably is, but it'd be better if we understood what you're trying to do. Try to tell us what you are trying to achieve instead of how you plan on doing it :-) > I have looked at OFS.ObjectManager and discovered that the functions _getobj, _setobj, and _delobj are called to get, set and delete an object. Presumably, if I raised an exception here, it would cause the operation to not suceed. Yes, but you don't have to change ObjectManager for that. As I mentioned before, you could inherit from folder, override ._setobj() and raise an exception before calling 'Folder._setobj(self, ...)'. You can also raise an exception after you've called those methods, as long as you are still in the same transaction. If the exception is not caught, it aborts the transaction and any changes that happened since it's begining will be discarded. > I have also figured out how to get the ID and Title of the file, but I can't get the absolute path. > How do I tell the absolute path of a file from within OFS.ObjectManager? file.getPhysicalPath() will give you a tuple representation of the object absolute path. '"/".join(file.getPhysicalPath())' will get you the string representation. > And, is modifying OFS.ObjectManager to call the function in my program the best place to modify the core of zope? As I said, there are a number of options to try before you modify Zope core :-) Cheers, Leo ___ 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 Saturday 15 March 2003 5:40 pm, Chris McDonough wrote: > - The second is an unidentified (yet) bug in TemporaryStorage. As a cause of the KeyError exception? Could be I have seen equivalent exceptions with plain FileStorage in applications that do not use sessions, so I suspect there might be a hard-to-hit zodb bug that can cause this too. (In FileStorage the equivalent exception is POSKeyError, a subclass of KeyError) > If I find and fix the TemporaryStorage bug I will let you know. In the > meantime, you can probably work around this by using a different > non-undoing storage to put your session data in (e.g. Berkeley, or maybe > DirectoryStorage?). It would be interesting to hear if this exception is repeatable with the session state stored in a FileStorage too. > > > You may see many more conflicts with this running. But maybe the data > > > structures will not become desynchronized. > > > > You weren't kidding about the increase in conflict errors. 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. -- 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 )
