We've got a patch to prevent the exceptions:
https://issues.apache.org/jira/browse/SOLR-9712
-Yonik
On Fri, Dec 9, 2016 at 7:45 PM, Joel Bernstein wrote:
> The question about allowing more the one on-deck searcher is a good one.
> The current behavior with maxWarmingSearcher config is to throw
The question about allowing more the one on-deck searcher is a good one.
The current behavior with maxWarmingSearcher config is to throw an
exception if searchers are being opened too frequently. There is probably a
good reason why it was done this way but I'm not sure the history behind it.
Curre
: > If you are seeing an increase in "Overlapping onDeckSearchers" when using
: > DocExpirationUpdateProcessorFactory, it's becuase you actaully have docs
: > expiring quite frequently relative to the autoDeletePeriodSeconds and
: > the amount of time needed to warm each of the new searchers.
:
Chris Hostetter-3 wrote
> If you are seeing an increase in "Overlapping onDeckSearchers" when using
> DocExpirationUpdateProcessorFactory, it's becuase you actaully have docs
> expiring quite frequently relative to the autoDeletePeriodSeconds and
> the amount of time needed to warm each of the n
: bq: ...is it triggering a commit every 30 seconds, because that's what
: I have the autoDeletePeriodSeconds set to
yes a commit is triggered each time a delete is fired.
: There's a note in the code about making the commits optional, it seems
: fair to raise a JIRA about implementing this. Pat
Okay, I created a JIRA ticket
(https://issues.apache.org/jira/servicedesk/agent/SOLR/issue/SOLR-9841) and
will work on a patch.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Adding-DocExpirationUpdateProcessorFactory-causes-Overlapping-onDeckSearchers-warnings-tp4309155p43
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/update/processor/DocExpirationUpdateProcessorFactory.java#L407
Based on that it looks like this would definitely trigger additional
commits. Specifically with openSearcher being true.
Not sure the best way around
bq: ...is it triggering a commit every 30 seconds, because that's what
I have the autoDeletePeriodSeconds set to
Yep. There's this line from Chris' writeup:
After the deleteByQuery has been executed, a soft commit is also
executed using openSearcher=true so that search results will no longer
I'm using Solr Cloud 6.1.0, and my client application is using SolrJ 6.1.0.
Using this Solr config, I get none of the dreaded "PERFORMANCE WARNING:
Overlapping onDeckSearchers=2" log messages:
https://dl.dropboxusercontent.com/u/49733981/solrconfig-no_warnings.xml
However, I start getting them fr
I’d prefer it if the alias was required to be removed, or pointed elsewhere,
before the collection could be deleted.
As a best practice, I encourage all SolrCloud users to configure an alias to
each collection, and use only the alias in their clients. This allows atomic
switching between colle
Shawn and Joel both answered the question with seemingly opposite answers,
but Joel's should be right. On Deck, as an idiom, means "getting ready to
go next". I think it has it's history in military / naval terminology (a
plane being "on deck" of an aircraft carrier was the next one to take off),
a
> On Dec 9, 2016, at 1:12 PM, Anshum Gupta wrote:
>
> On a similar note, I think we should also be clearing out the aliases when
> we DELETE a collection.
This seems problematic since an alias can point to several collections. Maybe
the point is that the deleted collection should be removed f
Nice.
Here is something similar: https://github.com/sematext/solr-researcher -
hope others find it useful, too.
Otis
--
Monitoring - Log Management - Alerting - Anomaly Detection
Solr & Elasticsearch Consulting Support Training - http://sematext.com/
On Mon, Dec 5, 2016 at 4:18 AM, Andrea Gazza
I think that might have just been an oversight. We shouldn't allow creation
of an alias for non-existent collections.
On a similar note, I think we should also be clearing out the aliases when
we DELETE a collection.
-Anshum
On Fri, Dec 9, 2016 at 12:57 PM Tomás Fernández Löbbe
wrote:
> We cur
We currently support requests to CREATEALIAS to collections that don’t
exist. Requests to this alias later result in 404s. If the target
collection is later created, requests to the alias will begin to work. I’m
wondering if someone is relying on this behavior, or if we should validate
the existenc
Hi,
I'm trying to index Turkish characters. These are what I see at my index (I
see both of them at different places of my content):
aç �klama
açıklama
These are same words but indexed different (same weird character at first
one). I see that there is not a weird character when I check the origi
Jihwan:
Correct. Do note that there are two distinct warnings here:
1> "Error opening new searcher. exceeded limit of maxWarmingSearchers"
2> "PERFORMANCE WARNING: Overlapping onDeckSearchers=..."
in <1>, the new searcher is _not_ opened.
in <2>, the new searcher _is_ opened.
In practice, ge
why is there a setting (maxWarmingSearchers) that even lets you have more
than one:
Isn't it also for a case of (frequent) update? For example, one update is
committed. During the warming up for this commit, another update is
made. In this case the new commit also go through another warming. If
I took a quick look at the code and really don't see any attempt to
resolve sysvars in the collection create code so I don't think this is
supported. Certainly sysvar substitution when reading core.properties
files is supported.
I don't know what gotchas there'd be in supporting this, you could
ra
bq: because shouldn't there only be one active
searcher at a time?
Kind of. This is a total nit, but there can be multiple
searchers serving queries briefly (one hopes at least).
S1 is serving some query when S2 becomes
active and starts getting new queries. Until the last
query S1 is serving is c
Hmmm, conflicting answers. Given the infamous "PERFORMANCE WARNING:
Overlapping onDeckSearchers" log message, it seems like the "they're the
same" answer is probably correct, because shouldn't there only be one active
searcher at a time?
Although it makes me curious, if there's a warning about hav
An on-deck searcher is not yet the active searcher. The SolrCore increments
the on-deck searcher count prior to starting the warming process. Unless
it's the first searcher, a new searcher will be warmed and then registered.
Once registered the searcher becomes active.
So, the initial question: is
No OOM, no corrupted index. Just a clean instal with few documents. Similar
to this:
http://lucene.472066.n3.nabble.com/NoSuchFileException-errors-common-on-version-5-5-0-td4263072.html
On Wed, Nov 30, 2016 at 3:19 AM, Shawn Heisey wrote:
> On 11/29/2016 8:40 AM, halis Yılboğa wrote:
> > it is n
My guess is system time is high either due to lock contention (too many
parallel threads) or page faults.
Heap size was less than 6gb when this long pause occurred, and and young
generation was less than 2gb. Though lowering heap size would help I don't
think that is the root cause here
On Dec 9
Hi
I am trying to create a collection via Collection API and set a core
property to use system substitution variable as shown below:
http://localhost:8090/solr/admin/collections?action=
CREATE&name=ds&numShards=1&replicationFactor=1&
maxShardsPerNode=1&collection.configName=ds&property.
dataDir=$
On 12/8/2016 6:08 PM, Brent wrote:
> Is there a difference between an "on deck" searcher and a warming
> searcher? From what I've read, they sound like the same thing.
The on-deck searcher is the one that's active and serving queries. A
warming searcher is one that is still coming up. As soon a
Then again, if the load characteristics on the Solr instance differ e.g.
by time of day, G1GC, in my experience, may have trouble adapting. For
instance if your query load reduces drastically during the night, it may
take a while for G1GC to catch up in the morning. What I've found useful
from
27 matches
Mail list logo
