Running vshard routers on application threads
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 68/100
- Tipo di issue
- Documentazione
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- lua
- Ambito
- documentation
Direzione di ricerca
Inizia trovando la documentazione sulla configurazione del router vshard e la sezione relativa a sharding.router_thread_group. Spiega che il gruppo deve essere definito in threads.groups e documenta le note sui thread dell’applicazione riguardanti le esportazioni IPROTO, i privilegi lua_call e il comportamento di bootstrap per thread. Il lavoro è completato quando gli utenti possono configurare e usare i router sui thread dell’applicazione seguendo le indicazioni documentate.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The new configuration option sharding.router_thread_group specifies
the name of the thread group where the vshard router module will be
loaded and configured. The group must be defined in threads.groups.
The default value is "tx" (run the router on the main thread).
Using an alternative thread group is the way to scale the vshard router
performance within the same process, without spawning extra Tarantool
instances.
Notes about using vshard in application threads:
- Adding a function to the global Lua namespace
_Gin an application
thread does not export the function in IPROTO. Instead you should use
box.iproto.export(), which works both in the main and application
threads. - To grant a user a permission to execute a function exported in an
application thread over IPROTO, you should add the corresponding
lua_callprivilege to the config file. The execute access to
the universe or the super role won't work. - Each application thread acts as an independent router although they
all take requests from the same IPROTO port. In particular, this
means thatvshard.router.bootstrapshould be called once or
if_not_bootstrappedoption should be used, just like with routers
running on different Tarantool instances.
Requested by @locker in https://github.com/tarantool/tarantool/commit/68fe9c1da2cf4f4a2d83ce7356faf30cd1c9d250.
- Lingua principale
- CSS
- Stelle
- 16
- Fork
- 49
- Merge medio
- 5g 18h
- PR unite (30g)
- 1
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di tarantool/doc
-
dictionary size soft limitAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 63/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
Tutte le issue di tarantool/doc
Issue simili
-
bug documentation
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100
apify/apify-docs#3206 ·
I maintainer di solito rispondono entro 1 giorno
-
docs size:S
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
documentation good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
zerohourzulu/irontrellis#16 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 65/100
Droid-Deck/DroidDeck#2198 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
better-auth/better-auth#12292 · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno