> A quick peek at the code (branch_4x, SolrCore.java, starting at line 1647)
> seems to confirm this.
It seems my understanding of that option was wrong! Thanks for correcting me
Shawn.
Greg
On Feb 19, 2014, at 11:19 AM, Shawn Heisey wrote:
> On 2/19/2014 8:59 AM, Greg Walters wrote:
>> I b
On 2/19/2014 8:59 AM, Greg Walters wrote:
I believe that there's a configuration option that'll make on-deck searchers be
used if they're needed even if they're not fully warmed yet. You might try that
option and see if it doesn't solve your 503 errors.
I'm fairly sure that this option (useCo
I believe that there's a configuration option that'll make on-deck searchers be
used if they're needed even if they're not fully warmed yet. You might try that
option and see if it doesn't solve your 503 errors.
Thanks,
Greg
On Feb 18, 2014, at 9:05 PM, Erick Erickson wrote:
> Colin:
>
> Sto
Inline quoting ahead, sorry:
Colin:
Stop. Back up. The automatic soft commits will make updates available to
your users every second. Those documents _include_ anything from your "hard
commit" jobs. What could be faster? Parenthetically I'll add that 1 second
soft commits are rarely an actual r
Colin:
Stop. Back up. The automatic soft commits will make updates available to
your users every second. Those documents _include_ anything from your "hard
commit" jobs. What could be faster? Parenthetically I'll add that 1 second
soft commits are rarely an actual requirement, but that's your deci
On 02/18/2014 10:15 AM, Shawn Heisey wrote:
If you want to be completely in control like that, get rid of the
automatic soft commits and just do the hard commits.
I would personally choose another option for your setup -- get rid of
*all* explicit commits entirely, and just configure autoCommit
On 2/18/2014 10:59 AM, Colin Bartolome wrote:
I'll describe a bit more about our setup, so I can say why I don't
think that'll work for us:
* Our web servers send update requests to Solr via a background
thread, so HTTP requests don't have to wait for the request to complete.
* That background
On 02/17/2014 09:46 PM, Shawn Heisey wrote:
I think I put too much information in my reply. Apologies. Here's the
most important information to deal with first:
Don't send hard commits at all. Configure autoCommit in your server
config, with the all-important openSearcher parameter set to fal
On 2/17/2014 7:06 PM, Colin Bartolome wrote:
> Increasing the maxTime value doesn't actually solve the problem, though;
> it just makes it a little less likely. Really, the soft commits aren't
> the problem here, as far as we can tell. It's that a request that
> triggers a hard commit simply fails
On 02/17/2014 05:38 PM, Shawn Heisey wrote:
On 2/17/2014 6:06 PM, Colin Bartolome wrote:
We're using Solr version 4.2.1, in case new functionality has helped
with this issue.
We have our Solr servers doing automatic soft commits with maxTime=1000.
We also have a scheduled job that triggers a ha
On 2/17/2014 6:06 PM, Colin Bartolome wrote:
> We're using Solr version 4.2.1, in case new functionality has helped
> with this issue.
>
> We have our Solr servers doing automatic soft commits with maxTime=1000.
> We also have a scheduled job that triggers a hard commit every fifteen
> minutes. Wh
We're using Solr version 4.2.1, in case new functionality has helped with
this issue.
We have our Solr servers doing automatic soft commits with maxTime=1000.
We also have a scheduled job that triggers a hard commit every fifteen
minutes. When one of these hard commits happens while a soft com
12 matches
Mail list logo
