Thanks Shawn,
Missed the openSearcher=false setting.
So another thing to check really is whether there are concurrent
commitWithin calls ever to the same shard.
10 марта 2016 г. 4:39 PM пользователь "Shawn Heisey"
написал:
> On 3/10/2016 3:05 AM, Dmitry Kan wrote:
> > The only thing that I spot
On 3/10/2016 3:05 AM, Dmitry Kan wrote:
> The only thing that I spot is that you use both auto-commit with 900 sec
> frequency AND commitWithin. Solr is smart enough to skip empty commits. But
> if auto-commit kicks in during the doc add / delete, there will be at least
> two commits ongoing. Could
Hi,
The only thing that I spot is that you use both auto-commit with 900 sec
frequency AND commitWithin. Solr is smart enough to skip empty commits. But
if auto-commit kicks in during the doc add / delete, there will be at least
two commits ongoing. Could you change you Full recovery case to commi
Hi,
To give you some context, we are migrating from Solr4 and solr5,
the client code and the configuration haven't changed but now we are
facing this problem. We have already checked the commit behaviour
configuration and it seems good.
Here it is :
Server side, we have 2 collections (mai
Hi,
Check the the autoCommit and autoSoftCommit nodes in the solrconfig.xml.
Set them to reasonable values. The idea is that if you commit too often,
searchers will be warmed up and thrown away. If at any point in time you
get overlapping commits, there will be several searchers sitting on the
dec
Hi,
We are facing an issue during a migration from Solr4 to Solr5.
Given
- migration from solr 4.10.4 to 5.4.1
- 2 collections
- cloud with one leader and several replicas
- in solrconfig.xml: maxWarmingSearchers=1
- no code change
When collection reload using /admin/collectio
