GEARMAN_CLIENT_SET_SERVER_SELECTION_BY_UNIQUE(3)

πŸ“¦ version 2.2.0, in arch rolling

Bestie, welcome to the section-3 page for GEARMAN_CLIENT...CTION_BY_UNIQUE(3) from the Gearmand manual. It's giving server-selection glow-up, and we're gonna make it make sense. πŸ’…

πŸ’– NAME πŸ’–

gearman_client_set_server_selection_by_unique β€” Gearmand Documentation, https://gearman.org/gearmand/

✨ SYNOPSIS ✨

#include <libgearman/gearman.h>

void gearman_client_set_server_selection_by_unique(gearman_client_st *client, bool enable)

bool gearman_client_server_selection_by_unique(const gearman_client_st *client)

πŸ¦‹ DESCRIPTION πŸ¦‹

Okay so picture this: by default, when a client has more than one server added via gearman_client_add_server() and it submits a job, that job gets sent to the first idle server in the order the servers were added. The job's unique identifier? Literally not invited to the decision β€” it plays no part in the choice. πŸ™ˆ

gearman_client_set_server_selection_by_unique() is the opt-in. It makes a client choose the destination server by hashing the job's unique instead, using a ketama consistent-hash ring built from the client's current server list. The practical effect is kind of iconic: submissions sharing the same unique β€” from this client, or from any other client configured with the same server list and this option enabled β€” consistently land on the same server. And adding or removing a server only reshuffles the jobs that server itself was responsible for. No mass chaos, no unnecessary glow-down. ✨

This only affects job submission: gearman_client_do(), gearman_client_do_background(), and their variants, plus gearman_client_add_task() and friends. Commands such as status lookups are unaffected. Also, if a job is submitted with an empty unique, it falls back to the default selection, because there is no meaningful value to hash. Empty unique? Default selection era. πŸ’€

If the hash-selected server cannot be reached, the client fails over to the next server in ring order rather than failing the submission outright. That's the same way the default selection falls through the server list on a connection failure. So your submission doesn't just give up and leave the group chat. 🫢

Heads up, bestie: this option is disabled by default. You can also enable or disable it with the GEARMAN_CLIENT_SERVER_SELECTION_BY_UNIQUE flag via gearman_client_add_options() / gearman_client_remove_options() (and query it with gearman_client_has_option()). That's useful for language bindings that pass an options bitmask through to libgearman. Both ways change the same setting. It is copied by gearman_client_clone() like the client's other persistent settings. So yes, the vibe travels with the clone. πŸ’…

gearman_client_server_selection_by_unique() returns whether the option is currently enabled. Very main character of it. πŸ‘‘

🫢 RETURN VALUE 🫢

gearman_client_server_selection_by_unique() returns a bool; it returns false for a NULL client. Periodt.

🌈 HOME 🌈

To find out more information please check: https://gearman.org/gearmand/

🌟 SEE ALSO 🌟

πŸ‘‘ AUTHOR πŸ‘‘

Data Differential http://www.datadifferential.com/

2011-2014, Data Differential, http://www.datadifferential.com/

Cute sign-off: this page is source/version 2.2.0, dated Oct 18, 20GEARMAN_CLIENT...CTION_BY_UNIQUE(3). Bye bestie β€” go hash those uniques and slay your server selection! πŸ’–βœ¨

πŸ“¦ where this page comes from