Yeah it is - this was fixed a while ago on 4x and will be in 4.1. An exception would kill the collection manager wait loop.
- Mark On Sun, Dec 9, 2012 at 9:21 PM, Brett Hoerner <br...@bretthoerner.com> wrote: > Thanks, > > It looks like my cluster is in a wedged state after I tried to delete a > collection that didn't exist. There are about 80 items in the queue after > the delete op (that it can't get by). Is that a known bug? > > I guess for now I'll just check that a collection exists before sending any > deletes. :) > > Brett > > > On Fri, Dec 7, 2012 at 10:50 AM, Mark Miller <markrmil...@gmail.com> wrote: > >> Anything in any of the other logs (the other nodes)? The key is getting >> the logs from the node designated as the overseer - it should hopefully >> have the error. >> >> Right now because you pass this stuff off to the overseer, you will always >> get back a 200 - there is a JIRA issue that addresses this though >> (collection API responses) and I hope to get it committed soon. >> >> - Mark >> >> On Dec 7, 2012, at 7:26 AM, Brett Hoerner <br...@bretthoerner.com> wrote: >> >> > For what it's worth this is the log output with DEBUG on, >> > >> > Dec 07, 2012 2:00:48 PM org.apache.solr.handler.admin.CollectionsHandler >> > handleCreateAction >> > INFO: Creating Collection : action=CREATE&name=foo&numShards=4 >> > Dec 07, 2012 2:01:03 PM org.apache.solr.core.SolrCore execute >> > INFO: [15671] webapp=/solr path=/admin/system params={wt=json} status=0 >> > QTime=5 >> > Dec 07, 2012 2:01:15 PM org.apache.solr.handler.admin.CollectionsHandler >> > handleDeleteAction >> > INFO: Deleting Collection : action=DELETE&name=default >> > Dec 07, 2012 2:01:20 PM org.apache.solr.core.SolrCore execute >> > >> > Neither the CREATE or DELETE actually did anything, though. (Again, HTTP >> > 200 OK) >> > >> > Still stuck here, any ideas? >> > >> > Brett >> > >> > >> > On Tue, Dec 4, 2012 at 7:19 PM, Brett Hoerner <br...@bretthoerner.com >> >wrote: >> > >> >> Hi, >> >> >> >> I have a Cloud setup of 4 machines. I bootstrapped them with 1 >> collection, >> >> which I called "default" and haven't used since. I'm using an external >> ZK >> >> ensemble that was completely empty before I started this cloud. >> >> >> >> Once I had all 4 nodes in the cloud I used the collection API to create >> >> the real collections I wanted. I also tested that deleting works. >> >> >> >> For example, >> >> >> >> # this worked >> >> curl " >> >> >> http://localhost:8984/solr/admin/collections?action=CREATE&name=15678&numShards=4 >> >> " >> >> >> >> # this worked >> >> curl " >> >> http://localhost:8984/solr/admin/collections?action=DELETE&name=15678" >> >> >> >> Next, I started my indexer service which happily sent many, many updates >> >> to the cloud. Queries against the collections also work just fine. >> >> >> >> Finally, a few hours later, I tried doing a create and a delete. Both >> >> operations did nothing, although Solr replied with a "200 OK". >> >> >> >> $ curl -i " >> >> >> http://localhost:8984/solr/admin/collections?action=CREATE&name=15679&numShards=4 >> >> " >> >> HTTP/1.1 200 OK >> >> Content-Type: application/xml; charset=UTF-8 >> >> Transfer-Encoding: chunked >> >> >> >> <?xml version="1.0" encoding="UTF-8"?> >> >> <response> >> >> <lst name="responseHeader"><int name="status">0</int><int >> >> name="QTime">3</int></lst> >> >> >> >> There is nothing in the stdout/stderr logs, nor the Java logs (I have it >> >> set to WARN). >> >> >> >> I have tried bouncing the nodes and it doesn't change anything. >> >> >> >> Any ideas? How can I further debug this or what else can I provide? >> >> >> >> -- - Mark