August 2002 - Zope-Dev

ZEO 2.0 beta 1 released
by Jeremy Hylton 29 Aug '02

29 Aug '02

We've just released ZEO 2.0 beta 1.It's available from http://www.zope.org/Products/ZEO. We think this release of ZEO 2 is fairly stable, although we may do one more beta release to add some performance improvements. There are many changes since ZEO 2.0a1, which was released in May. The CHANGES.txt file describes the most significant changes; I've included the 2.0b1 changes list at the end of this message. The ZEO 2 protocol is not backwards compatible with ZEO 1. If you want to upgrade a system, all the clients and servers need to be upgraded at the same time. I don't plan to provide backwards compatibility for 2.0, but could be convinced otherwise if there is significant user demand. In the alpha release, we reported that the test suite was a bit fragile on Windows. It is much better now. We have tested on Windows 2000 and Windows 98, and expect all the tests to pass. The tests may run very slow on Windows, because many of the tests spawn server processes. The Windows scheduler can make this very slow. On occasion, we've seen the tests hang for several minutes before finishing successfully. After the alpha release, I suggested that there would be several more alpha releases to add new features. We didn't have the resources to pursue the new features. Instead, we plan to get a solid 2.0 final release out as soon as possible. New features will be postponed until 2.1. Jeremy The changes since ZEO 2.0a1 release are: - Added version identification. The variable ZEO.version is a string identifying the version in the style of sys.version. The same string is also available in ZEO/version.txt for people who want to check without loading the code. - Fixed performance problem. The low-level socket code was often calling send() with very small strings instead of joining them together before calling send. The small string variant ran afoul of the Nagle algorithm and delayed TCP acks. - Fix bugs in server handling of queued transactions Several bugs in 2.0a1 could cause the storage to lock up when it attempted to restart a transaction that was queued waiting for an earlier transaction to finish. The locking code in the two-phase commit methods was revised to properly use the condition variable protocol. Thanks to Tim Peters for pointing this out. - Avoid locking up server on unexpected client exit If a client disconnected unexpectedly in the middle of a two- phase commit, the server would never release the commit lock. - Very long log messages avoided. Some of the logging messages at BLATHER and lower were producing very long log messages because they included all the argument of method calls, even when the argument was a list with thousands of elements. These log messages are now truncated at a reasonable length. - Fix log rotation The SIGHUP behavior was fixed. If the ZEO server receives a SIGHUP, it will re-initialize its logging code. Thus, it is possible to rotate the log files and then send a HUP. - Fixed problem handling signals. The asyncore and zrpc error handlers would trap SystemExit if it was raised by a signal handler. They now ignore it. - pack() can be called on a read-only connection This ends up being very convenient for packing a read-only server, even though it isn't obvious that pack() is a read- only operation. - pack(wait=1) now waits A bug caused pack(wait=1) to return immediately, even though the pack was still running. - Fix bug in history(). The history() implementation prevent the client from returning more than one item. - Enhanced logging for blocked transactions. If a transaction had to be blocked because another transaction was executing, the server would log an info message. Now it also logs a message when the transaction is resumed, so that it doesn't look like the transaction was blocked forever. - Fixed bug in logging call for store(). The logging call could raise NameError. - Removed debug argument to ClientStorage constructor. It had no effect. - Removed ZEO.trigger There were two copies of the trigger module in the last release. The one in ZEO.trigger was removed, because it is only needed in ZEO.zrpc.trigger. - Added minimal tests of start.py. There are only run on Unix.

3 4

Windows Zope Install
by Andy McKay 29 Aug '02

29 Aug '02

Can anyone point me to the location of the configuration file for the Windows install in CVS? I'm sure Brian pointed it out to me once, but I cant find it at the moment... -- Andy McKay Agmweb Consulting http://www.agmweb.ca

2 2

[Fwd: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs]
by Chris Withers 29 Aug '02

29 Aug '02

