Hi Esther-Melaine, The collection exists in Zookeeper under the /collections node and I can see the shardX_replicaX folders under $SOLR_HOME/server/solr of both servers.
I was not able to replicate the issue using the collection API. Here are the logs where I added the 'MyNewerNode' https://gist.github.com/orck-adrouin/4d074cbb60141cba90c0aae9c55360d4 I took a closer look at the admin UI and here are my findings: - In Chrome's devtool I can see the first create request - After 10 seconds the request getting aborted and a second create request is sent to the server - In Fiddler I can see that the first request completes successfully without any issues. The second request is sent a few seconds before the first one ends so it looks like a admin UI issue. Is it possible that the admin UI has some kind of TTL for requests set to 10 seconds? You mentioned something about the nodes going into recovery. Any idea how I can fix this issue? My development environment (if it makes a difference): - OS: Windows - 2 Solr 6.1 nodes using SolrCloud. They both are running on the same server using different ports. - Zookeeper 3.4.8 Alexandre Drouin -----Original Message----- From: Esther-Melaine Quansah [mailto:esther.quan...@lucidworks.com] Sent: August 12, 2016 10:46 AM To: solr-user@lucene.apache.org Subject: Re: Getting "collection already exists" when creating collection in admin UI Importance: High Hi Alexandre, The question here is why the create action is called twice. You’re getting that “collection already exists” error after the second action is called. Can you verify if MyNewNode exists in /collections in ZK or on the machines running Solr at $SOLR_HOME/server/solr/ Your logs show a lot of issues around the overseer and it looks like those nodes are going into recovery pretty frequently. Can you replicate this issue by creating a collection through the API (not through the UI): http://localhost:8983/admin/collections?action=CREATE&name=MyNewerNode&numShards=1&replicationFactor=2&maxShardsPerNode=1&collection.configName=DefaultConfig Thanks, Esther > On Aug 12, 2016, at 10:05 AM, Alexandre Drouin > <alexandre.dro...@orckestra.com> wrote: > > Hello, > > I am running SolrCloud with 2 nodes (Solr 6.1 with SSL and basic auth) and > with one Zookeeper node (for development purposes) and when I try to create a > new collection in the admin UI with 'replicationFactor=2' I get a > "Connection to Solr lost" message and another message telling me " collection > already exists: MyNewNode". I made sure that a collection with the same name > does not exists and the issue does not appear with a replication factor of 1. > > > While debugging I saw that the create action is called twice with the > following parameters: > /solr/admin/collections?_=1471010473184&action=CREATE&collection.confi > gName=DefaultConfig&maxShardsPerNode=1&name=aaa&numShards=1&replicatio > nFactor=2&router.name=compositeId&routerName=compositeId&wt=json > > Can anyone replicate this issue? I have not found it in JIRA. > > > Below is the relevant log (if useful) and I posted the full logs here > https://gist.github.com/orck-adrouin/690d485ba0835320273e7b2e09fb3771 > > 63549 ERROR > (OverseerThreadFactory-5-thread-5-processing-n:orc-dev-solr-cd.local:8444_solr) > [ ] o.a.s.c.OverseerCollectionMessageHandler Collection: MyNewNode > operation: create failed:org.apache.solr.common.SolrException: collection > already exists: MyNewNode > at > org.apache.solr.cloud.OverseerCollectionMessageHandler.createCollection(OverseerCollectionMessageHandler.java:1832) > at > org.apache.solr.cloud.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:224) > at > org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:463) > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$22(ExecutorUtil.java:229) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > > Thanks, > Alexandre Drouin
