[jira] [Commented] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor

2012-12-04 Thread Per Steffensen (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509769#comment-13509769
 ] 

Per Steffensen commented on SOLR-3425:
--

You talk about using CloudSolrServer and/or LBHttpSolrServer for access to Core 
Admin API. This a little strange because:
* A Core Admin API request should be sent to a specific Solr node in order for 
you to control where the shard is created (or removed from)
* CloudSolrServer and LBHttpSolrServer are all about sending requests that can 
end up going to a (randmon) node among several nodes
With the quick-fix code above (Tommaso Teofili 01/May/12) you will end up 
having your shard created on a random node among all live nodes - it is very 
rarely want you want.

So as long as we are talking about accessing Core Admin API you probably always 
want to use HttpSolrServer, which is aimed a sending the request to a specific 
node.

But when talking about creating an entire collection consisting of many shards, 
it is certainly meaningful to use CloudSolrServer. To create entire collections 
(without having to create each shard yourself using the Core Admin API) we now 
have the Collection API in 4.0.0. The Collection API can be used through 
CloudSolrServer, except...
* You cant create your first collection through CloudSolrServer
* You cant create a collection through a CloudSolrServer, where 
default-collection is the collection you want to create
* etc
...basically because CloudSolrServer wants an existing collection (pointed to 
by its default-collection or a collection-name provided in the actual request) 
before it can do anything.
This will be fixed with SOLR-4140, but is not in 4.0.0.

Other things not in Collection API of 4.0.0
* You cant have more than one shard per collection on a single node - fixed in 
TLT-4114
* You cant specify which Solr nodes the shards for a new collection is allowed 
to be spread across - they are just spread across all live Solr nodes - fixed 
in TLT-4120

