Definition edges an ordinary transaction commits don't reach the schema caches of other instances
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- java
- Domain
- backend, databases, distributed-systems
Research direction
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.
Written by the indexing model from the issue text.
Description
- 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=trueor added withtx.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
- Open two instances on the same storage with
schema.constraints=trueand the default schema maker; create vertex labelpersonand edge labelknowsthrough the management system. - On instance B, read
person's connections in a transaction (none yet; B caches the empty list). - On instance A, add a
person -knows-> personedge in an ordinary transaction and commit it (the connection is auto-created). - Instance B still sees no connection, and adding a
person -knows-> personedge 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.
- Dominant language
- Java
- Stars
- 5.8k
- Forks
- 1.2k
- Avg merge
- 20h 36m
- Merged PRs (30d)
- 25
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from JanusGraph/janusgraph
-
Difficulty 1/5 Under an hour Newbie friendliness 95/100
JanusGraph/janusgraph#4943 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 62/100
JanusGraph/janusgraph#1578 ·
Maintainers usually reply within 1 day
-
Transaction recovery takes a transaction whose final status it reads one poll later for a failed oneOpen
Difficulty 4/5 3-5 days Newbie friendliness 45/100
JanusGraph/janusgraph#4986 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
JanusGraph/janusgraph#4954 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
JanusGraph/janusgraph#4934 ·
Maintainers usually reply within 1 day
All issues in JanusGraph/janusgraph
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
oracle/javavscode#652 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
OpenAPITools/openapi-generator#25014 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
AloisSeckar/demos-java#380 ·