> 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) > 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... 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) Thanks, Vikas
