tokenrove / bertconf Goto Github PK

There's a potential race condition that can occur if we're doing multiple nested reload but the probabilities are low.

The issue is that bertconf:read first reads the current table for a namespace then looks up a key in that table which means that if the table is deleted between these two calls, the second lookup with trigger an error.

This code tries to avoid that by introducing a grace period where old tables are kept around until the next reload which would normally happen on the configure periodic timer. That being said, if one table takes too long to load and we end up executing multiple nested reloads (has been known to happen) then no grace periods are introduced and we may end up deleting the table that is currently being read.

Especially because needs_reload can be sent repeatedly. Both need to be fixed -- reloads should coalesce, and reload_bert should be changed to not call itself and not keep so much data live.