Personal tools
Skip to content. | Skip to navigation
Programmable web browser for functional black-box testing of web applications
The thread-creation API provided by the Python threading module is annoying. :) This package provides a very simple thread-creation API that: Makes threads daemonic and allows daemonicity to be passed to the constructor. For example: zc.thread.Thread(mythreadfunc) Starts a daemonic thread named 'mythreadfunc' running mythreadfunc. Allows threads to be defined via decorators, as in: import zc.thread @zc.thread.Thread def mythread(): ... In the example above, a daemonic thread named mythread is created and started. The thread is also assigned to the variable mythread. You can control whether threads are daemonic and wether they are started by default: import zc.thread @zc.thread.Thread(daemon=False, start=False) def mythread(): ... After a thread finishes, you can get the return value of the target function from the thread's value attribute, or, if the function raises an exception, you can get the exception object from the thread's exception attribute. (This feature was inspired by the same feature in gevent greenlets.) There's also a Process constructor/decorator that works like Thread, but with multi-processing processes, and without the value and exception attributes.
Twist: Talking to the ZODB in Twisted Reactor Calls The twist package contains a few functions and classes, but primarily a helper for having a deferred call on a callable persistent object, or on a method on a persistent object. This lets you have a Twisted reactor call or a Twisted deferred callback affect the ZODB. Everything can be done within the main thread, so it can be full-bore Twisted usage, without threads. There are a few important "gotchas": see the Gotchas section below for details. The main API is Partial. You can pass it a callable persistent object, a method of a persistent object, or a normal non-persistent callable, and any arguments or keyword arguments of the same sort. DO NOT use non-persistent data structures (such as lists) of persistent objects with a database connection as arguments. This is your responsibility. If nothing is persistent, the partial will not bother to get a connection, and will behave normally.
The Zope 3 monitor server is a server that runs in a Zope 3 process and that provides a command-line interface to request various bits of information. It is based on zc.monitor, which is itself based on zc.ngi, so we can use the zc.ngi testing infrastructure to demonstrate it. This package provides several Zope 3 and ZODB monitoring and introspection tools that work within the zc.monitor server. These are demonstrated below. Please see the zc.monitor documentation for details on how the server works. This package also supports starting a monitor using ZConfig, and provides a default configure.zcml for registering plugins. The ZConfig setup is not demonstrated in this documentation, but the usage is simple.
The zc.zk package provides some high-level interfaces to the low-level zookeeper extension. It's not complete, in that it doesn't try, at this time, to be a complete high-level interface. Rather, it provides facilities we need to use ZooKeeper to connect services: ZODB database clients and servers HTTP-based clients and services Load balancers and HTTP application servers The current (initial) use cases are: Register a server providing a service. Get the addresses of servers providing a service. Get and set service configuration data. Model system architecture as a tree.
Managing addresses, and especially ports is a drag. ZooKeeper can be used as a service registry. Servers can register themselves and clients can find services there. The zc.zkzeo package provides support for registering ZEO servers and a ZEO client storage that gets addresses from ZooKeeper.
zc.zkzopeserver provides a wrapper for the zope.server WSGI runner that registers with ZooKeeper. By registering with ZooKeeper, you can let the operating system assign ports and have clients find your server by looking in ZooKeeper.
secondary storages will automatically replicate data from the primary storage. Replication is superior to back-ups because as long as secondaries are running, secondary data is kept updated. In the event of a failure of a primary storage, just reconfigure a secondary to be the primary, and it can begin handling application requests. Features Primary/secondary replication Support for read-only secondary storages Service registration and discovery with ZooKeeper
zdaemon is a Python package which provides APIs for managing applications run as daemons. Its principal use to date has been to manage the application server and storage server daemons for Zope / ZEO, although it is not limited to running Python-based applications (for instance, it has been used to manage the 'spread' daemon).
This package contains the ZEO server and necessary startups