Re: [SOLVED]: [Zope-DB] ZSQL meyhod fr an Oracle Stored Procedure that Returns a ref_cur
According to m.banaouas:
2-add a python script for external method in Plone\Data\Extensions :
# myscript.py
def mymethod(self , somename):
conn= self.myconnection()
curext = conn.db.cursor()
curint = conn.db.cursor()
sql = begin MY_PACKAGE.MY_PROC(:p_Cursor, :p_NAME); end;
curext.execute(sql, (curint, somename))
data= TransformCursorIntoReadableText(curint)
return data
If you are writing to a transactional database, you should add
conn._register()
to register that connection for the zope transaction
machinery. That way the Zope Publisher calls commit at the end of a
successful request (or abort on error).
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] [SOLVED]: ZSQL meyhod fr an Oracle Stored Procedure that Returns a ref_cur
According to banaouas:
If you are writing to a transactional database, you should add
conn._register()
to register that connection for the zope transaction
machinery. That way the Zope Publisher calls commit at the end of a
successful request (or abort on error).
Initially, I needed to access to this oracle database only for read
operations.
But even for read only access, it might be a good practice to add this
commit, cause sometime database engins hold some kind of lock on the read
data, depending on how transaction was started.
It might be a good practice, because you never know, if your
application will eventually also be writing to the DB. I don't know if
it has an effect on read only operations.
I imagine that zsql class do implicitely this commit ?
Strictly speaking its no commit, its a registration for
commit/abort. And yes, for ZSQL methods this is done implicitly (via
the query method of the DB class).
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-dev] Retracting Zope 2.9.7, Zope 2.10.3 releases because of a zopectl start problem
According to Andreas Jung:
I decided to retractthe latest 2.9.7 and Zope 2.10.3 releases
for now because of this problem:
http://mail.zope.org/pipermail/zope/2007-March/171086.html
I could confirm that zopectl start does not work properly.
zdaemon spawns the second process however this one seems to go
own immediately. Unfortunately I could not find the reason so far.
Any help will be appreciated.
At the risk of saying something obvious...
strace showed, that the spawned process exits with
raise ValueError('No REQUEST parameter in callable signature')
which is part of the postonly(callable) function in
lib/python/AccessControl/requestmethod.py.
Wasnt this part of the hotfix?
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
Zope-Dev maillist - Zope-Dev@zope.org
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-PAS] Re: Failing to fill users properties, should it cause an error?
According to Tres Seaver:
At the PAS level, we could add a new plugin interface, something like
'IIsUserValid', which would be called just after the roles plugins, and
which would block returning any user at all if required properties for
the site were not present.
+1
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
Zope-PAS mailing list
Zope-PAS@zope.org
http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope] POST sucks.
According to Paul Winkler:
Been doing web services (XML-RPC) stuff lately.
What suggestions do people have for troubleshooting a zope-based
XML-RPC application?
Access and trace logs are totally useless, since even the method name is
hidden in the POST payload, so I feel like I'm flying blind; when a
client developer tells me he gets occasional hangs, I have no idea what
kind of request triggers the hang.
I may end up sprinkling my code with a lot more logging calls than I'm used
to. Any other suggestions?
I found it very useful to log every xml-rpc call (call and return
value). For this we have patched ZPublisher/xmlrpc.py (and one line in
ZPublisher/HTTPRequest.py). See attachment (tested against 2.9.3).
The log entries look like that:
Sep 10 06:58:40 bach-s10 xmlrpc id=-177841652, client=137.208.89.23, \
user=stupl, inst=bach-s10.wu-wien.ac.at:10082, path=/bach/stupl/RPC, \
call=get_adreptl3(2002,)
Sep 10 06:58:40 bach-s10 xmlrpc id=-177841652, client=137.208.89.23, \
user=stupl, inst=bach-s10.wu-wien.ac.at:10082, time=88.27ms, out-ok, \
ret=[('E', 19007, None, 7066351, 1, None), ('E', 19010, None, ...
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
-included file follows-
--- xmlrpc.py.ori 2006-05-12 13:53:45.0 +0200
+++ xmlrpc.py 2006-09-12 18:52:39.094041280 +0200
@@ -21,11 +21,56 @@
import re
import sys, types
+import time
from HTTPResponse import HTTPResponse
import xmlrpclib
+import logging
+logger = logging.getLogger('event.xmlrpc')
+logger.setLevel(logging.INFO)
+hdlr = logging.handlers.SysLogHandler('/dev/log')
+logger.addHandler(hdlr)
from zExceptions import Unauthorized
+def log_before(request, method, response):
+# PATH_INFO, or PATH_TRANSLATED ???
+#url = request.base + request.environ['PATH_INFO']
+path = request.environ.get('PATH_INFO')
+host_port = request.environ.get('HTTP_HOST')
+user = request._authUserPW() # returns (user,pw) tuple or None
+if user:
+user = user[0]
+response.xmlrpc_timestamp = time.time()
+idstring = 'xmlrpc id=%u, client=%s, user=%s, inst=%s' % (
+ id(response), request._client_addr, user, host_port)
+args = '%s' % (request.args,)
+if len(args) 200: # syslog line limit: 1024
+sargs = []
+# XXX
+logger.info(
+ %s, path=%s, call=%s%s %
+ (idstring, path, method, request.args))
+response.xmlrpc_idstring = idstring
+
+def get_xmlrpc_info(response):
+ts = getattr(response, 'xmlrpc_timestamp', None)
+if ts:
+t = '%.2fms' % ((time.time() - ts) * 1000,)
+else:
+t = '-'
+idstring = (getattr(response, 'xmlrpc_idstring', None) or
+ 'xmlrpc %u' % (id(response),))
+return idstring,t
+
+def log_ok(response, ret):
+idstring, t = get_xmlrpc_info(response)
+logger.info(%s, time=%s, out-ok, ret=%s % (idstring, t, ret))
+
+def log_exception(response, errortext):
+idstring, t = get_xmlrpc_info(response)
+logger.info(
+%s, time=%s, out-error, exception=%s % (idstring, t, errortext))
+
def parse_input(data):
Parse input data and return a method path and argument tuple
@@ -97,8 +142,11 @@
def setBody(self, body, title='', is_error=0, bogus_str_search=None):
if isinstance(body, xmlrpclib.Fault):
+txt = str(body)
+log_exception(self, txt)
# Convert Fault object to XML-RPC response.
-body=xmlrpclib.dumps(body, methodresponse=1, allow_none=True)
+body=xmlrpclib.dumps(body, methodresponse=1, allow_none=True,
+ encoding='iso-8859-1')
else:
if type(body) == types.InstanceType:
# Avoid disclosing private members. Private members are
@@ -117,8 +165,13 @@
# was a Python None. This is now patched in xmlrpclib to
# allow Nones nested inside data structures too.
try:
+ret = '%s' % (body,)
+if len(ret) 80:
+ret = ret[:80] + '...'
body = xmlrpclib.dumps(
-(body,), methodresponse=1, allow_none=True)
+(body,), methodresponse=1, allow_none=True,
+encoding='iso-8859-1')
+log_ok(self, ret)
except:
self.exception()
return
@@ -141,6 +194,9 @@
isinstance(t, types.ClassType) and issubclass(t, Unauthorized)
):
+txt = '%s: %s' % (t, v)
+log_exception(self, txt)
+
return self._real.exception(fatal=fatal, info=info)
# Create an appropriate Fault object. Containing error information
--- HTTPRequest.py.orig 2006-05-12 13:53:45.0 +0200
+++ HTTPRequest.py 2006-06-01 10:23:57.272282896 +0200
@@ -394,6 +394,7 @@
Re: [Zope-PAS] PAS Caching (sucks)
According to Chris McDonough:
On Jul 29, 2006, at 10:28 AM, Jens Vagelpohl wrote:
I personally don't see any need to have caching in plugins
themselves. Instead, caching should be applied at the gateway
into the user folder, where it emits user objects. These user
objects should be cached as a whole. I am envisioning a thread-
independent cache (meaning no redundant lookups in each thread)
that is configured using a caching ZMI tab on the PAS instance. No
more Cache tab everywhere and no more RAM cache managers to
configure. And no more contortions in plugin code to utilize
ZCacheable.
+1 on caching in the gateway.
Who's got an opinion?
Hmmm.. PAS' trunk PluggableAutheService class already inherits from
OFS.Cacheable and its _findUser method uses the available cache, so
_findUser can be configured to use a cache, but _extractUserIds can
not. It would be cool if also _extractUserIds could use a cache, since
the authentication step takes place in there.
You do still need to configure the PAS instance to actually do
caching. But this seems OK. I think you can just ignore caching
when creating plugins if this is all you want. Even though the
ZCacheable API sucks, the indirection here is good. I wouldn't want
PAS itself to have a hard-wired caching implementation in it, and I
don't mind associating the PAS instance with a cache manager.
Nevertheless i think to PAS Caching needs improvement. Currently there
is no way to cache the authentication step in the gateway.
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
Zope-PAS mailing list
Zope-PAS@zope.org
http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-dev] 2.9.4? reStructuredText support?
According to Andreas Jung:
Tres' patch is looking in fine to me. I don't see a need right now
for dropping reST with having file inclusing *removed*.
Has anyone written tests for Tres' patch? Apparently no one wrote
adequate tests for the last hot fix, which helped put us in this
situation.
I've written some tests (checked in on the trunk). They test the 'raw'
and 'include' directives
Thank you, Andreas!
We make extensive use of reST (via ZWiki) and it would be very hard for
us to do without reST.
@Tres: what is the reason to keep the 'raw' code in docutils? I am in favor
to remove it and replace it with a NotImplementedError exception (same as
for the the 'include' code). The related tests (for reStructredText and
ZReST are commented for now) do except a NotImplementedError for a 'raw'
directive.
In ZWiki reST pages you can use the 'raw' directive to call
e.g. python scripts (useful for custom index generation, ...). If it
goes away due to security reasons, so be it. But if there is a way to
keep the 'raw' functionality and remove only 'file' and 'include', we
are certanly in favour of that...
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
Zope-Dev maillist - Zope-Dev@zope.org
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: xmlrpc OverflowError fault
According to Tres Seaver:
Trying to get a Zope DateTime object (as dictionary value) via xml-rpc
gives on OverflowError! You can try it yourself:
(I used a freshly installed Zope-2.9.3 [with python-2.4.3] on Linux
FC3; but other versions should behave equally.)
Add a Python Script in the Zope OFS root folder:
return {'root_modification_time': container.bobobase_modification_time()}
The www request returns:
{'root_modification_time': DateTime('2006/05/13 14:33:12.445 GMT+2')}
But the XML-RPC returns:
xmlrpclib.Fault: (-1, 'Unexpected Zope exception:
exceptions.OverflowError - long int exceeds XML-RPC limits'
A monkeypatch of the module should work fine, as the 'WRAPPERS' object
is looked up as a global at each use. If anybody *else* imports it
using 'from xmlrpc import WRAPPERS', then they won't see the new
registration after the monkeypatch, because 'WRAPPERS' is a tuple, and
must therefore be replaced, rather than mutated.
Tres, thanks for the hint! I updated my patch in the collector
(http://www.zope.org/Collectors/Zope/2109). Is there chance to get
this in the Zope distribution?
Thanks,
\wlang{}
$ cat xmlrpc-datetime.patch
--- DateTime/DateTime.py.ori2006-05-12 13:53:46.0 +0200
+++ DateTime/DateTime.py2006-05-15 23:15:40.485825640 +0200
@@ -1805,6 +1805,11 @@
d1 = (( d4 - L) % 365) + L
return d1/7 + 1
+# wlang, 2006-05: make DateTime instances marshallable via xml-rpc
+def encode(self, out):
+out.write(valuedateTime.iso8601)
+out.write(self.ISO8601())
+out.write(/dateTime.iso8601/value\n)
class strftimeFormatter:
--- ZPublisher/xmlrpc.py.ori2006-05-12 13:53:45.0 +0200
+++ ZPublisher/xmlrpc.py2006-05-15 23:15:05.055211912 +0200
@@ -23,6 +23,10 @@
import sys, types
from HTTPResponse import HTTPResponse
import xmlrpclib
+# wlang, 2006-05: monkeypatch to make DateTime marshallable via xml-rpc
+from DateTime import DateTime
+xmlrpclib.WRAPPERS = xmlrpclib.WRAPPERS + (DateTime,)
+
from zExceptions import Unauthorized
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
Zope-Dev maillist - Zope-Dev@zope.org
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 OverflowError fault
Trying to get a Zope DateTime object (as dictionary value) via xml-rpc
gives on OverflowError! You can try it yourself:
(I used a freshly installed Zope-2.9.3 [with python-2.4.3] on Linux
FC3; but other versions should behave equally.)
Add a Python Script in the Zope OFS root folder:
return {'root_modification_time': container.bobobase_modification_time()}
The www request returns:
{'root_modification_time': DateTime('2006/05/13 14:33:12.445 GMT+2')}
But the XML-RPC returns:
xmlrpclib.Fault: (-1, 'Unexpected Zope exception:
exceptions.OverflowError - long int exceeds XML-RPC limits'
The reason for this is, that the DateTime object is treated as a normal
instance by xmlrpclib, ie __dict__ is marshalled (which, unfortunately,
contains the attribute '_millis', which is usually too big).
It would be better anyway, if Zope DateTime objects would be
marshalled as XML-RPC dates (dateTime.iso8601). Eg like that:
--- xmlrpclib.py.ori2006-05-13 13:29:45.606954800 +0200
+++ xmlrpclib.py.wlang 2006-05-13 13:32:45.923542512 +0200
@@ -701,10 +701,15 @@
def dump_instance(self, value, write):
# check for special wrappers
+import DateTime as ZopeDateTime
if value.__class__ in WRAPPERS:
self.write = write
value.encode(self)
del self.write
+elif value.__class__ == ZopeDateTime.DateTime:
+self.write = write
+DateTime(value).encode(self)
+del self.write
else:
# store instance attributes as a struct (really?)
self.dump_struct(value.__dict__, write)
However, this would modify xmlrpclib.py from the python distribution,
wich is plain ugly.
Can anyone think of a better solution? Is it possible to change
xmlrpclib.WRAPPERS from Zope, but leave python's xmlrpclib.py
unaffected?
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
Zope-Dev maillist - Zope-Dev@zope.org
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] converting bytestreams from iso-8859-1 to utf-8
According to Giuseppe Bonelli:
sorry if this is not zope specific, but can someone please explain
to me the following behaviour when trying to convert an iso-8859-1 string
read from a file to an utf-8 encoded one?
s='\x93test\x94' #an iso-8859-1 string
#\x93 and \x94 are left and right
#double quotation marks,
#as seen in a browser set to iso-8859-1
\x93 and \x94 are *not* iso-8859-1 quotation marks. See for example
http://en.wikipedia.org/wiki/ISO_8859-1
Instead they seem to be from the Windows-125X (X=0,1,...) codepage:
http://www.microsoft.com/globaldev/reference/sbcs/1250.mspx
ss=unicode(s,'iso-8859-1').encode('utf-8')
gives
ss='\xc2\x93test\xc2\x94'
which is wrong (as seen in a browser set to utf-8)!
but:
unicode(s,'cp1250').encode('utf-8')
'\xe2\x80\x9ctest\xe2\x80\x9d'
is right.
Do I have to explicitly replace all characters above \x7F ?
No, you have to use the right encodings ;-)
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] Please vote about conflict errors logging
Florent Guillaume wrote at 2005-12-2 23:00 +0100:
Please vote for the level at which you want to log retried conflict
errors. These are the ConflictErrors that aren't returned to the user
but automatically retried by the Zope publisher.
1. Do you want these ConflictErrors retried logs to be at level:
- INFO
- BLATHER
- DEBUG
- not logged
- other
INFO
(i *really* want to know, if there are lots of conflict errors)
2. In addition, please specify if you feel those retried
ConflictErrors should have their full traceback logged?
- Yes, with traceback
- No, without traceback
No traceback
(as Dieter has pointed out, they contain no useful information)
3. Finally, please tell us if the ConflictErrors that *can't* be
retried (and are returned to the user as an error, and are also
logged to the error_log) should be additionally explicitely logged to
the event log, and at which level:
- ERROR
- not logged
- other
Like any other exception seen by the user
Thanks!
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
Zope-Dev maillist - Zope-Dev@zope.org
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] Python Classes and Zope.
According to Dario Lopez-Kästen:
But in order to even display it in a zpt I must transmogrify it into a
special zope-object, and *that* is not so easy as I have discovered.
In my case I am not so interested in importing the moduels or classes
into a Script(Python) - I have allready passed the objects in question
thtough my product, but still I get some Zope Does Not Allow That error.
You could add
__allow_access_to_unprotected_subobjects__ = 1
to your class. Then all attributes and methods of its instances should
be accessible from Zope. However, this can be a security problem, so
be careful...
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Visibility and CopyPaste support
According to Peter Bengtsson:
Some of these objects I don't want to encourage people to create via
the ZMI and I don't want to clutter up the Add new object drop down
with stuff that can't be added.
If I register the class, but set 'visibility=None' I still can't
copy/cut paste the instanciated objects. Why? What's the point of
the 'visibility=None' parameter?
As this has bitten me the last time...
The method
CopySupport.py: CopyContainer._verifyObjectPaste
is responsible for that. It refuses to paste objects with meta_types,
which are not found in the all_meta_types attribute of the target
object.
And yes, I find it (at least) irritating, that an object cannot be
pasted, only because it isn't in the product add list
(visibility=None). And the error message (when pasting) does not help
either:
The object ... does not support this operation.
Is there a way to hide products from the product add list without
losing the ability to paste its corresponding objects?
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ZEO troubles on RedHat EL4 Linux
According to Tim Peters:
I don't know. Dieter asked whether you ran the tests via zopectl
test, but I didn't see an answer to that.
Ok, here some data points...
bender:~/Zope-2.7.7-final$ cat /proc/version
Linux version 2.6.9-11.ELsmp ([EMAIL PROTECTED]) (gcc version 3.4.3 20050227
(Red Hat 3.4.3-22)) #1 SMP Fri May 20 18:26:27 EDT 2005
bender:~/Zope-2.7.7-final$ python2.3
Python 2.3.5 (#1, Apr 19 2005, 14:53:39)
[GCC 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)] on linux2
Type help, copyright, credits or license for more information.
Running one single test:
bender:~/Zope-2.7.7-final$ python2.3 test.py testConnection
checkNoVerificationOnServerRestart\$
Running unit tests from /home/wlang/Zope-2.7.7-final/lib/python
==
ERROR: checkNoVerificationOnServerRestart
(ZEO.tests.testConnection.FileStorageReconnectionTests)
--
Traceback (most recent call last):
File
/home/wlang/Zope-2.7.7-final/lib/python/ZEO/tests/ConnectionTests.py, line
121, in tearDown
os.waitpid(pid, 0)
OSError: [Errno 10] No child processes
--
Ran 1 test in 0.689s
FAILED (errors=1)
After some retries, the same test passes:
bender:~/Zope-2.7.7-final$ python2.3 test.py testConnection
checkNoVerificationOnServerRestart\$
Running unit tests from /home/wlang/Zope-2.7.7-final/lib/python
--
Ran 1 test in 0.691s
OK
Interesstingly, if i run the test with strace, i never see the test
fail (i tried at least 30 times):
bender:~/Zope-2.7.7-final$ strace -e trace=signal -o /var/tmp/zeotest.trc
python2.3 test.py testConnection checkNoVerificationOnServerRestart\$
Running unit tests from /home/wlang/Zope-2.7.7-final/lib/python
--
Ran 1 test in 0.710s
OK
(Obviously a Heisenberg effect -- the observation influences the
behaviour ;-)
If anyone is interessted in the trace file -- it can be found at:
http://slime.wu-wien.ac.at/misc/zeotest.trc
(However, it would be way more interessting to see the syscalls while
the test is failing...)
Also, i debugged the whole test with the python debugger. Unfortunatly
(as with strace), i was not able to reproduce the failing of the test
in the debugger.
the ZEO tests spawn processes directly via Python's
os.spawnve(), and later waits for them to end, via the waitpid() code
shown earlier. It doesn't muck around with signals, forks, or
anything else that should be platform-dependent (the same ZEO-test
process code is used on both Linux and Windows, BTW -- for this
reason, it can't rely on any fancy signal or process gimmicks;
spawnve+watipid is the entire story here).
Yes, its as simple as that: zeo ist started, zeo is stopped, and when
the parent calls waitpid, we get the No child processes error most of
the time :-(
Any ideas what we can try to narrow this down?
All the failures you showed were in test teardown. If that's all the
failures you got, then all the test bodies actually passed. Of course
you have to be wary that normal methods of detecting child-process
termination aren't working as hoped on this box, because all the test
failures you reported were exactly failures to detect child-process
termination.
Sure -- we could just make this change:
bender:.../ZEO/tests$ diff ConnectionTests.py.ori ConnectionTests.py
121c121,124
os.waitpid(pid, 0)
---
try:
os.waitpid(pid, 0)
except OSError:
pass
then all tests will pass. But then we will not know why the zeo zombie
vanishes before the waitpid can reap the exit code ;-)
\wlang{}
PS: i'am afraid it turns out to be a python thread / signals / race
problem -- yuck!
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] XML Export Error and Patch
According to Dieter Maurer:
Willi Langenberger wrote at 2004-11-10 23:28 +0100:
...
The following patch (implement extend like append) solves the problem
(for me!):
Please file a bug report with solution to
http://www.zope.org/Collectors/Zope
Ok, now that i figured out how to search in the collector, i
discovered that the issue is already there:
http://zope.org/Collectors/Zope/1219
http://zope.org/Collectors/Zope/1340
Sorry for the noise...
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
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] XML Export Error and Patch
Hi!
When i try to export a PluggableAuthService object as XML, (with ZMI
Import/Export or with manage_exportObject?id=acl_usersdownload=1toxml=Y)
i get the following exception:
Error Type: AttributeError
Error Value: List instance has no attribute 'extend'
[...]
Traceback (innermost last):
* Module ZPublisher.Publish, line 101, in publish
* Module ZPublisher.mapply, line 88, in mapply
* Module ZPublisher.Publish, line 39, in call_object
* Module OFS.ObjectManager, line 504, in manage_exportObject
* Module OFS.XMLExportImport, line 58, in exportXML
* Module OFS.XMLExportImport, line 33, in XMLrecord
* Module Shared.DC.xml.ppml, line 253, in load
* Module pickle, line 872, in load
* Module pickle, line 1209, in load_appends
Seems that the xml export calls the extend method of an
Shared.DC.xml.ppml.List object, which isnt implemented.
The following patch (implement extend like append) solves the problem
(for me!):
[EMAIL PROTECTED]:~$ diff -u -U10
Zope-2.7.2/lib/python/Shared/DC/xml/ppml.py.ori
Zope-2.7.2/lib/python/Shared/DC/xml/ppml.py
--- Zope-2.7.2/lib/python/Shared/DC/xml/ppml.py.ori 2002-08-14
23:51:00.0 +0200
+++ Zope-2.7.2/lib/python/Shared/DC/xml/ppml.py 2004-11-10 23:05:55.0
+0100
@@ -209,20 +209,22 @@
class Sequence(Collection):
def __init__(self, v=None):
if not v: v=[]
self._subs=v
def __len__(self): return len(self._subs)
def append(self, v): self._subs.append(v)
+def extend(self, v): self._subs.extend(v)
+
def value(self, indent):
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
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: Developing plugins for PluggableAuthService
According to Chris Withers:
Could you add this patch to the following collector issue:
http://zope.org/Members/urbanape/PluggableAuthService/Collector/4
Sure!
(i didnt do it in the first place, because it was already in CVS --
but you are right, it should be in the collector)
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
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: Developing plugins for PluggableAuthService
According to Chris Withers:
Is there any chance I could tempt you to change these to be Python 2.3
style logging calls? Zope will be moving to them for 2.8 and it'd be
great if you can change the code while you're in there...
Do you have an example at hand? I remember a posting to this list, but
i cannot find it :-(
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
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: Developing plugins for PluggableAuthService
According to Lennart Regebro:
No. Closer inspection seems to show that I actually don't get PAS to do
anything at all. It is simply ignored, unless I put it into the root, in
which case I can't do anything, since it doesn't care of emergency_user.
I also had this problem with the emergency user. Try the following patch:
-snip-snip---
$ diff -u PluggableAuthService.py.ori PluggableAuthService.py
--- PluggableAuthService.py.ori 2004-04-28 21:58:50.0 +0200
+++ PluggableAuthService.py 2004-07-31 23:08:22.0 +0200
@@ -784,7 +784,7 @@
user_id - decorated_user
-if user_id == self._emergency_user.getId():
+if user_id == self._emergency_user.getUserName():
return self._emergency_user
if cache is None:
-snip-snip---
At least it worked for me.
AFAIK its already in the CVS.
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
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] Segfault and Deadlock
Hi Zope (and Python) experts!
There seems to be a problem when an external python module segfaults
during a zope request. The remaining worker threads are deadlocked.
I think this is the same problem as Dieter pointed out in his message
to zope-dev [Problem] strange state after SIGSEGV:
http://mail.zope.org/pipermail/zope-dev/2004-March/022092.html
The reason is the way python handles threads on some systems
(RedHat-7.3, kernel 2.4.20, without NPTL). I've written a small python
extension, which does nothing but segfault[1]. With this, i made the
following simulation, where one thread acquires a lock and segfaults:
#!/usr/bin/env python2.3
import thread
import time
import _segfault
_lock = thread.allocate_lock()
def worker():
time.sleep(10)
_lock.acquire()
_segfault.segfault()
_lock.release()
thread.start_new_thread(worker, ())
thread.start_new_thread(worker, ())
thread.start_new_thread(worker, ())
thread.start_new_thread(worker, ())
time.sleep(3600)
print 'Bye...'
On my RedHat-7.3 box (kernel 2.4.20-18, without NPTL) i get the
following behaviour. After starting the program, pstree shows this:
bash(4103,wlang)---python2.3(4333)---python2.3(4334)-+-python2.3(4335)
|-python2.3(4336)
|-python2.3(4337)
`-python2.3(4338)
After the 10 seconds sleep, one worker gets the lock, and
segfaults. After that, pstree shows this:
init(1)-+-[...]
|-python2.3(4336,wlang)
|-python2.3(4337,wlang)
|-python2.3(4338,wlang)
Three remaining worker threads (without main thread).
Gdb shows, that they wait for the lock (but they wont get it):
(gdb) info stack
#0 0x420293d5 in sigsuspend () from /lib/i686/libc.so.6
#1 0x40031609 in __pthread_wait_for_restart_signal ()
from /lib/i686/libpthread.so.0
#2 0x4003272c in sem_wait@@GLIBC_2.1 () from /lib/i686/libpthread.so.0
#3 0x080c7b2d in PyThread_acquire_lock (lock=0x8170728, waitflag=1)
^
at Python/thread_pthread.h:406
[...]
(On a side note, as python threads block all signals, these worker
threads cannot be stopped with SIGTERM. They must be killed with SIGKILL.)
All this has the consequences Dieter described:
Consequences:
* Zope did no longer respond to requests
* stop did not work (as SIGTERM was ineffective)
* start did not work, as the dangling processes kept
the HTTP port bound.
So i think i know what's happening, but i don't know how to fix it!
Can anyone help please? Any hints are highly appreciated!
\wlang{}
PS: A RedHat-9 system (kernel 2.4.20, with NPTL) shows a different
behaviour. After the segfault, all threads disappeared. So maybe
all is ok with NPTL, but i've not tested it yet...
[1] segfault module
-segfault.c---
void
segfault(void)
{
char *x = 0;
*x = 'a';
}
-segfault.i
%module segfault
%{
%}
void segfault(void);
-building:--
$ swig -python segfault.i
$ gcc -I/usr/local/include/python2.3 -c segfault_wrap.c -o segfault_wrap23.o
$ gcc -c -o segfault.o segfault.c
$ gcc -shared segfault_wrap23.o segfault.o -o _segfault.so
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
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] Segfault and Deadlock
According to Dieter Maurer:
The reason is the way python handles threads on some systems
(RedHat-7.3, kernel 2.4.20, without NPTL).
What is NPTL?
Native POSIX Thread Library.
That is the good behaviour. Thus, we only have to learn
how we can get NPTL for all Linux systems.
However, i dont know enough about NPTL. Only that it caused us some
grief when we migrated applications from RedHat-7.3 to RedHat-9 (we
had to set LD_ASSUME_KERNEL=2.4.1 for some applications [including
oracle] to work).
By the way, nobody answered my problem report on comp.lang.python.
Was maybe a bad time, during Pycon.
Yes, i think it is more a python problem than a zope problem. But it
bites the Zope server on a linux system w/o NPTL. Maybe we have more
luck this time...
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
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] zope 2.7.0: no tracebacks produced
According to Mika, David P (Research):
I am making a big upgrade and moving my products from 2.3.1 on HP-UX
to 2.7.0 on windows 2000 and can't get zope to produce any tracebacks
when it encounters errors. I've checked all the log files and monitor
stdout
to no avail. All I get is a brief html message with error type and value
and
instructions to check the error log.
from Zope-2.7.0/lib/python/ZPublisher/HTTPResponse.py:
# Enable APPEND_TRACEBACKS to make Zope append tracebacks like it used to,
# but a better solution is to make standard_error_message display error_tb.
APPEND_TRACEBACKS = 0
\wlang{}
--
[EMAIL PROTECTED]Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
___
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 )
