yuqi1129 opened a new issue, #12418:
URL: https://github.com/apache/gravitino/issues/12418

   ### Describe the subtask
   
   Cross-node cache invalidation has no test that runs two actual Gravitino 
servers. The only cross-node coverage today is 
`TestEntityCacheCrossNodeInvalidation`, a unit test that simulates two 
`EntityCache` instances inside one JVM. Everything that is specific to *being* 
multi-node is therefore unverified:
   
   - two server processes contending on the same `entity_change_log` table
   - `EntityChangeLogPoller` and `EntityChangeLogCleaner` interacting across 
processes
   - cursor behaviour across DB connection loss or restart of one node
   - end-to-end staleness actually landing within the promised one poll interval
   
   This is the last blocking gap before `gravitino.cache.enabled=true` can be 
recommended for a multi-node deployment: the mechanism is complete, but it has 
never run in the shape it is meant to run in.
   
   **Constraint worth knowing up front:** `GravitinoEnv` is a process-wide 
singleton (`GravitinoEnv.java:194`), and `MiniGravitino` already acknowledges 
this — it waits for one embedded server to terminate before the next starts. So 
two nodes **cannot** be two `MiniGravitino` instances in one JVM. The test 
needs either two real server processes (`BaseIT` deploy mode, via 
`GravitinoITUtils.startGravitinoServer()`) or two separate JVMs, both pointed 
at one shared JDBC backend. Deciding this is the first step of the task.
   
   Scenarios to cover:
   
   - node A alters/drops a table, schema, catalog, metalake, fileset, tag, 
policy, job → node B serves fresh data within one poll interval
   - cascade drop of a schema → node B drops descendants, including nested 
`HierarchicalSchema` levels (see #12416)
   - rename → node B invalidates under the pre-mutation name
   - catalog alter → node B rebuilds the catalog instance 
(`CatalogChangeLogListener`)
   - authorization: owner/role change on node A is reflected on node B 
(`JcasbinChangeListener`)
   - node B restarts → cursor resumes at the current max id and does not replay 
history
   
   ### Parent issue
   
   https://github.com/apache/gravitino/issues/11737
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to