Please state if you still believe something is missing or unclear. Or else you 
might want to state that your problems are solved with the 4.0.0 Collection 
API (maybe plus one or more of SOLR-4140, SOLR-4114 and SOLR-4120 which will 
hopefully be in the next release) by closing this issue SOLR-3425

 CloudSolrServer can't create cores when using the zkHost based constructor
 --

 Key: SOLR-3425
 URL: https://issues.apache.org/jira/browse/SOLR-3425
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Tommaso Teofili
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.1

 Attachments: SOLR-3425-test.patch


 When programmatically creating cores with a running SolrCloud instance the 
 CloudSolrServer uses the slices nodes information to feed the underlying 
 LBHttpSolrServer so it fails to create cores as there aren't any slices for 
 any new collection (as it's still to be created).
 This happens when using the CloudSolrServer constructor which takes the ZK 
 host as only parameter while it can be avoided by using the constructor which 
 also takes the list of Solr URLs and the underlying LBHttpSolrServer is 
 actually used for making the core creation request.
 However it'd be good to use the ZK host live nodes information to 
 automatically issue a core creation command on one of the underlying Solr 
 hosts without having to specify the full list of URLs beforehand.
 The scenario is when one wants to create a collection with N shards so the 
 client sends N core creation requests for the same collection thus the 
 SolrCloud stuff should just take care of choosing the host where to issue the 
 core creation request and update the cluster state.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor

2012-12-04 Thread Tommaso Teofili (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509793#comment-13509793
 ] 

Tommaso Teofili commented on SOLR-3425:
---

this issue was opened before the Collections API was designed, so basically 
things have changed along time but apart from that as long as there's SOLR-4140 
the use case I opened this for is safe, therefore I'll close it.
Thanks [~steff1193] for helping out.

 CloudSolrServer can't create cores when using the zkHost based constructor
 --

 Key: SOLR-3425
 URL: https://issues.apache.org/jira/browse/SOLR-3425
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Tommaso Teofili
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.1

 Attachments: SOLR-3425-test.patch


 When programmatically creating cores with a running SolrCloud instance the 
 CloudSolrServer uses the slices nodes information to feed the underlying 
 LBHttpSolrServer so it fails to create cores as there aren't any slices for 
 any new collection (as it's still to be created).
 This happens when using the CloudSolrServer constructor which takes the ZK 
 host as only parameter while it can be avoided by using the constructor which 
 also takes the list of Solr URLs and the underlying LBHttpSolrServer is 
 actually used for making the core creation request.
 However it'd be good to use the ZK host live nodes information to 
 automatically issue a core creation command on one of the underlying Solr 
 hosts without having to specify the full list of URLs beforehand.
 The scenario is when one wants to create a collection with N shards so the 
 client sends N core creation requests for the same collection thus the 
 SolrCloud stuff should just take care of choosing the host where to issue the 
 core creation request and update the cluster state.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor

2012-09-19 Thread Tommaso Teofili (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458534#comment-13458534
 ] 

Tommaso Teofili commented on SOLR-3425:
---

I had a simple patch for making this work, however I'm not too sure what we 
need to do here (it made sense before but with the new Collections API it may 
be not that urgent).
Maybe we can defer this and get advantage of SOLR-3488 as soon as that's 
finished.


 CloudSolrServer can't create cores when using the zkHost based constructor
 --

 Key: SOLR-3425
 URL: https://issues.apache.org/jira/browse/SOLR-3425
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Tommaso Teofili
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.0, 5.0

 Attachments: SOLR-3425-test.patch


 When programmatically creating cores with a running SolrCloud instance the 
 CloudSolrServer uses the slices nodes information to feed the underlying 
 LBHttpSolrServer so it fails to create cores as there aren't any slices for 
 any new collection (as it's still to be created).
 This happens when using the CloudSolrServer constructor which takes the ZK 
 host as only parameter while it can be avoided by using the constructor which 
 also takes the list of Solr URLs and the underlying LBHttpSolrServer is 
 actually used for making the core creation request.
 However it'd be good to use the ZK host live nodes information to 
 automatically issue a core creation command on one of the underlying Solr 
 hosts without having to specify the full list of URLs beforehand.
 The scenario is when one wants to create a collection with N shards so the 
 client sends N core creation requests for the same collection thus the 
 SolrCloud stuff should just take care of choosing the host where to issue the 
 core creation request and update the cluster state.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor

2012-09-18 Thread Robert Muir (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457905#comment-13457905
 ] 

Robert Muir commented on SOLR-3425:
---

Mark/Tommaso, can you guys look at this issue? I notice it hasn't been touched 
in months. is it going to make 4.0?

 CloudSolrServer can't create cores when using the zkHost based constructor
 --

 Key: SOLR-3425
 URL: https://issues.apache.org/jira/browse/SOLR-3425
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Tommaso Teofili
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.0, 5.0

 Attachments: SOLR-3425-test.patch


 When programmatically creating cores with a running SolrCloud instance the 
 CloudSolrServer uses the slices nodes information to feed the underlying 
 LBHttpSolrServer so it fails to create cores as there aren't any slices for 
 any new collection (as it's still to be created).
 This happens when using the CloudSolrServer constructor which takes the ZK 
 host as only parameter while it can be avoided by using the constructor which 
 also takes the list of Solr URLs and the underlying LBHttpSolrServer is 
 actually used for making the core creation request.
 However it'd be good to use the ZK host live nodes information to 
 automatically issue a core creation command on one of the underlying Solr 
 hosts without having to specify the full list of URLs beforehand.
 The scenario is when one wants to create a collection with N shards so the 
 client sends N core creation requests for the same collection thus the 
 SolrCloud stuff should just take care of choosing the host where to issue the 
 core creation request and update the cluster state.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor

2012-05-22 Thread Tommaso Teofili (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13281055#comment-13281055
 ] 

Tommaso Teofili commented on SOLR-3425:
---

Mark, I'd commit this quick fix for now so that we solve the bug and maybe we 
can start discussing about a new collection management API on a different issue.

 CloudSolrServer can't create cores when using the zkHost based constructor
 --

 Key: SOLR-3425
 URL: https://issues.apache.org/jira/browse/SOLR-3425
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Tommaso Teofili
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-3425-test.patch


 When programmatically creating cores with a running SolrCloud instance the 
 CloudSolrServer uses the slices nodes information to feed the underlying 
 LBHttpSolrServer so it fails to create cores as there aren't any slices for 
 any new collection (as it's still to be created).
 This happens when using the CloudSolrServer constructor which takes the ZK 
 host as only parameter while it can be avoided by using the constructor which 
 also takes the list of Solr URLs and the underlying LBHttpSolrServer is 
 actually used for making the core creation request.
 However it'd be good to use the ZK host live nodes information to 
 automatically issue a core creation command on one of the underlying Solr 
 hosts without having to specify the full list of URLs beforehand.
 The scenario is when one wants to create a collection with N shards so the 
 client sends N core creation requests for the same collection thus the 
 SolrCloud stuff should just take care of choosing the host where to issue the 
 core creation request and update the cluster state.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor

2012-05-01 Thread Mark Miller (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13265805#comment-13265805
 ] 

Mark Miller commented on SOLR-3425:
---

I'd like to improve collection creation outside of Solrj as well - but I think 
it also makes sense to improve this here as well. Do you have a proposal yet? 
Perhaps we should just add new collection management api? Trying to wrap this 
stuff in a SolrCore's world gets kind of ugly.

 CloudSolrServer can't create cores when using the zkHost based constructor
 --

 Key: SOLR-3425
 URL: https://issues.apache.org/jira/browse/SOLR-3425
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Tommaso Teofili
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-3425-test.patch


 When programmatically creating cores with a running SolrCloud instance the 
 CloudSolrServer uses the slices nodes information to feed the underlying 
 LBHttpSolrServer so it fails to create cores as there aren't any slices for 
 any new collection (as it's still to be created).
 This happens when using the CloudSolrServer constructor which takes the ZK 
 host as only parameter while it can be avoided by using the constructor which 
 also takes the list of Solr URLs and the underlying LBHttpSolrServer is 
 actually used for making the core creation request.
 However it'd be good to use the ZK host live nodes information to 
 automatically issue a core creation command on one of the underlying Solr 
 hosts without having to specify the full list of URLs beforehand.
 The scenario is when one wants to create a collection with N shards so the 
 client sends N core creation requests for the same collection thus the 
 SolrCloud stuff should just take care of choosing the host where to issue the 
 core creation request and update the cluster state.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor

2012-05-01 Thread Tommaso Teofili (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13265841#comment-13265841
 ] 

Tommaso Teofili commented on SOLR-3425:
---

bq. Perhaps we should just add new collection management api?

I think so, that would also help SolrCloud users understand the mind shift from 
cores to collections.

For this particular thing the dummy fix (not tested widely but still all the 
tests pass) could be to add the following lines for filling the urlList 
variable:
{code}
// enable automatic distributed core creation
if (request instanceof CoreAdminRequest.Create) {
  for (String liveNodeHost : zkStateReader.getCloudState().getLiveNodes()) {
urlList.add(new 
StringBuilder(http://;).append(liveNodeHost.replaceAll(_solr, 
/solr/)).toString());
  }
}
else {
  for (Slice slice : slices.values()) {
...
{code}

however i don't like it very much. I think adding proper APIs would be just 
better.

 CloudSolrServer can't create cores when using the zkHost based constructor
 --

 Key: SOLR-3425
 URL: https://issues.apache.org/jira/browse/SOLR-3425
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Tommaso Teofili
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-3425-test.patch


 When programmatically creating cores with a running SolrCloud instance the 
 CloudSolrServer uses the slices nodes information to feed the underlying 
 LBHttpSolrServer so it fails to create cores as there aren't any slices for 
 any new collection (as it's still to be created).
 This happens when using the CloudSolrServer constructor which takes the ZK 
 host as only parameter while it can be avoided by using the constructor which 
 also takes the list of Solr URLs and the underlying LBHttpSolrServer is 
 actually used for making the core creation request.
 However it'd be good to use the ZK host live nodes information to 
 automatically issue a core creation command on one of the underlying Solr 
 hosts without having to specify the full list of URLs beforehand.
 The scenario is when one wants to create a collection with N shards so the 
 client sends N core creation requests for the same collection thus the 
 SolrCloud stuff should just take care of choosing the host where to issue the 
 core creation request and update the cluster state.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org