I had tried importing data from Manifold, and one document threw a Tika Exception.
If I shut everything down and restart SOLR cloud, the system sync'd on startup. Could extraction errors be the issue? On Sun, Mar 18, 2012 at 2:50 PM, Matthew Parker < mpar...@apogeeintegration.com> wrote: > I have nodes running on ports: 8081-8084 > > A couple of the other SOLR cloud nodes we complaining about not being talk > with 8081, which is the first node brought up in the cluster. > > The startup process is: > > 1. start 3 zookeeper nodes > > 2. wait until complete > > 3. start first solr node. > > 4. wait until complete > > 5. start remaining 3 solr nodes. > > I wiped the zookeper and solr nodes data directories to start fresh. > > Another question: Would a Tika Exception cause the nodes not to replicate? > I can see the documents being commited on the first solr node, but nothing > replicates to the other 3. > > > > > On Sun, Mar 18, 2012 at 2:07 PM, Mark Miller <markrmil...@gmail.com>wrote: > >> From every node in your cluster you can hit http://MACHINE1:8084/solr in >> your browser and get a response? >> >> On Mar 18, 2012, at 1:46 PM, Matthew Parker wrote: >> >> > My cloud instance finally tried to sync. It looks like it's having >> connection issues, but I can bring the SOLR instance up in the browser so >> I'm not sure why it cannot connect to it. I got the following condensed log >> output: >> > >> > org.apache.commons.httpclient.HttpMethodDirector executeWithRetry >> > I/O exception (java.net.ConnectException) caught when processing >> request: Connection refused: connect >> > >> > org.apache.commons.httpclient.HttpMethodDirector executeWithRetry >> > I/O exception (java.net.ConnectException) caught when processing >> request: Connection refused: connect >> > >> > org.apache.commons.httpclient.HttpMethodDirector executeWithRetry >> > I/O exception (java.net.ConnectException) caught when processing >> request: Connection refused: connect >> > >> > Retrying request >> > >> > shard update error StdNode: >> http://MACHINE1:8084/solr/:org.apache.solr.client.solrj.SolrServerException: >> http://MACHINE1:8084/solr >> > at >> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java: >> 483) >> > .. >> > .. >> > .. >> > Caused by: java.net.ConnectException: Connection refused: connect >> > at java.net.DualStackPlainSocketImpl.connect0(Native Method) >> > .. >> > .. >> > .. >> > >> > try and ask http://MACHINE1:8084/solr to recover >> > >> > Could not tell a replica to recover >> > >> > org.apache.solr.client.solrj.SolrServerException: >> http://MACHINE1:8084/solr >> > at >> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:483) >> > ... >> > ... >> > ... >> > Caused by: java.net.ConnectException: Connection refused: connect >> > at java.net.DualStackPlainSocketImpl.waitForConnect(Native method) >> > .. >> > .. >> > .. >> > >> > On Sat, Mar 17, 2012 at 10:10 PM, Mark Miller <markrmil...@gmail.com> >> wrote: >> > Nodes talk to ZooKeeper as well as to each other. You can see the >> addresses they are trying to use to communicate with each other in the >> 'cloud' view of the Solr Admin UI. Sometimes you have to override these, as >> the detected default may not be an address that other nodes can reach. As a >> limited example: for some reason my mac cannot talk to my linux box with >> its default detected host address of halfmetal:8983/solr - but the mac can >> reach my linux box if I use halfmetal.Local - so I have to override the >> published address of my linux box using the host attribute if I want to >> setup a cluster between my macbook and linux box. >> > >> > Each nodes talks to ZooKeeper to learn about the other nodes, including >> their addresses. Recovery is then done node to node using the appropriate >> addresses. >> > >> > >> > - Mark Miller >> > lucidimagination.com >> > >> > On Mar 16, 2012, at 3:00 PM, Matthew Parker wrote: >> > >> > > I'm still having issues replicating in my work environment. Can anyone >> > > explain how the replication mechanism works? Is it communicating >> across >> > > ports or through zookeeper to manager the process? >> > > >> > > >> > > >> > > >> > > On Thu, Mar 8, 2012 at 10:57 PM, Matthew Parker < >> > > mpar...@apogeeintegration.com> wrote: >> > > >> > >> All, >> > >> >> > >> I recreated the cluster on my machine at home (Windows 7, Java >> 1.6.0.23, >> > >> apache-solr-4.0-2012-02-29_09-07-30) , sent some document through >> Manifold >> > >> using its crawler, and it looks like it's replicating fine once the >> > >> documents are committed. >> > >> >> > >> This must be related to my environment somehow. Thanks for your help. >> > >> >> > >> Regards, >> > >> >> > >> Matt >> > >> >> > >> On Fri, Mar 2, 2012 at 9:06 AM, Erick Erickson < >> erickerick...@gmail.com>wrote: >> > >> >> > >>> Matt: >> > >>> >> > >>> Just for paranoia's sake, when I was playing around with this (the >> > >>> _version_ thing was one of my problems too) I removed the entire >> data >> > >>> directory as well as the zoo_data directory between experiments (and >> > >>> recreated just the data dir). This included various index.2012.... >> > >>> files and the tlog directory on the theory that *maybe* there was >> some >> > >>> confusion happening on startup with an already-wonky index. >> > >>> >> > >>> If you have the energy and tried that it might be helpful >> information, >> > >>> but it may also be a total red-herring.... >> > >>> >> > >>> FWIW >> > >>> Erick >> > >>> >> > >>> On Thu, Mar 1, 2012 at 8:28 PM, Mark Miller <markrmil...@gmail.com> >> > >>> wrote: >> > >>>>> I assuming the windows configuration looked correct? >> > >>>> >> > >>>> Yeah, so far I can not spot any smoking gun...I'm confounded at the >> > >>> moment. I'll re read through everything once more... >> > >>>> >> > >>>> - Mark >> > >>> >> > >> >> > >> >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > ------------------------------ >> > This e-mail and any files transmitted with it may be proprietary. >> Please note that any views or opinions presented in this e-mail are solely >> those of the author and do not necessarily represent those of Apogee >> Integration. >> > >> > >> >> - Mark Miller >> lucidimagination.com >> >> >> >> >> >> >> >> >> >> >> >> > ------------------------------ This e-mail and any files transmitted with it may be proprietary. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Apogee Integration.