Zisis: It's not so much that the behavior has changed, and it's still perfectly possible to use old-style solr.xml. Rather, it's that there has been quite a lot of hardening how SolrCloud creates things. I realize that the Collections API is more of a black box and you have to take on faith that it's doing the right thing. That said, the API was written by people deeply involved in the guts of how SolrCloud works and has some safeguards built in.
bq: Do you mean getting rid of Zookeeper snapshot and transcation logs, basically clearing things and removing zknodes like clusterstate.json, overseer and the like? This is just a recipe for how I completely blow away Zookeeper's knowledge of the system so I'm _sure_ nothing's hanging around. Note that I frequently bounce around from one thing to another rather than maintain a single system, so I'm pretty cavalier about this. Mostly I've spent too much time being hammered by something I'd forgotten I changed when moving from one problem to another. I mean I'll spin up Solr 5.x, one or two Solr 4.x versions and maybe trunk over the course of a day while working on various problems; it's easy to lose track. Of course you wouldn't want to resort to this in a "real" environment. "rm -rf /tmp/zookeeper' is just an incantation I often use ;) But yes, that's what's going on. The clusterstate and all non-ephemeral nodes are just gone. There are more sophisticated ways to do this that aren't so blunt if you'd prefer. Do be a bit aware, though, that if the replicas are still on the Solr nodes, they can re-register themselves after you blow away the Zookeeper info. bq: Do you see anything unusual there. Unusual, but not necessarily bad. The collections API takes much of the guesswork out of this though. For instance, are you quite sure you're naming each replica such that there are no collisions? Note that you can also specify what nodes the leaders and replicas go on, and you can script this if using the Collections API. Ditto with adding replicas (of course this latter came in later than 4.4 IIRC). Not intimately familiar with HttpShardHandlerFactory, but on a quick glance it's handling pooling threads for sub-requests to other shards. May be way off base here. Erick On Fri, Feb 13, 2015 at 9:21 AM, Zisis Tachtsidis <zist...@runbox.com> wrote: > Erick Erickson wrote >> OK, I think this is the root of your problem: >> >> bq: Everything was setup using the - now deprecated - tags >> <cores> >> and >> <core> >> inside solr.xml. >> >> There are a bunch of ways this could go wrong. I'm pretty sure you >> have something that would take quite a while to untangle, so unless >> you have a _very_ good reason for making this work, I'd blow >> everything away. > > I've started playing with SolrCloud before the new solr.xml made its > appearance (in the example files of 4.4 distribution If I'm not mistaken) > and since it was classified only as deprecated I decided to postpone the > transition to the new solr.xml for the migration to Solr 5.0. Anyway, what > you are saying is that the use of the new solrcloud-friendly configuration > file is accompanied by changes in SolrCloud behavior? > > > Erick Erickson wrote >> If you're using an external Zookeeper shut if off and, 'rm -rf >> /tmp/zookeeper'. If using embedded, you can remove zoo_data under your >> SOLR_HOME. > > Do you mean getting rid of Zookeeper snapshot and transcation logs, > basically clearing things and removing zknodes like clusterstate.json, > overseer and the like? > > > Erick Erickson wrote >> OK, now use the Collections API to create your collection, see: >> https://cwiki.apache.org/confluence/display/solr/Collections+API and >> go from there (don't forget to push your configs to Zookeeper first) >> and go from there. > > I've successfully tried your proposed approach using the new solr.xml but > I've bypassed the collections API and added core.properties files inside my > collection directories. Directories contain no other files and configuration > has been preloaded into Zookeeper. I prefer to have everything ready before > starting the Solr servers. Do you see anything unusual there? > > One last thing, what exactly is HttpShardHandlerFactory responsible for? > Because there was no such definition in the deprecated solr.xml I was using. > > Thanks Erick, > Zisis T. > > > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Index-directory-containing-only-segments-gen-tp4186045p4186316.html > Sent from the Solr - User mailing list archive at Nabble.com.
