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
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
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=CREATEname=foonumShards=4
Dec 07, 2012 2:01:03 PM org.apache.solr.core.SolrCore execute
INFO: [15671]
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
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
