/ 
Gearman-Server-v1.130.1
River stage one • 7 direct dependents • 7 total dependents
/ Gearman::Server::Client

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.