Warning
This documentation is for an old version of IPython. You can find docs for newer versions here.
The IPython Controller Hub with 0MQ This is the master object that handles connections from engines and clients, and monitors traffic through the various queues.
Authors:
Bases: IPython.utils.traitlets.HasTraits
A simple object for accessing the various zmq connections of an object. Attributes are: id (int): engine ID uuid (unicode): engine UUID pending: set of msg_ids stallback: DelayedCallback for stalled registration
Bases: IPython.parallel.factory.RegistrationFactory
The Configurable for setting up a Hub.
return full zmq url for a named client channel
return full zmq url for a named engine channel
construct Hub object
Bases: IPython.kernel.zmq.session.SessionFactory
The IPython Controller Hub with 0MQ connections
Parameters: | loop: zmq IOLoop instance : session: Session object : <removed> context: zmq context for creating new connections (?) : queue: ZMQStream for monitoring the command queue (SUB) : query: ZMQStream for engine registration and client queries requests (ROUTER) : heartbeat: HeartMonitor object checking the pulse of the engines : notifier: ZMQStream for broadcasting engine registration changes (PUB) : db: connection to db for out of memory logging of commands :
engine_info: dict of zmq connection information for engines to connect :
client_info: dict of zmq connection information for engines to connect :
|
---|
# universal: loop: IOLoop for creating future connections session: streamsession for sending serialized data # engine: queue: ZMQStream for monitoring queue messages query: ZMQStream for engine+client registration and client requests heartbeat: HeartMonitor object for tracking engines # extra: db: ZMQStream for db connection (NotImplemented) engine_info: zmq address/protocol dict for engine connections client_info: zmq address/protocol dict for client connections
Reply with connection addresses for clients.
Perform a raw query on the task record database.
all ME and Task queue messages come through here, as well as IOPub traffic.
Route registration requests and queries from clients.
Second half of engine registration, called after our HeartMonitor has received a beat from the Engine’s Heart.
Get a list of all msg_ids in our DB records
Get the result of 1 or more messages.
handler to attach to heartbeater. called when a previously registered heart fails to respond to beat request. triggers unregistration
handler to attach to heartbeater. Called when a new heart starts to beat. Triggers completion of registration.
Purge results from memory. This method is more valuable before we move to a DB based message storage mechanism.
Return the Queue status of one or more targets. if verbose: return the msg_ids else: return len of each type. keys: queue (pending MUX jobs)
tasks (pending Task jobs) completed (finished jobs from both queues)
Register a new engine.
Resubmit one or more tasks.
save an iopub message into the db
Save the submission of a task.
save the result of a completed task.
handle shutdown request.
Unregister an engine that explicitly requested to leave.