Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Definition edges an ordinary transaction commits don't reach the schema caches of other instances

Chiusa
  • Qualcosa non va?
#4,982 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java
Ambito
backend, databases, distributed-systems

Direzione di ricerca

Start with ManagementSystem and ManagementLogger, then trace CACHED_TYPE_EVICTION handling for ordinary commits and schema-cache expiration in open transactions. Verify the reserved eviction id 0, sender and receiver behavior, rolling-version acknowledgement handling, and failure logging. Done means other instances stop serving stale definition edges without long-running transactions being force-closed.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

  • Version: master (5c1b77ef8)
  • Storage Backend: any shared storage (BerkeleyJE, Cassandra, HBase, ...)
  • Mixed Index Backend: n/a
  • Expected Behavior: when an ordinary transaction on one JanusGraph instance commits definition edges, for example a connection or property constraint auto-created under schema.constraints=true or added with tx.addConnection(...) / tx.addProperties(...), the other instances stop serving the definitions they had cached.
  • Current Behavior: since #4953, such a commit expires the committing instance's own schema cache, and #4977 extends that to its open transactions. Nothing reaches the other instances, though. They keep the definition edges they cached (empty definition-edge lists are cached in both modes since #4953), and the first time one of them adds the same kind of edge, it creates another copy of the constraint.
Steps to Reproduce
  1. Open two instances on the same storage with schema.constraints=true and the default schema maker; create vertex label person and edge label knows through the management system.
  2. On instance B, read person's connections in a transaction (none yet; B caches the empty list).
  3. On instance A, add a person -knows-> person edge in an ordinary transaction and commit it (the connection is auto-created).
  4. Instance B still sees no connection, and adding a person -knows-> person edge there creates a second copy.
Design

ManagementSystem tells the other instances through a CACHED_TYPE_EVICTION message on the management log, but ManagementLogger.sendCacheEviction waits for every open instance to acknowledge it. An instance acknowledges only once all the transactions it had open have closed. With graph.management-auto-close-stale-instances, an instance that hasn't acknowledged within graph.management-ack-timeout (120 s) is force-closed. That is fine for deliberate management operations, but an ordinary write must not be able to get an instance with a long-running transaction force-closed.

So ordinary commits send the same message without registering an eviction trigger, under a reserved eviction id 0. The trigger counter hands out ids from 1, so no acknowledged eviction ever uses it.

  • A receiver expires the elements from its schema cache and its open transactions exactly as for a management eviction, but sends no acknowledgement for id 0.
  • Every instance which reads the message, the sender included, expires the elements from its schema cache and its open transactions; the sender re-reads what it expired when it sent the message.
  • Instances of earlier versions read the message format unchanged. They expire the elements and acknowledge id 0, and newer senders ignore that acknowledgement instead of logging "Could not find eviction trigger". A rolling upgrade therefore needs no preparation.
  • Failing to send the message is logged and doesn't fail the commit, which has already persisted everything.
Lingua principale
Java
Stelle
5.8k
Fork
1.2k
Merge medio
20h 36m
PR unite (30g)
25

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di JanusGraph/janusgraph

Tutte le issue di JanusGraph/janusgraph

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.