Faceting Performance Factors
Our current search is faceting on a single integer field. The field is multi-valued. facet=true facet.mincount=1 facet.limit=-1 facet.field=fieldA The number of unique values in our index for fieldA is around 8000, and a typical query can return about 500 counts. A typical single document can have anywhere from 5 to 20 values for fieldA. The performance we are getting for this implementation is pretty acceptable (under 2 seconds). Now, we are trying to add in a 2nd facet, also an integer and also multi-valued. facet=true facet.mincount=1 facet.limit=-1 facet.field=fieldA facet.field=fieldB The number of unique values in our index for fieldB is around 100k, but a typical query still only returns about 400 counts. However, a single document will only have 5 or 6 values for fieldB. The performance of our queries dropped significantly (about 15-20 seconds per query!). I'm unable to figure out why there is such a significant drop in performance here. Is it the fact that there are more than 10x more possible unique values for fieldB? Hopefully I have provided enough info above, but do any of these strike you as a big contributing factor to the drop in performance? We are currently using Solr 1.3 and upgrading to 1.4 will not be an option until it is finalized. Thanks for the help. -- View this message in context: http://www.nabble.com/Faceting-Performance-Factors-tp25033622p25033622.html Sent from the Solr - User mailing list archive at Nabble.com.
Plugin Performance Issues
We recently created a custom class for our spellchecking implementation in Solr. We decided to include the class in a custom jar and deployed it to the /lib directory in solr_home to use it as a plugin. After a while (about 12 hours), the heap usage for Solr slowly starts to rise, and we eventually run into swap issues which ends up killing our performance. We've tried several different things to try to solve the problem, originally thinking it was our code, but on one of our servers, the new code in the plugin wasn't even being used. Has anyone else experienced? I'm wondering if this is perhaps a side-effect of using plugins in general, perhaps something going on with the custom class loading of Solr. We're using Tomcat 6 and Solr 1.3 by the way. -- View this message in context: http://www.nabble.com/Plugin-Performance-Issues-tp24295010p24295010.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Plugin Performance Issues
Our max heap was configured to use 5GB. It has been running fine until we tried to deploy a new queryConverter for our SpellcheckComponent. After which, we upped our heap to 8GB and still had issues. Solr is the only webapp running on Tomcat. We are using sorting and faceting, but again, hadn't had problems until deploying this plugin. Also, seeing as how it's only spellchecking related (and we have a separate RequestHandler that only handles spellchecking, while leaving the SpellcheckComponent out of our standard RequestHandler), I'm not entirely convinced that it's related to our code, but it could be. Just trying to get a sense if other plugins have had similar problems, just by the nature of using Solr's resource loading from the /lib directory. Otis Gospodnetic wrote: Hi, Could it simply be the case that you really do need all that memory that the JVM start consuming with time? How large of a heap are you using, is Solr the only webapp in your TOmcat, and are you using sorting or faceting? Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: CameronL cameron.develo...@gmail.com To: solr-user@lucene.apache.org Sent: Wednesday, July 1, 2009 2:37:40 PM Subject: Plugin Performance Issues We recently created a custom class for our spellchecking implementation in Solr. We decided to include the class in a custom jar and deployed it to the /lib directory in solr_home to use it as a plugin. After a while (about 12 hours), the heap usage for Solr slowly starts to rise, and we eventually run into swap issues which ends up killing our performance. We've tried several different things to try to solve the problem, originally thinking it was our code, but on one of our servers, the new code in the plugin wasn't even being used. Has anyone else experienced? I'm wondering if this is perhaps a side-effect of using plugins in general, perhaps something going on with the custom class loading of Solr. We're using Tomcat 6 and Solr 1.3 by the way. -- View this message in context: http://www.nabble.com/Plugin-Performance-Issues-tp24295010p24295010.html Sent from the Solr - User mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Plugin-Performance-Issues-tp24295010p24296828.html Sent from the Solr - User mailing list archive at Nabble.com.
LRUCache causing locked threads
I've searched through the forums and seen a few similar problems to this, but nothing that seemed to help much. We're running Solr 1.3 on Tomcat 6.0.16 and Java 6. We've been having performance problems with our search, causing long query times under normal traffic. We've taken a thread dump and have seen many threads locked or waiting for LRUCache (see below). Our cache values are as follows: filterCache class=solr.LRUCache size=2 initialSize=1 autowarmCount=1/ queryResultCache class=solr.LRUCache size=2 initialSize=1 autowarmCount=5000/ documentCache class=solr.LRUCache size=25000 initialSize=1 autowarmCount=0/ http-8983-99 daemon prio=10 tid=0x002beb3f5800 nid=0x2fb9 waiting for monitor entry [0x47ea5000..0x47ea6c30] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.solr.search.LRUCache.get(LRUCache.java:130) - waiting to lock 0x002a9fb94be8 (a org.apache.solr.search.LRUCache$1) at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:605) at org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:1556) at org.apache.solr.request.SimpleFacets.getFacetTermEnumCounts(SimpleFacets.java:377) at org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:156) at org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:182) at org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:96) at org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:70) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:169) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1204) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232) http-8983-83 daemon prio=10 tid=0x002bead1a000 nid=0x2f76 waiting for monitor entry [0x46e95000..0x46e96c30] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.solr.search.LRUCache.get(LRUCache.java:130) - locked 0x002a9fb94be8 (a org.apache.solr.search.LRUCache$1) at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:605) at org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:1556) at org.apache.solr.request.SimpleFacets.getFacetTermEnumCounts(SimpleFacets.java:377) at org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:156) at org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:182) at org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:96) at org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:70) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:169) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1204) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232) Has anyone else experienced this or does anyone have an idea of why this might be happening? -- View this message in context: http://www.nabble.com/LRUCache-causing-locked-threads-tp24040421p24040421.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: LRUCache causing locked threads
Unfortunately upgrading to 1.4 isn't an option for us at the moment. Since we're stuck using 1.3, is there anything in particular we need to do to prevent these threads from locking (through configuration or something) or is this sort of expected/unavoidable using 1.3? Yonik Seeley-2 wrote: Solr 1.4 has a cache implementation that's lockless for gets, and faster for gets. There's a new faceting implementation as well. -Yonik http://www.lucidimagination.com On Mon, Jun 15, 2009 at 2:39 PM, CameronLcameron.develo...@gmail.com wrote: I've searched through the forums and seen a few similar problems to this, but nothing that seemed to help much. We're running Solr 1.3 on Tomcat 6.0.16 and Java 6. We've been having performance problems with our search, causing long query times under normal traffic. We've taken a thread dump and have seen many threads locked or waiting for LRUCache (see below). Our cache values are as follows: filterCache class=solr.LRUCache size=2 initialSize=1 autowarmCount=1/ queryResultCache class=solr.LRUCache size=2 initialSize=1 autowarmCount=5000/ documentCache class=solr.LRUCache size=25000 initialSize=1 autowarmCount=0/ http-8983-99 daemon prio=10 tid=0x002beb3f5800 nid=0x2fb9 waiting for monitor entry [0x47ea5000..0x47ea6c30] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.solr.search.LRUCache.get(LRUCache.java:130) - waiting to lock 0x002a9fb94be8 (a org.apache.solr.search.LRUCache$1) at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:605) at org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:1556) at org.apache.solr.request.SimpleFacets.getFacetTermEnumCounts(SimpleFacets.java:377) at org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:156) at org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:182) at org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:96) at org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:70) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:169) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1204) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232) http-8983-83 daemon prio=10 tid=0x002bead1a000 nid=0x2f76 waiting for monitor entry [0x46e95000..0x46e96c30] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.solr.search.LRUCache.get(LRUCache.java:130) - locked 0x002a9fb94be8 (a org.apache.solr.search.LRUCache$1) at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:605) at org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:1556) at org.apache.solr.request.SimpleFacets.getFacetTermEnumCounts(SimpleFacets.java:377) at org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:156) at org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:182) at org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:96) at org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:70) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:169) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1204) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232) Has anyone else experienced this or does anyone have an idea of why this might be happening? -- View this message in context: http://www.nabble.com/LRUCache-causing-locked-threads-tp24040421p24040421.html Sent from the Solr - User mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/LRUCache-causing-locked-threads-tp24040421p24040772.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Boost Query effect with Standard Request Handler
Ahh shoot! Ok, I copied the original thread at the bottom for context. Basically what I need is the bq functionality with the StandardRequestHandler. I can't use dismax because that requires using qf and doesn't offer as much flexibility as we need. I have used Erik's technique of appending an additional clause to the end of all of my queries, but this doesn't work when a document is missing the field that I'm boosting on. This is also an AND query, not OR: name:something AND (searchTier:1^100 OR searchTier:2^50 ...OR searchTier:0^1) In the above example, I'd like to be able to leave the searchTier:0 off and not have to index any documents that have no searchTier with value=0. The bq does this correctly, putting any documents that match the criteria but without a searchTier at the bottom. The reason I brought the question back up is that hossman said: as of SOlr 1.3 -- the SearchHandler (which superclasses and replaces the old StandardRequestHandler and the DisMaxRequestHandler) supports the bq param direclty ... so you can just add a bq param to your request and it will do what you want. I tried it and it didn't work, so I was curious if I was still doing something wrong. Erik Hatcher wrote: bq only works with dismax (defType=dismax). To get the same effect with the lucene/solr query parser, append a clause to the original query (OR'ing it in). Erik On Nov 11, 2008, at 11:52 PM, Otis Gospodnetic wrote: Hi, It's hard to tell what you are replying to since you removed the original email (sounds like somebody suggested using bq). I think it might help if you send the actual URL you are using. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch From: CameronL [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Tuesday, November 11, 2008 9:12:28 PM Subject: Re: Boost Query effect with Standard Request Handler So the bq parameter works with the standard request handler (I don't have to specify defType=dismax)?? I've been running a few tests and it doesn't seem to be picking up the bq. I've boosted one of the values very high (like 1000) compared to the other fields and it doesn't seem to be affecting anything. We're using Solr 1.3. Is there something else I may be missing (some sort of config)? -- View this message in context: http://www.nabble.com/Boost-Query-effect-with-Standard-Request-Handler-tp20042301p20452647.html Sent from the Solr - User mailing list archive at Nabble.com. hossman wrote: : I'm trying to create the boost query (bq parameter) effect with the standard : request handler. Unfortunately, going to the dismax handler isn't really an : option for me, so I'm trying to create a similar effect. as of SOlr 1.3 -- the SearchHandler (which superclasses and replaces the old StandardRequestHandler and the DisMaxRequestHandler) supports the bq param direclty ... so you can just add a bq param to your request and it will do what you want. If you have to stick with 1.2 for some reason... : I have an integer field, 'searchTier', that sort of needs to be factored : into every query. Something like: : : q=name:something AND (searchTier:1^100 OR searchTier:2^50 OR : searchTier:3^25) : : However, if a document has no tier, it should still turn up in the results, : just at the bottom. Currently it does not. I had been playing around with : this a couple months ago, and it worked as desired back then. But after the : 1.3 release, the functionality seems to have changed. in all versions of Solr that query would have required that searchTier contain one of the values in the set (1,2,3) ... if you thought it was working before, trust me: something else was happening. what you wante would have been something like... +name:something (searchTier:1^100 searchTier:2^50 searchTier:3^25) ...note the + indicating that the name:something clause is required, and no modifier in from the the parems indicating thta everything in there is optional. : I've tried several different ways to get around this: : q=name:something AND (searchTier:1^100 OR searchTier:2^50 OR searchTier:3^25 : OR searchTier:[* TO *]) if you *must* use the AND/OR keywords, the only way to do something like this would be... name:something AND (*:* OR searchTier:1^100 OR searchTier:2^50 ...) -Hoss -- View this message in context: http://www.nabble.com/Boost-Query-effect-with-Standard-Request-Handler-tp20042301p20464737.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Boost Query effect with Standard Request Handler
So the bq parameter works with the standard request handler (I don't have to specify defType=dismax)?? I've been running a few tests and it doesn't seem to be picking up the bq. I've boosted one of the values very high (like 1000) compared to the other fields and it doesn't seem to be affecting anything. We're using Solr 1.3. Is there something else I may be missing (some sort of config)? -- View this message in context: http://www.nabble.com/Boost-Query-effect-with-Standard-Request-Handler-tp20042301p20452647.html Sent from the Solr - User mailing list archive at Nabble.com.
Boost Query effect with Standard Request Handler
I'm trying to create the boost query (bq parameter) effect with the standard request handler. Unfortunately, going to the dismax handler isn't really an option for me, so I'm trying to create a similar effect. I have an integer field, 'searchTier', that sort of needs to be factored into every query. Something like: q=name:something AND (searchTier:1^100 OR searchTier:2^50 OR searchTier:3^25) However, if a document has no tier, it should still turn up in the results, just at the bottom. Currently it does not. I had been playing around with this a couple months ago, and it worked as desired back then. But after the 1.3 release, the functionality seems to have changed. I've tried several different ways to get around this: q=name:something AND (searchTier:1^100 OR searchTier:2^50 OR searchTier:3^25 OR searchTier:[* TO *]) q=name:something AND (searchTier:1^100 OR searchTier:2^50 OR searchTier:3^25 OR -searchTier:[* TO *]) but the first method left out results where searchTier is not set, and the second method returns no results. Does it seem like I'm trying to do something that Solr isn't meant to do? I could have sworn it worked before... -- View this message in context: http://www.nabble.com/Boost-Query-effect-with-Standard-Request-Handler-tp20042301p20042301.html Sent from the Solr - User mailing list archive at Nabble.com.
Distributed Search Strategy / Shards
What is the current strategy for doing distributed search for Solr? We currently have our index divided over 3 servers: solr1 solr2 solr3 In order to balance the load, our application calls each with a 'shards' parameter to get the data: solr1:8080/select?shards=solr1,solr2,solr3... solr2:8080/select?shards=solr1,solr2,solr3... solr3:8080/select?shards=solr1,solr2,solr3... However, with this configuration we seem to be running into problems (currently running latest build of solr 1.3) with the servers locking up. It looks like there is some sort of race condition that is causing threads to lock when hitting the search pretty hard. In this configuration, each solr server is responsible for receiving requests, using the shards to send out additional requests (while also potentially receiving shards requests from the other two servers), and merging the results before sending back the response. Is this the intended design for distributed search for solr? -- View this message in context: http://www.nabble.com/Distributed-Search-Strategy---Shards-tp18882112p18882112.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Distributed Search Strategy / Shards
Yonik Seeley wrote: On Thu, Aug 7, 2008 at 7:32 PM, CameronL [EMAIL PROTECTED] wrote: What is the current strategy for doing distributed search for Solr? We currently have our index divided over 3 servers: solr1 solr2 solr3 In order to balance the load, our application calls each with a 'shards' parameter to get the data: solr1:8080/select?shards=solr1,solr2,solr3... solr2:8080/select?shards=solr1,solr2,solr3... solr3:8080/select?shards=solr1,solr2,solr3... However, with this configuration we seem to be running into problems (currently running latest build of solr 1.3) with the servers locking up. It looks like there is some sort of race condition that is causing threads to lock when hitting the search pretty hard. In this configuration, each solr server is responsible for receiving requests, using the shards to send out additional requests (while also potentially receiving shards requests from the other two servers), and merging the results before sending back the response. Is this the intended design for distributed search for solr? It is. You should be able to send top-level requests to any shard and have it send sub-requests to all of the other shards. Does this lockup only happen under load? -Yonik The lockup happens under a moderately heavy load. We are running stress tests to make sure our configuration will be able to handle the amount of traffic we expect. Our other idea was to have one dedicated server to handle the incoming requests, distributing those to the shards, and merging the results, but I see by this post: http://www.nabble.com/Distributed-Search-Caching-td16851547.html#a16884618 That it doesn't seem to be the intended design. Does this seem like an issue that might need to be escalated to jira? We might be able to provide you some additional info relating to these threads locking if you need it. -- View this message in context: http://www.nabble.com/Distributed-Search-Strategy---Shards-tp18882112p18883004.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Dynamic Boosting
Thanks Erik. That's a great idea, and it seems like this is exactly what the bq parameter was made for. Now the problem I seem to be having is that Solr seems to be ignoring the bq parameter altogether. My query looks something like: ...select?q=name:somethingbq=Tier:1^100 Tier:2^75 Tier:3^50 Essentially, this should order the results, but it doesn't. It's returning the exact same results as if the bq param was never there. However, if I format my search like: ...select?q=name:something Tier:1^100 OR Tier:2^75 OR Tier:3^50 then I get the result I want. However, I want to utilize the bq param instead so I don't have to append this to all of my queries. Anyone have any ideas why my bq parameter doesn't seem to be working? Erik Hatcher wrote: How about tinkering with the boosting query (bq) parameter or the boosting function (bf) parameter? I believe clever bq'ing would probably do the trick, huh? Erik On Jul 31, 2008, at 7:34 PM, CameronL wrote: My problem is a little complex, so please bear with me. I currently have a set of documents that need to be tiered, and depending on what tier they are in, a configurable boost should be applied, essentially affecting the score and ordering of the search results. My first idea was to create 10 different fields in my schema for these tiers: field name=Tier1 type=boolean index=true stored=false/ field name=Tier2 type=boolean index=true stored=false/ ... field name=Tier10 type=boolean index=true stored=false/ Each document may be part of 0 or 1 tiers. Then, when a search is requested, I would use the dismax handler to add different boosts to the tier fields: Tier1^1.1 Tier2^1.2 Tier3^1.3... The desired effect is to give a little bit of boost to items that are in Tier 10 over items that are in, say, Tier 5 or in no tier. That is, for items that also match the search term criteria (my default search field is name). As you can see, the flaw in my little plan above is that there isn't really a good way to factor in the Tier fields into the search. I could probably try to add additional criteria ( AND Tier1:true OR Tier2:true...) but it still wouldn't work to include the documents that match the search term but have no tier. Is there another technique I should be using to achieve my desired effect? I'm a little stuck; your help would be much appreciated. Hope I am making sense. -- View this message in context: http://www.nabble.com/Dynamic-Boosting-tp18765678p18765678.html Sent from the Solr - User mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Dynamic-Boosting-tp18765678p18783406.html Sent from the Solr - User mailing list archive at Nabble.com.
Multicore DataDir
The dataDir parameter specified in the core... element in multicore.xml does not seem to point to the correct directory. I commented out the dataDir element from solrconfig.xml in all of my cores. I could explicitly set the dataDir for each core in all of the solrconfig.xml files, but I would rather only have to deal with a single solrconfig.xml and not have to configure its contents individually for each of my cores. Plus, it's pretty convenient to only have to look at 1 file (multicore.xml) to configure the dataDirs Is this the expected behavior? Is there another place I should be setting it? -- View this message in context: http://www.nabble.com/Multicore-DataDir-tp18784286p18784286.html Sent from the Solr - User mailing list archive at Nabble.com.
Dynamic Boosting
My problem is a little complex, so please bear with me. I currently have a set of documents that need to be tiered, and depending on what tier they are in, a configurable boost should be applied, essentially affecting the score and ordering of the search results. My first idea was to create 10 different fields in my schema for these tiers: field name=Tier1 type=boolean index=true stored=false/ field name=Tier2 type=boolean index=true stored=false/ ... field name=Tier10 type=boolean index=true stored=false/ Each document may be part of 0 or 1 tiers. Then, when a search is requested, I would use the dismax handler to add different boosts to the tier fields: Tier1^1.1 Tier2^1.2 Tier3^1.3... The desired effect is to give a little bit of boost to items that are in Tier 10 over items that are in, say, Tier 5 or in no tier. That is, for items that also match the search term criteria (my default search field is name). As you can see, the flaw in my little plan above is that there isn't really a good way to factor in the Tier fields into the search. I could probably try to add additional criteria ( AND Tier1:true OR Tier2:true...) but it still wouldn't work to include the documents that match the search term but have no tier. Is there another technique I should be using to achieve my desired effect? I'm a little stuck; your help would be much appreciated. Hope I am making sense. -- View this message in context: http://www.nabble.com/Dynamic-Boosting-tp18765678p18765678.html Sent from the Solr - User mailing list archive at Nabble.com.
