| Issue 700: | Notify slaves when a cache entry is stale through a stream | |
| 1 person starred this issue and may be notified of changes. | Back to list |
This is a cut'n'paste from previous discussions in the mailing list in this thread: http://groups.google.com/group/repo-discuss/browse_thread/thread/dfeb290231f5b873# Fredrik Luthander and Shawn Pearce quoted: > So, we need our slaves to be notified that a particular user > now is stale in cache and needs a reread from the db. The idea behind the magic 'Gerrit Code Review' SSH user, and the peer_keys file, was to allow the slaves to connect over SSH to the master, and then start listening for cache flush events. Similar to `gerrit stream-events`, only the slave would be listening for the lower level events that get posted to the master's caches, allowing the slaves to evict individual records just seconds behind the master. I got started... but didn't finish the work. This may not be that much more work to implement. When starting up in slave mode, start a background thread that just connects to the master in a loop. If the connection breaks, it just keeps trying to reconnect until its successful. The thread runs some new `gerrit stream-cache-changes` command or something similar, which allows the slave to learn about changes to the master's caches. On the master side, implement that new stream-cache-changes command similar to how stream-events is done. An async IO queue pushing events out to the connected clients, without needing to tie up a thread per client on the server side. We might then just need to add a listener to the underlying Ehcache objects that allows us to learn about remove() and removeAll() events, and send them out to listening clients. On the surface, it seems pretty simple... :-)
Sep 1, 2010
#1
sop@google.com
Labels:
-Type-Bug Type-Feature
|
|
| ► Sign in to add a comment |