I ran into another issue that I am having issue running to ground. My
implementation on Solr 4.x worked as I expected but trying to migrate this
to Solr 5.x it looks like some of the faceting is delegated to
DocValuesFacets which ultimately caches things at a field level in the
FieldCache.DEFAULT
This was my original thought. We already have the thread local so should
be straight fwd to just wrap the Field name and use that as the key. Again
thanks, I really appreciate the feedback
On Aug 19, 2015 8:12 AM, "Yonik Seeley" wrote:
> On Tue, Aug 18, 2015 at 10:58 PM, Jamie Johnson wrote:
>
On Tue, Aug 18, 2015 at 10:58 PM, Jamie Johnson wrote:
> Hmm...so I think I have things setup correctly, I have a custom
> QParserPlugin building a custom query that wraps the query built from the
> base parser and stores the user who is executing the query. I've added the
> username to the hashC
Hmm...so I think I have things setup correctly, I have a custom
QParserPlugin building a custom query that wraps the query built from the
base parser and stores the user who is executing the query. I've added the
username to the hashCode and equals checks so I think everything is setup
properly.
On Tue, Aug 18, 2015 at 9:51 PM, Jamie Johnson wrote:
> Thanks, I'll try to delve into this. We are currently using the parent
> query parser, within we could use {!secure} I think. Ultimately I would
> want the solr qparser to actually do the work of parsing and I'd just wrap
> that.
Right...
Thanks, I'll try to delve into this. We are currently using the parent
query parser, within we could use {!secure} I think. Ultimately I would
want the solr qparser to actually do the work of parsing and I'd just wrap
that. Are there any examples that I could look at for this? It's not
clear to
On Tue, Aug 18, 2015 at 8:38 PM, Jamie Johnson wrote:
> I really like this idea in concept. My query would literally be just a
> wrapper at that point, what would be the appropriate place to do this?
It depends on how much you are trying to make everything transparent
(that there is security) or
I really like this idea in concept. My query would literally be just a
wrapper at that point, what would be the appropriate place to do this?
What would I need to do to the query to make it behave with the cache.
Again thanks for the idea, I think this could be a simple way to use the
caches.
On
On Tue, Aug 18, 2015 at 8:19 PM, Jamie Johnson wrote:
> when you say a security filter, are you asking if I can express my security
> constraint as a query? If that is the case then the answer is no. At this
> point I have a requirement to secure Terms (a nightmare I know).
Heh - ok, I figured
when you say a security filter, are you asking if I can express my security
constraint as a query? If that is the case then the answer is no. At this
point I have a requirement to secure Terms (a nightmare I know). Our
fallback is to aggregate the authorizations to a document level and secure
th
On Tue, Aug 18, 2015 at 7:11 PM, Jamie Johnson wrote:
> Yes, my use case is security. Basically I am executing queries with
> certain auths and when they are executed multiple times with differing
> auths I'm getting cached results.
If it's just simple stuff like top N docs returned, can't you j
Yes, my use case is security. Basically I am executing queries with
certain auths and when they are executed multiple times with differing
auths I'm getting cached results. One option is to have another
implementation that has a number of caches based on the auths, something
that I suspect we wil
You can comment out (some) of the caches.
There are some caches like field caches that are more at the lucene
level and can't be disabled.
Can I ask what you are trying to prevent from being cached and why?
Different caches are for different things, so it would seem to be an
odd usecase to disabl
Thanks and good call, that has been there for quite some time!
I've changed it to: -Xms200m -Xmx1500m
I'll look into the effect of this first.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Disable-caching-on-sorting-to-improve-performance-tp4108356p4108362.html
Sent from
Hi,
Sorting uses Lucene FieldCache which you cannot disable. If you have lots of
documents and sort on three fields, you must increase the heap space. Also,
note that you have defined Xmx twice here, i don't know what effect that will
have.
Cheers
-Original message-
> From:PeterKer
: If you are not searching against your master, and you shouldn't (and
: it sounds like you aren't), then you don't have to worry about
: disabling caches - they will just remain empty. You could comment
: them out, but I think that won't actually disable them.
FWIW: what i generall advocate is
Thanks for the replies.
2012/10/17 Otis Gospodnetic
> Hi,
>
> If you are not searching against your master, and you shouldn't (and
> it sounds like you aren't), then you don't have to worry about
> disabling caches - they will just remain empty. You could comment
> them out, but I think that
Hi,
If you are not searching against your master, and you shouldn't (and
it sounds like you aren't), then you don't have to worry about
disabling caches - they will just remain empty. You could comment
them out, but I think that won't actually disable them.
Warmup queries you can just comment ou
Yes Anderson, you don't need cache for master, neither warming.
-Original Message-
From: Anderson vasconcelos [mailto:anderson.v...@gmail.com]
Sent: Wednesday, October 17, 2012 9:55 PM
To: solr-user
Subject: Disable Caching
Hi
I have a server that just index data and sincronize this dat
19 matches
Mail list logo
