clear query| facets| time Search criteria: author:"Mark Miller".   Results from 1 to 10 from 787 (0.0s).
Loading phrases to help you
refine your search...
[SOLR-3750] On session expiration, we should explicitly wait some time before running the leader sync process so that we are sure every node participates. - Solr - [issue]
...We should wait until all the known nodes are part of the election, or X amount of time if that does not happen (when a node or more does not come back for whatever reason)....
http://issues.apache.org/jira/browse/SOLR-3750    Author: Mark Miller , 2016-05-09, 18:47
[SOLR-3751] Add defensive checks against errant updates to distrib update processor. - Solr - [issue]
...The distrib update processor should do sanity checks on incoming updates - you never know what greedy routers might hang to some packets for while before letting them go.We can quickly and e...
http://issues.apache.org/jira/browse/SOLR-3751    Author: Mark Miller , 2016-05-09, 18:47
[SOLR-3752] Currently it seems that when a leader goes down, he stays marked as the leader in the ClusterState - it's not strictly necessary, but I think the leader should be cleared until the new one is elected. - Solr - [issue]
http://issues.apache.org/jira/browse/SOLR-3752    Author: Mark Miller , 2016-05-09, 18:47
[SOLR-3756] If we are elected the leader of a shard, but we fail to publish this for any reason, we should clean up and re trigger a leader election. - Solr - [issue]
http://issues.apache.org/jira/browse/SOLR-3756    Author: Mark Miller , 2016-05-09, 18:49
[SOLR-3772] On cluster startup, we should wait until we see all registered replicas before running the leader process - or if they all do not come up, N amount of time. - Solr - [issue]
...This seems like a simple and good way to start....
http://issues.apache.org/jira/browse/SOLR-3772    Author: Mark Miller , 2016-05-09, 18:52
[SOLR-3773] Hash based on the external String id rather than the indexed representation for distributed updates. - Solr - [issue]
...This makes some things easier - such as external systems doing the hashing themselves (like CloudSolrServer).It will be back compat for String id types but not others. Sent an email to the l...
http://issues.apache.org/jira/browse/SOLR-3773    Author: Mark Miller , 2016-05-09, 18:52
[SOLR-3782] A leader going down while updates are coming in can cause shard inconsistency. - Solr - [issue]
...Harpoon into the head of the great whale I have been chasing for a couple weeks now.ChaosMonkey test was exposing this.Turns out the problem was the solr cmd distrib executor - when closing ...
http://issues.apache.org/jira/browse/SOLR-3782    Author: Mark Miller , 2016-05-09, 18:54
[SOLR-3794] We should protect against the corner case where zk session expiration causes a new leader election but only recovering nodes make it into the election. - Solr - [issue]
http://issues.apache.org/jira/browse/SOLR-3794    Author: Mark Miller , 2016-05-09, 18:55
[SOLR-3807] Currently during recovery we pause for a number of seconds after waiting for the leader to see a recovering state so that any previous updates will have finished before our commit on the leader - we don't need this wait for peersync. - Solr - [issue]
http://issues.apache.org/jira/browse/SOLR-3807    Author: Mark Miller , 2016-05-09, 18:56
[SOLR-3812] ConnectionLoss during recovery can cause lost updates, leading to shard inconsistency. - Solr - [issue]
...When we lose our connection to ZooKeeper due to connectionloss (that does not lead to expiration), we can drop updates when replaying buffered updates and think we have successfully recovere...
http://issues.apache.org/jira/browse/SOLR-3812    Author: Mark Miller , 2016-05-09, 18:57