On Dec 8, 2014, at 1:40 PM, Vikas Saurabh <vikas.saur...@gmail.com> wrote:
>> Since the cache initialization was a separate thread I had to take care on >> properly handle this situation and updating properly the bloomfilter. > > Sorry for being a little slow to catch up. But, as far as I understood > the issue -- it is about that we need to load all vanity mappings > during startup to declare that the instance is indeed up. I thought it > implied that until the thread that loads/caches/marks all vanity paths > finishes its task, startup isn't marked as complete (please excuse the > different terms -- I'm not sure of the exact usages in sling) This is the current behavior. In SLING-3290 in order to speed up the startup time the idea was to have he initialization of the cache in a new thread and using the BloomFilter as a fallback for startup. The problem there is that while the cache was initialized and the system was up with the Bloomfilter somebody was allowed to add new vanityPaths. As you might imagine this could be pretty brittle to handle... > >> With this new approach of limiting the vanity Path entries size I think the >> Bloom Filter can come back in the solution :) > > I think even with bloom filter (assuming we don't serialize its state > back on clean shutdowns), we'd have to read 'all' vanity mappings once > during startup. Bloom filter would just use less memory to mark if we > really have mapping in repo (even when there is a miss on cached > vanity entry) > > I think SLING-3290 is about reducing number of MapEntries required to > load up all vanity paths… this was about minimize the start time (back then there wasn’t the though to limit the cache unluckily :() > but, I think SLING-4216 is more to do with > how many of vanity entries would we like to keep in memory -- which I > think can be solved with some cache implementation (probably LRU???) + > bloom filter(to tell if going back to repo would be useful or not) exactly regards antonio > > Thanks, > Vikas
