1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
|
Gear: Asynchronous Event-Driven Gearman Interface
=================================================
.. module:: gear
:synopsis: Asynchronous Event-Driven Gearman Interface
This module implements an asynchronous event-driven interface to
Gearman. It provides interfaces to build a client or worker, and
access to the administrative protocol. The design approach is to keep
it simple, with a relatively thin abstration of the Gearman protocol
itself. It should be easy to use to build a client or worker that
operates either synchronously or asynchronously.
Client Example
--------------
To use the client interface, instantiate a
:py:class:`Client`, and submit a :py:class:`Job`. For example::
import gear
client = gear.Client()
client.addServer('gearman.example.com')
client.waitForServer() # Wait for at least one server to be connected
job = gear.Job("reverse", "test string")
client.submitJob(job)
The waitForServer() call is only necessary when running in a
synchronous context. When running asynchronously, it is probably more
desirable to omit that call and instead handle the
:py:class:`NoConnectedServersError` exception that submitJob may
raise if no servers are connected at the time.
When Gearman returns data to the client, the :py:class:`Job` object is
updated immediately. Event handlers are called on the
:py:class:`Client` object so that subclasses have ample facilities for
reacting to events synchronously.
Worker Example
--------------
To use the worker interface, create a :py:class:`Worker`, register at
least one function that the worker supports, and then wait for a Job
to be dispatched to the worker.
An example of a Gearman worker::
import gear
worker = gear.Worker('reverser')
worker.addServer('gearman.example.com')
worker.registerFunction("reverse")
while True:
job = worker.getJob()
job.sendWorkComplete(job.arguments.reverse())
API Reference
=============
The following sections document the module's public API. It is
divided into sections focusing on implementing a client, a worker,
using the administrative protocol, and then the classes that are
common to all usages of the module.
Client Usage
------------
The classes in this section should be all that are needed in order to
implement a Gearman client.
Client Objects
^^^^^^^^^^^^^^
.. autoclass:: gear.Client
:members:
:inherited-members:
Job Objects
^^^^^^^^^^^
.. autoclass:: gear.Job
:members:
:inherited-members:
Worker Usage
------------
The classes in this section should be all that are needed in order to
implement a Gearman worker.
Worker Objects
^^^^^^^^^^^^^^
.. autoclass:: gear.Worker
:members:
:inherited-members:
FunctionRecord Objects
^^^^^^^^^^^^^^^^^^^^^^
.. autoclass:: gear.FunctionRecord
:members:
:inherited-members:
WorkerJob Objects
^^^^^^^^^^^^^^^^^
.. autoclass:: gear.WorkerJob
:members:
:inherited-members:
Administrative Protocol
-----------------------
Gearman provides an administrative protocol that is multiplexed on the
same connection as the normal binary protocol for jobs. The classes
in this section are useful for working with that protocol. They need
to be used with an existing :py:class:`Connection` object; either one
obtained via a :py:class:`Client` or :py:class:`Worker`, or via direct
instantiation of :py:class:`Connection` to a Gearman server.
AdminRequest Objects
^^^^^^^^^^^^^^^^^^^^
.. autoclass:: gear.AdminRequest
:members:
:inherited-members:
.. autoclass:: gear.StatusAdminRequest
:inherited-members:
.. autoclass:: gear.ShowJobsAdminRequest
:inherited-members:
.. autoclass:: gear.ShowUniqueJobsAdminRequest
:inherited-members:
.. autoclass:: gear.CancelJobAdminRequest
:inherited-members:
.. autoclass:: gear.VersionAdminRequest
:inherited-members:
Common
------
These classes do not normally need to be directly instatiated to use
the gear API, but they may be returned or otherwise be accessible from
other classes in this module. They generally operate at a lower
level, but still form part of the public API.
Connection Objects
^^^^^^^^^^^^^^^^^^
.. autoclass:: gear.Connection
:members:
:inherited-members:
Packet Objects
^^^^^^^^^^^^^^
.. autoclass:: gear.Packet
:members:
:inherited-members:
Exceptions
^^^^^^^^^^
.. autoexception:: gear.ConnectionError
.. autoexception:: gear.InvalidDataError
.. autoexception:: gear.ConfigurationError
.. autoexception:: gear.NoConnectedServersError
.. autoexception:: gear.UnknownJobError
.. autoexception:: gear.InterruptedError
Constants
---------
These constants are used by public API classes.
.. py:data:: PRECEDENCE_NORMAL
Normal job precedence.
.. py:data:: PRECEDENCE_LOW
Low job precedence.
.. py:data:: PRECEDENCE_HIGH
High job precedence.
.. automodule:: gear.constants
:members:
Indices and tables
==================
* :ref:`genindex`
* :ref:`modindex`
* :ref:`search`
|
