[
https://issues.apache.org/jira/browse/SOLR-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Woodward updated SOLR-9566:
--------------------------------
Attachment: SOLR-9566.patch
Here's a patch adding a 'newCollection' parameter to the core create command.
I haven't run it through a full test yet, but DeleteReplicaTest went from 54
seconds to 20 seconds, which is a very nice speedup.
[[email protected]] [[email protected]] is this proposal sane?
> Can we avoid doing recovery when collections are first created?
> ---------------------------------------------------------------
>
> Key: SOLR-9566
> URL: https://issues.apache.org/jira/browse/SOLR-9566
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Alan Woodward
> Attachments: SOLR-9566.patch
>
>
> When a core starts up as part of a collection, and it's not a shard leader,
> it goes into recovery, part of which involves a 7 second wait (set in
> SOLR-7141) to ensure that updates being sent from the leader don't get missed
> in between buffering and replication.
> This has the unfortunate side-effect of adding a 7-second pause to collection
> creation whenever the replication factor is 2 or more, which slows down tests
> massively - for example, DeleteReplicaTest takes about 54 seconds to execute
> on my machine, 28 seconds of which is just pauses - over 50% of execution
> time. It's not actually possible to add documents to a collection before the
> creation request has returned, so the recovery stage here isn't strictly
> speaking necessary.
> I think we could try adding a parameter to a CoreAdmin create request that
> says the core is being created as part of a new collection, so it doesn't
> need to try and recover from it's leader when it starts up. Does this sound
> sensible, or am I missing something here?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
