lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Steffensen (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor
Date Tue, 04 Dec 2012 14:42:58 GMT

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

Per Steffensen edited comment on SOLR-3425 at 12/4/12 2:42 PM:
---------------------------------------------------------------

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
                
      was (Author: steff1193):
    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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message