dcapwell commented on PR #136: URL: https://github.com/apache/cassandra-accord/pull/136#issuecomment-2465373892
we spoke in slack, dumping here access to epoch and epoch state is done with the lock on `accord.impl.AbstractConfigurationService#epochs` the lock you are referring to is `AccordConfigurationService.this`, which is separate and doesn't block epochs. `AccordConfigurationService.this` is used to interact with `AccordConfigurationService#state` `AccordConfigurationService#diskState` and `AccordConfigurationService.EpochState#syncStatus` - this one could use the epoch lock, but the access is 100% with diskState There is some concern that `AccordConfigurationService#start` holds the lock for too long, and I can try to look into this. The main issue I see is that Accord can notify about epoch status, which requires we save to the topologies table... but we are reading from that table to populate what the state *should* be... This callback can happen (logically) from 2 places: bootstrap complete (CommandStore), `DONE` (local thread, which is either `main` or `MiscStage`). This would mean that during startup we need to worry about the `CommandStore` and `MiscStage` threads being blocked (both are single threaded). For `CommandStore` this feels fine as we have not even started journal reply yet, nor are we accepting Accord messages (they are dropped while we are starting up). That leaves `MiscStage` -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
