package yadcc.cache

Get desktop application:
View/edit binary Protocol Buffers messages

• rpc FetchBloomFilter (FetchBloomFilterRequest, FetchBloomFilterResponse)

  cache.proto:108

  To speed up compilation cache lookup, the daemon should periodically call this method to load the Bloom Filter for detecting cache entry existance. Although technically feasible, always unconditionally looking up the cache before compilation can actually *hurt* performance. The reason is simple: so long as the build toolchain does work correctly, re-compilation of untouched file should be rare (ignoring users who clean up their workspace frequently). Therefore, unless the same file is compiled by others beforehand, cache is likely to *miss*. Because looking up cache (in Redis) incurs network delay, overall perf. can decrease. OTOH, consider that a large repository is shared by multiple users (given its real human or continuous integration scripts). In this case it's likely the same file is compiled multiple times by different user: e.g., someone compiled it locally, pushed into to Git, and subsequently fetched by a bunch of users who later compile it. In this regard, caching *should* speed things up to a certain degree. To take the best of both world, the scheduler maintain a Bloom Filter for detecting definite cache miss, and suggest the daemon to lookup the cache if it will likely to hit. Note that, to save bandwidth, this method may returns an incremental list of keys instead of a full bloom filter.

  message FetchBloomFilterRequest

  cache.proto:27

  • string token = 3

    Token of the requestor. The cache server only accepts request from clients that present a recognized token.

  • uint32 seconds_since_last_full_fetch = 1

    Seconds elapsed since last fetch of entire bloom filter.

  • uint32 seconds_since_last_fetch = 2

    Seconds elapsed since last bloom filter fetcher, either full or incremental.

  message FetchBloomFilterResponse

  cache.proto:40

  • bool incremental = 1

    If set, a list of new keys are provided, otherwise, the entire bloom filter is returned via attachment.

  • repeated string newly_populated_keys = 2

    Keys of newly populated cache entries.

  • uint32 num_hashes = 3

    Number of hash values generated for each key.

• rpc TryGetEntry (TryGetEntryRequest, TryGetEntryResponse)

  cache.proto:117

  Try read a cache entry with the specified cache key. Not sure if a batch interface would be beneficial here. If we choose to batch requests / responses, we can return a big attachment and pass offset of each cache entry in attachment via response message. This saves us from having Protocol Buffers to serialize a (really big) byte stream.

  message TryGetEntryRequest

  cache.proto:60

  • string token = 2

  • string key = 1

    Key of cache entry.

  message TryGetEntryResponse

  cache.proto:67

  NOTHING. On success, the cached entry is returned via attachment.

  (message has no fields)

• rpc PutEntry (PutEntryRequest, PutEntryResponse)

  cache.proto:123

  Save a cache result. The caller is responsible for compressing the value before saving it to cache.

  message PutEntryRequest

  cache.proto:71

  • string token = 2

  • string key = 1

  message PutEntryResponse

  cache.proto:79

  NOTHING.

  (message has no fields)

• STATUS_UNKNOWN = 0

  Placeholder for flare::rpc::STATUS_SUCCESS.

• STATUS_NOT_FOUND = 1001

  The requested cache entry is not found.

• STATUS_ACCESS_DENIED = 1002

  Invalid token?

• STATUS_INVALID_ARGUMENT = 1003