[jira] [Commented] (SOLR-9566) Can we avoid doing recovery when collections are first created?
[ https://issues.apache.org/jira/browse/SOLR-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582907#comment-15582907 ] ASF subversion and git services commented on SOLR-9566: --- Commit 65f55802ee01b90a7f529de270d5d866a2282a40 in lucene-solr's branch refs/heads/master from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=65f5580 ] SOLR-9566: Don't put replicas into recovery when collections are created > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9566) Can we avoid doing recovery when collections are first created?
[ https://issues.apache.org/jira/browse/SOLR-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582906#comment-15582906 ] ASF subversion and git services commented on SOLR-9566: --- Commit c9eb9e10e4168ae1fba6d122ab80aa1402f33fce in lucene-solr's branch refs/heads/branch_6x from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c9eb9e1 ] SOLR-9566: Don't put replicas into recovery when collections are created > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9566) Can we avoid doing recovery when collections are first created?
[ https://issues.apache.org/jira/browse/SOLR-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582651#comment-15582651 ] Alan Woodward commented on SOLR-9566: - I got a verbal +1 from [~markrmil...@gmail.com] at Revolution, so I'll commit this shortly. Anybody who disagrees should speak up now... > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
