NAME¶
Gearman::Server::Client - client for gearmand
NAME¶
Used by Gearman::Server to instantiate connections from clients. Clients speak
either a binary protocol, for normal operation (calling functions, grabbing
function call requests, returning function values, etc), or a text-based line
protocol, for relatively rare administrative / monitoring commands.
The binary protocol commands aren't currently documented. (FIXME) But they're
well-implemented in Gearman::Client, Gearman::Worker, and
Gearman::Client::Async, if that's any consolation.
The line-based administrative commands are documented below.
Binary Protocol Structure¶
All binary protocol exchanges between clients (which can be callers, workers, or
both) and the Gearman server have common packet header:
4 byte magic -- either "\0REQ" for requests to the server, or
"\0RES" for responses from the server
4 byte type -- network order integer, representing the packet type
4 byte length -- network order length, for data segment.
data -- optional, if length is non-zero
Binary Protocol Commands¶
echo_req (type=16)¶
A debug command. The server will reply with the same data, in a echo_res
(type=17) packet.
(and many more...)¶
FIXME: auto-generate protocol docs from internal Gearman::Util table, once
annotated with some English?
Line based commands¶
These commands are used for administrative or statistic tasks to be done on the
gearman server. They can be entered using a line based client (telnet, etc.)
by connecting to the listening port (7003) and are also intended to be machine
parsable.
"workers"¶
Emits list of registered workers, their fds, IPs, client ids, and list of
registered abilities (function names they can do). Of format:
fd ip.x.y.z client_id : func_a func_b func_c
fd ip.x.y.z client_id : func_a func_b func_c
fd ip.x.y.z client_id : func_a func_b func_c
.
It ends with a line with just a period.
"status"¶
The output format of this function is tab separated columns as follows, followed
by a line consisting of a fullstop and a newline (".\n") to indicate
the end of output.
- Function name
- A string denoting the name of the function of the job
- Number in queue
- A positive integer indicating the total number of jobs for this function
in the queue. This includes currently running ones as well (next
column)
- Number of jobs running
- A positive integer showing how many jobs of this function are currently
running
- Number of capable workers
- A positive integer denoting the maximum possible count of workers that
could be doing this job. Though they may not all be working on it due to
other tasks holding them busy.
"jobs"¶
Output format is zero or more lines of:
[Job function name]\t[Uniq (coalescing) key]\t[Worker address]\t[Number of listeners]\n
Follows by a single line of:
.\n
\t is a literal tab character \n is perl's definition of newline (literal \n on
linux, something else on win32)
"clients"¶
Output format is zero or more sections of:
One line of:
[Client Address]\n
Followed by zero or more lines of:
\t[Job Function]\t[Uniq (coalescing) key]\t[Worker Address]\n
Follows by a single line of:
.\n
\t is a literal tab character \n is perl's definition of newline (literal \n on
linux, something else on win32)
"maxqueue" function [max_queue_size]¶
For a given function of job, the maximum queue size is adjusted to be
max_queue_size jobs long. A negative value indicates unlimited queue size.
If the max_queue_size value is not supplied then it is unset (and the default
maximum queue size will apply to this function).
This function will return OK upon success, and will return ERR incomplete_args
upon an invalid number of arguments.
"shutdown" ["graceful"]¶
Close the server. Or "shutdown graceful" to close the listening
socket, then close the server when traffic has died away.
"version"¶
Returns server version.