I think Tim meant this to go to the list ;-) Chris -------- Original Message -------- Subject: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs Date: 29 Aug 2002 14:36:30 +0800 From: Tim Hoffman <timhoffman(a)cams.wa.gov.au> To: Chris Withers <chrisw(a)nipltd.com> References: <3D66A3E5.5050302(a)gmx.net> <001b01c24aea$6fa37060$6717a8c0@dorothy> <3D66B042.1090900(a)gmx.net> <1030196732.1365.34.camel@james> <3D67C9D7.4000501(a)gmx.net> <1030216329.1327.114.camel@james> <3D6CB8AD.40206(a)nipltd.com> Hi Just my 2c worth, I wouldn't want this to be a blanket approach if it where ever implemented. If my ZODB is so big that it takes half an hour to rebuild, I would hate it to be aborted just because the browser lost it's connection (ie IE crashed ;-) or running a big import. I don't need the browser to hang around for the end result, I just want it to complete at some point. (ie kicking off long running processes through xml-rpc, I don't want to keep the connection open for the duration.) Either you can programatically look at the state of the connection (within the process and chose to kill it) or there was a console tool so that you could see long running threads and kill them. Rgds Tim On Wed, 2002-08-28 at 19:49, Chris Withers wrote: > I know I'm late in on this thread, but I thought I'd throw in my views. > > I'd like to see the REQUEST be flat plain aborted when someone hits the stop > button or the connection dies. > > I don't is the is context.REQUEST.RESPONSE.isClientConnected() really working. > How would I plug this in an expensive SQL SELECT/JOIN? Why do we need this extra > programming overhead? > > As for the long running administrative tasks, I actually see the ability to > bugger off and leave them running as an extremely bad thing. Say I hit 'pack' on > a big fat ZODB. I then go somewhere else. How do I now tell when its done? The > only was would be to go and look at 'top' and guess which python thread is doing > the pack and wait till its CPU usage drops to zero. That's pretty ropey ;-) > For the same reason, I hate ZEO's pack's possibility of returning before a pack > is finished. > > If you do a pack, I really think you should wait for the browser to return. If > the browser times out, then use something like wget. If I hit 'stop', the pack > should abort. > > As a parting example, what happens if I accidentally start a pack? How can I > stop it? ;-) > > cheers, > > Chris > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope )

4 3

ZMI: preserve the sort criteria
by THerp＠apriori.de 29 Aug '02

29 Aug '02

I often sort the object list in the ZMI by modification date, to get the script on top I'm currently working on. However, whenever I navigate to another folder, the default sorting is by name. I'd like it very much if the sort criteria would be kept until changed explicitly, e. g. by storing it in the SESSION. Cheers, Tobias Herp Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das un- erlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

1 0

Slow zope on windows 2000?
by mart＠eastsite.nl 29 Aug '02

29 Aug '02

Hello, I have a question for you zope administrators out there : What are your experiences whith zope running on Windows NT/2K? No matter what I try , zope will run significant faster on a Unixlike system (with the same hardware), especially when working alot with the ZCatalog. Do you guys have any proposals how to make zope run faster on windows? My own experience is also that zope runs faster with the "start.bat" way instead as a Windows NT Service. Strange, because I tried several numbers of threads with both ways with the same startup parameters. Thnx in advance, Martijn Jacobs East Site.

9 9

RE: [Zope-dev] Slow zope on windows 2000?
by sean.upton＠uniontrib.com 28 Aug '02

28 Aug '02

Actually, I believe that NT Workstation ran dynamic web apps better than NT server. This was because the tuning on NT server out of the box was really geared toward file-server type applications. I assume the case is the same with win2k. At that, I don't think is would be noticeable enough, except under real stress. Sean -----Original Message----- From: Arndt Droullier [mailto:ad@dvelectric.com] Sent: Wednesday, August 28, 2002 12:13 PM To: zope-dev(a)zope.org Subject: AW: [Zope-dev] Slow zope on windows 2000? > This, however, is almost an order of magnitude difference, and may need > further investigation... > > Adam > There´s also a difference between Win2000 and Win2000 Server. The Server version is optimised for network and system operations(thread/memory allocation) and really much faster than the normal edition. I suppose you will have a magnificant performance difference with Zope on these two systems. Arndt _______________________________________________ Zope-Dev maillist - Zope-Dev(a)zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )

1 0

Acquisition and method lookup: loosing acquisition context
by Dieter Maurer 28 Aug '02

28 Aug '02

