our timeouts are configurable, we'll have to experiment. It defaults to
500ms, so each by segment query won't see more than 500ms overhead in case
of cache issues.


On Fri, Apr 4, 2014 at 11:55 AM, nishantmonu51 <notifications@github.com>wrote:

> In server/src/main/java/io/druid/client/CachingQueryRunner.java:
>
> > +                                  && strategy != null
> > +                                  && cacheConfig.isPopulateCache();
> > +
> > +    final boolean useCache = Boolean.parseBoolean(query.getContextValue(CacheConfig.USE_CACHE, "true"))
> > +        && strategy != null
> > +        && cacheConfig.isPopulateCache();
> > +
> > +    final Cache.NamedKey key = CacheUtil.computeSegmentCacheKey(
> > +        segmentIdentifier,
> > +        segmentDescriptor,
> > +        strategy.computeCacheKey(query)
> > +    );
> > +
> > +    if(useCache) {
> > +      final Function cacheFn = strategy.pullFromCache();
> > +      final byte[] cachedResult = cache.get(key);
>
> yap, i think u r right, memcache internally does bulk gets, not sure on
> how it would behave in case of cache timeouts, can there be any worst case
> when those timeouts add on linearly.
>
> --
> Reply to this email directly or view it on GitHub<https://github.com/metamx/druid/pull/458/files#r11308567>
> .
>