On 3/9/2016 10:43 AM, Joel Bernstein wrote: > From Alfresco's point of view this would be a bad thing. Alfresco uses > Solr in stand alone mode and has developed an entire sharding and > replication model that fit's the ECM use case. So being forced to have > ZooKeeper and Solr Cloud would not be ideal.
I'm aware of the potential pain. Third-party Solr support and the documentation that goes with it might require significant changes -- but those changes will already be required if those packages want to add support for talking to SolrCloud in general. I firmly believe that "cloud mode only" is the way Solr is headed, and that once we reach the other side, Solr will be better, especially because of documentation and API consolidation. My intent would not be to force SolrCloud's built-in sharding on everyone. You could still do completely manual sharding and work with individual Solr nodes like before. The difference would be that each "standalone" Solr node would internally use zookeeper (probably the embedded server) to manage itself. We might need to invent a "standalone collection" concept that could be used for single-shard-single-replica collections, where the core name and the collection name are the same, instead of cores named foo_shardN_replicaN. I myself would feel a lot of the pain you mentioned in relation to Alfresco. I'm also manually managing shards on standalone Solr instances. I've got a significant investment in a SolrJ application to handle these indexes. The change should not happen before 7.0, and with a major change like that on the horizon, the major version *before* the change (such as 6.x) should remain the stable branch for quite a while, so everybody has time to update and support cloud mode before it becomes mandatory. There will be a lot of details to iron out. I hope to be able to help with that. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