Acquisition lookup for (ExtensionClass'es Python) methods is not done through the standard "__of__" call but handled specially: if (PyECMethod_Check(r) && PyECMethod_Self(r)==self->obj) ASSIGN(r,PyECMethod_New(r,OBJECT(self))); As a consequence, the method's "im_self" is not fully acquisition wrapped. Rather, the context is more or less stripped down. I would find it more naturally, when (ExtensionClass'es Python) methods conceptually had an "__of__" method that relays the context to "im_self". The code above would then become: if (PyECMethod_Check(r)) { im_self= PyECMethod_Self(r); if (has__of__(im_self)): ASSIGN(r,PyECMethod_New(r,__of__(im_self,OBJECT(self)))); } This could be optimized to: if (PyECMethod_Check(r)) { im_self= PyECMethod_Self(r); if (im_self==self->obj) ASSIGN(r,PyECMethod_New(r,OBJECT(self))); else if (has__of__(im_self)): ASSIGN(r,PyECMethod_New(r,__of__(im_self,OBJECT(self)))); } But maybe, there is a reason for the special rule. I am unhappy with the special method treatment because my "References" product does not work as expected due to the leaking context. Most applications using "getattr" to look up methods in other objects will suffer from the same problem. Dieter

1 0

AW: [Zope-dev] Slow zope on windows 2000?
by Arndt Droullier 28 Aug '02

28 Aug '02

> This, however, is almost an order of magnitude difference, and may need > further investigation... > > Adam > There´s also a difference between Win2000 and Win2000 Server. The Server version is optimised for network and system operations(thread/memory allocation) and really much faster than the normal edition. I suppose you will have a magnificant performance difference with Zope on these two systems. Arndt

2 1

RE: [Zope-dev] Slow zope on windows 2000?
by sean.upton＠uniontrib.com 28 Aug '02

28 Aug '02

For what its worth, a long time ago, with an ancient version of Zope running on the original W2k Professional on my home machine (minus any service packs), Zope (running as a service) was magnitudes of order slower after coming back from a system Hibernate; I no longer hibernate/power-manage Win2k, nor run Zope on Windows, so I'm really not sure why this was, and likely will never know. Sean -----Original Message----- From: Adam Manock [mailto:abmanock@earthlink.net] Sent: Wednesday, August 28, 2002 10:51 AM To: zope-dev(a)zope.org Subject: Re: [Zope-dev] Slow zope on windows 2000? > >I'm not sure that is the case you know. Oracle 9i Linux is faster on my >Linux Athlon 800 than the same release on my Win2k Dual Piii 1GHz. > >Also my Win box has 1Gb ram, while my Linux box has only 512Mb... In other news.... Apache is reported to run faster on Linux that Win2000, as is PostgreSQL. Samba is reported to provide double the throughput of Win2000 native file services, with half the response delay for client requests. >Very much so! On a Win2k with Dual P3 1Ghz Zope runs slower than the same >install on a Linux box with 1 P133 !!!! (I have tested this on multiple >different configurations and every time it comes out the same) This, however, is almost an order of magnitude difference, and may need further investigation... Adam _______________________________________________ Zope-Dev maillist - Zope-Dev(a)zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )

1 0

Handling of ECONNRESET socket error in asyncore.py
by Oliver Bleutgen 28 Aug '02

28 Aug '02

It just thought about the fact that zope on linux seemingly does ignore when the user presses of the stop on his browser. I.e., if you access a e.g. long running python(script) and press "Stop" on the browser and you'll see the thread which runs the script is still working. Extremely ugly IMO. Well, it also happens on win. I just looked at asyncore.dispatcher, and there's the recv() method: def recv (self, buffer_size): try: ... except socket.error, why: # winsock sometimes throws ENOTCONN if why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN]: self.handle_close() return '' else: raise socket.error, why The browser closes the connection when the Stop button is pressed, that means that the recieving end gets a RST, and that seems to throw a socket.error, with why[0] == ECONNRESET. Well, I know jack about the python socket class, but a strategical placed "print" tells more than a thousand words ;-). handle_close() doesn't also do much, just logs and closes the connection. So, the poor thread never does never find out about the fact that all his work is for nothing, and happily continues. Can't this be fixed anyhow? cheers, oliver

5 17