bq: Do you think it would be possible to add an abstraction layer to Solr source code in near future?
I strongly doubt it. As you've already noted, this is a large amount of work. Without some super-compelling advantage I just don't see the interest. bq: to avoid deploying ZK just for SolrCloud would save a bunch of $$ for large customers How so? It's free. Making this change would, IMO, require a compelling story to generate much enthusiasm. So far I haven't seen that story, and Jürgen and Walter raise valid points that haven't been addressed. I suspect you're significantly underestimating the effort to get this stable in the SolrCloud world as well. I don't really want to be such a wet blanket, but you're asking about a very significant amount of work from a bunch of people, all of whom have lots of things on their plate. So without a _very_ good reason, I think it's unlikely to generate much interest. Best, Erick On Mon, Nov 3, 2014 at 11:17 AM, Greg Solovyev <g...@zimbra.com> wrote: > Thanks Erick, > after looking further into Solr's source code, I see that it's married to ZK > libraries and it won't be possible to extend existing code without diverting > from the trunk. At the same time, I don't see any reason for lack of > abstraction in cloud-related code of Solr and SolrJ. As far as I can see > Consul provides all that SolrCloud needs and so if cloud code was using some > more abstraction, ZK bindings could be substituted with another library. I am > willing to implement a this functionality and the abstraction, but at the > same time, I don't want to maintain my own branch of Solr because of this > integration. Do you think it would be possible to add an abstraction layer to > Solr source code in near future? > > I think Consul has all the features that SolrCloud needs and what's > especially attractive about Consul is that it's memory footprint is 100X > smaller than ZK. Mainly though, we are considering Consul as a main service > locator for a bunch of other moving parts within Zimbra, so being able to > avoid deploying ZK just for SolrCloud would save a bunch of $$ for large > customers. > > Thanks, > Greg > > ----- Original Message ----- > From: "Erick Erickson" <erickerick...@gmail.com> > To: solr-user@lucene.apache.org > Sent: Friday, October 31, 2014 5:15:09 PM > Subject: Re: Consul instead of ZooKeeper anyone? > > Not that I know of, but.... look before you leap. I took a quick look at > Consul and it really doesn't look like any kind of drop-in replacement. > Also, the Zookeeper usage in SolrCloud isn't really pluggable > AFAIK, so there'll be lots of places in the Solr code that need to be > reworked etc., especially in the realm of collections and sharding. > > The Collections API will be challenging to port over I think. > > Not to mention SolrJ and CloudSolrServer for clients who want to interact > with SolrCloud through Java. > > Not saying it won't work, I just suspect that getting it done would be > a big job, and thereafter keeping those changes in sync with the > changing SolrCloud code base would chew up a lots of time. So if > I were putting my Product Manager hat on I'd ask "is the benefit > worth the effort?". > > All that said, go for it if you've a mind to! > > Best, > Erick > > On Fri, Oct 31, 2014 at 4:08 PM, Greg Solovyev <g...@zimbra.com> wrote: >> I am investigating a project to make SolrCloud run on Consul instead of >> ZooKeeper. So far, my research revealed no such efforts, but I wanted to >> check with this list to make sure I am not going to be reinventing the >> wheel. Have anyone attempted using Consul instead of ZK to coordinate >> SolrCloud nodes? >> >> Thanks, >> Greg
