You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Otis Gospodnetic <ot...@gmail.com> on 2014/03/12 03:07:39 UTC

Disabling lookups into disabled caches?

Hi,

Is there a way to disable cache *lookups* into cached that are disabled?

Check this for example: https://apps.sematext.com/spm-reports/s/Z04bfIvGyH

This is a Document cache that was enabled, and then got disabled.  But the
lookups are still happening, which is pointless if the cache is disabled.

If that's not doable, I will JIRA?

Thanks,
Otis
--
Performance Monitoring * Log Analytics * Search Analytics
Solr & Elasticsearch Support * http://sematext.com/

Re: Disabling lookups into disabled caches?

Posted by Otis Gospodnetic <ot...@gmail.com>.
Hi Shawn,

Here it is: https://issues.apache.org/jira/browse/SOLR-5851

Otis
--
Performance Monitoring * Log Analytics * Search Analytics
Solr & Elasticsearch Support * http://sematext.com/


On Tue, Mar 11, 2014 at 11:22 PM, Shawn Heisey <so...@elyograg.org> wrote:

> On 3/11/2014 8:51 PM, Shawn Heisey wrote:
> > On 3/11/2014 8:07 PM, Otis Gospodnetic wrote:
> >> Is there a way to disable cache *lookups* into cached that are disabled?
> >>
> >> Check this for example:
> https://apps.sematext.com/spm-reports/s/Z04bfIvGyH
> >>
> >> This is a Document cache that was enabled, and then got disabled.  But
> the
> >> lookups are still happening, which is pointless if the cache is
> disabled.
> >>
> >> If that's not doable, I will JIRA?
> >
> > I think this needs an issue.  I've worked up a *possible* patch for the
> > problem.  One that still needs testing and review.  Which reminds me, I
> > should probably invent new test methods for this.
> >
> > The lookups should have very little overhead, but any avoidable overhead
> > *should* be avoided.
>
> The quickfix that I started with on FastLRUCache didn't work and made
> most of the tests fail.  It turns out that FastLRUCache bumps the max
> cache size to 2 when you set it to zero.  I haven't looked deeper into
> the other cache types yet.
>
> Once you create the issue, we can move this discussion there.
>
> Thanks,
> Shawn
>
>

Re: Disabling lookups into disabled caches?

Posted by Shawn Heisey <so...@elyograg.org>.
On 3/11/2014 8:51 PM, Shawn Heisey wrote:
> On 3/11/2014 8:07 PM, Otis Gospodnetic wrote:
>> Is there a way to disable cache *lookups* into cached that are disabled?
>>
>> Check this for example: https://apps.sematext.com/spm-reports/s/Z04bfIvGyH
>>
>> This is a Document cache that was enabled, and then got disabled.  But the
>> lookups are still happening, which is pointless if the cache is disabled.
>>
>> If that's not doable, I will JIRA?
> 
> I think this needs an issue.  I've worked up a *possible* patch for the
> problem.  One that still needs testing and review.  Which reminds me, I
> should probably invent new test methods for this.
> 
> The lookups should have very little overhead, but any avoidable overhead
> *should* be avoided.

The quickfix that I started with on FastLRUCache didn't work and made
most of the tests fail.  It turns out that FastLRUCache bumps the max
cache size to 2 when you set it to zero.  I haven't looked deeper into
the other cache types yet.

Once you create the issue, we can move this discussion there.

Thanks,
Shawn


Re: Disabling lookups into disabled caches?

Posted by Shawn Heisey <so...@elyograg.org>.
On 3/11/2014 8:07 PM, Otis Gospodnetic wrote:
> Is there a way to disable cache *lookups* into cached that are disabled?
> 
> Check this for example: https://apps.sematext.com/spm-reports/s/Z04bfIvGyH
> 
> This is a Document cache that was enabled, and then got disabled.  But the
> lookups are still happening, which is pointless if the cache is disabled.
> 
> If that's not doable, I will JIRA?

I think this needs an issue.  I've worked up a *possible* patch for the
problem.  One that still needs testing and review.  Which reminds me, I
should probably invent new test methods for this.

The lookups should have very little overhead, but any avoidable overhead
*should* be avoided.

Thanks,
Shawn