You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by davers <db...@improvementdirect.com> on 2013/01/03 01:58:29 UTC
Solr Collection API doesn't seem to be working
Hello I have an external zookeeper ensemble and I have started 6 tomcat
servers with solr running with the default solr.xml
I have uploaded the config directory to zookeeper and linked the collection.
http://d.pr/i/BkT
My solr.xml is nearly the default with a minor adjustment for the jetty.port
parameter:
<cores adminPath="/admin/cores" defaultCoreName="collection1"
host="${host:}" hostPort="${jetty.port:8080}" hostContext="${hostContext:}"
zkClientTimeout="${zkClientTimeout:15000}">
</cores>
When I try to create the collection issuing the command:
/solr/admin/collections?action=CREATE&name=productindex&numShards=3 (I leave
replicationFactor out because I want my cloud to automatically re-size
vertically as I add or remove replicant servers) I get output in the log:
INFO: Creating Collection : numShards=3&name=productindex&action=CREATE
But nothing happens. The solr.xml files are not updated. What am I doing
wrong?
--
View this message in context: http://lucene.472066.n3.nabble.com/Solr-Collection-API-doesn-t-seem-to-be-working-tp4030182.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solr Collection API doesn't seem to be working
Posted by Mark Miller <ma...@gmail.com>.
Happy to clarify.
- Mark
On Jan 3, 2013, at 10:02 AM, Per Steffensen <st...@designware.dk> wrote:
> Ok, sorry. Easy to misunderstand, though.
>
> On 1/3/13 3:58 PM, Mark Miller wrote:
>> MAX_INT is just a place holder for a high value given the context of this guy wanting to add replicas for as many machines as he adds down the line. You are taking it too literally.
>>
>> - Mark
>
Re: Solr Collection API doesn't seem to be working
Posted by Per Steffensen <st...@designware.dk>.
Ok, sorry. Easy to misunderstand, though.
On 1/3/13 3:58 PM, Mark Miller wrote:
> MAX_INT is just a place holder for a high value given the context of this guy wanting to add replicas for as many machines as he adds down the line. You are taking it too literally.
>
> - Mark
Re: Solr Collection API doesn't seem to be working
Posted by Mark Miller <ma...@gmail.com>.
MAX_INT is just a place holder for a high value given the context of this guy wanting to add replicas for as many machines as he adds down the line. You are taking it too literally.
- Mark
On Jan 3, 2013, at 9:02 AM, Per Steffensen <st...@designware.dk> wrote:
> On 1/3/13 2:50 AM, Mark Miller wrote:
>> Unfortunately, for 4.0, the collections API was pretty bare bones. You don't actually get back responses currently - you just pass off the create command to zk for the Overseer to pick up and execute.
>>
>> So you actually have to check the logs of the Overseer to see what the problem may be. I'm working on making sure we address this for 4.1.
>>
>> If you look at the admin UI, in the zk tree, you should be able to see what node is the overseer (look for its election node). The logs for that node should indicate the problem.
>>
>> FYI, if I remember right, replication factor is not currently optional.
> Actually I believe it is.
>>
>> In the future, I'd like it so you can say like replicationFactor=max_int, and the overseer will periodically try to match that given the nodes it sees - but we don't have that yet.
> Uhhhh, but why!
>
> It would be nice if you can say replicationFactor=X where X is higher than your current number of nodes, and overseer then periodically tries to see if it can honor your original request for replicationFactor X (it will be when you eventually have X nodes in your cluster).
>
> But specifying a MAX_INT value is IMHO a bad idea. It requires double "resource"-usage to maintain double number of replica, so you dont want more replica than necessary relative to your risk/HA-profile. I couldnt imaging a setup where you want replica of each shard across all nodes no matter how many nodes you add to your cluster. Of course you can always give a replicationFactor of 10 (or something high) and then if you know (currently believe) that you will never add more than 10 nodes to your cluster, then basically you will achieve what you wanted to do with MAX_INT. But if things evolve and you end up having 20 or 100 nodes in you cluster you probably do not want more than 10 replica anyway.
>>
>> When you add new nodes, to add them to a current collection you will either have to use CoreAdmin API or pre configure the cores in solr.xml. All you need is to specify a matching collection name for the new core.
>>
>> - Mark
>
Re: Solr Collection API doesn't seem to be working
Posted by Per Steffensen <st...@designware.dk>.
On 1/3/13 2:50 AM, Mark Miller wrote:
> Unfortunately, for 4.0, the collections API was pretty bare bones. You don't actually get back responses currently - you just pass off the create command to zk for the Overseer to pick up and execute.
>
> So you actually have to check the logs of the Overseer to see what the problem may be. I'm working on making sure we address this for 4.1.
>
> If you look at the admin UI, in the zk tree, you should be able to see what node is the overseer (look for its election node). The logs for that node should indicate the problem.
>
> FYI, if I remember right, replication factor is not currently optional.
Actually I believe it is.
>
> In the future, I'd like it so you can say like replicationFactor=max_int, and the overseer will periodically try to match that given the nodes it sees - but we don't have that yet.
Uhhhh, but why!
It would be nice if you can say replicationFactor=X where X is higher
than your current number of nodes, and overseer then periodically tries
to see if it can honor your original request for replicationFactor X (it
will be when you eventually have X nodes in your cluster).
But specifying a MAX_INT value is IMHO a bad idea. It requires double
"resource"-usage to maintain double number of replica, so you dont want
more replica than necessary relative to your risk/HA-profile. I couldnt
imaging a setup where you want replica of each shard across all nodes no
matter how many nodes you add to your cluster. Of course you can always
give a replicationFactor of 10 (or something high) and then if you know
(currently believe) that you will never add more than 10 nodes to your
cluster, then basically you will achieve what you wanted to do with
MAX_INT. But if things evolve and you end up having 20 or 100 nodes in
you cluster you probably do not want more than 10 replica anyway.
>
> When you add new nodes, to add them to a current collection you will either have to use CoreAdmin API or pre configure the cores in solr.xml. All you need is to specify a matching collection name for the new core.
>
> - Mark
Re: Solr Collection API doesn't seem to be working
Posted by Per Steffensen <st...@designware.dk>.
On 1/3/13 5:26 PM, Yonik Seeley wrote:
> I agree - it's pointless to have two replicas of the same shard on a
> single node. But I'm talking about having replicationFactor as a
> target, so when you start up *new* nodes they will become a replica
> for any shard where the number of replicas is currently less than the
> replicationFactor. Ideally, one would be able to create a new
> collection with no nodes initially assigned to it if desired.
Yes THAT is a cool thing, as I also mentioned earlier. We should
implement that!
But as it is today, if e.g. you have 2 nodes and ask for
replicationFactor 3 you will get 2 replica on one node and 1 replica on
the other. Here I would rather only create 1 replica on each node, so
that you only start up with 2 replica all in all (even though you asked
for 3). Then "remember" (in ZK) that you actually asked for 3 and let
the overseer create the 3rd replica on a new node as soon as such an
additional node is available.
Re: Solr Collection API doesn't seem to be working
Posted by davers <db...@improvementdirect.com>.
Yes that is exactly what I was hoping for. I can live with just adding nodes
manually for now. Would be nice if this feature was included in 4.1 though
as I will be waiting for the 4.1 release to make the jump to SolrCloud.
--
View this message in context: http://lucene.472066.n3.nabble.com/Solr-Collection-API-doesn-t-seem-to-be-working-tp4030182p4030398.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solr Collection API doesn't seem to be working
Posted by Yonik Seeley <yo...@lucidworks.com>.
On Thu, Jan 3, 2013 at 8:46 AM, Per Steffensen <st...@designware.dk> wrote:
> There are defaults for both replicationFactor and maxShardsPerNode, so non
> of them HAS to be provided - default is 1 in both cases.
>
> int repFactor = msgStrToInt(message, REPLICATION_FACTOR, 1);
> int maxShardsPerNode = msgStrToInt(message, MAX_SHARDS_PER_NODE, 1);
>
> Remember than replicationFactor decides how many "instances" of you shard
> you will get, so a value of 1 does not provide you any replication.
>
>
> On 1/3/13 3:46 AM, Yonik Seeley wrote:
>>
>> On Wed, Jan 2, 2013 at 9:21 PM, davers <db...@improvementdirect.com>
>> wrote:
>>>
>>> So by providing the correct replicationFactor parameter for the number of
>>> servers has fixed my issue.
>>>
>>> So can you not provide a higher replicationFactor than you have
>>> live_nodes?
>
> Yes, but you will end up with multiple replica of the same shard running on
> the same node. It is kinda pointless (IMHO), but might be ok if you later
> want to "move" one of the replica to a "new" node. I would prefer to not
> allow creating more replica than you have nodes (because it is kinda
> pointless) and then just copy data when you, in the future, create a new
> replica of a shard on a new node.
I agree - it's pointless to have two replicas of the same shard on a
single node. But I'm talking about having replicationFactor as a
target, so when you start up *new* nodes they will become a replica
for any shard where the number of replicas is currently less than the
replicationFactor.
Ideally, one would be able to create a new collection with no nodes
initially assigned to it if desired.
-Yonik
http://lucidworks.com
Re: Solr Collection API doesn't seem to be working
Posted by Per Steffensen <st...@designware.dk>.
There are defaults for both replicationFactor and maxShardsPerNode, so
non of them HAS to be provided - default is 1 in both cases.
int repFactor = msgStrToInt(message, REPLICATION_FACTOR, 1);
int maxShardsPerNode = msgStrToInt(message, MAX_SHARDS_PER_NODE, 1);
Remember than replicationFactor decides how many "instances" of you
shard you will get, so a value of 1 does not provide you any replication.
On 1/3/13 3:46 AM, Yonik Seeley wrote:
> On Wed, Jan 2, 2013 at 9:21 PM, davers <db...@improvementdirect.com> wrote:
>> So by providing the correct replicationFactor parameter for the number of
>> servers has fixed my issue.
>>
>> So can you not provide a higher replicationFactor than you have live_nodes?
Yes, but you will end up with multiple replica of the same shard running
on the same node. It is kinda pointless (IMHO), but might be ok if you
later want to "move" one of the replica to a "new" node. I would prefer
to not allow creating more replica than you have nodes (because it is
kinda pointless) and then just copy data when you, in the future, create
a new replica of a shard on a new node. There is not a big difference
between "moving a replica from one node to another" and "establishing a
new copy of the shard on a new node from an old node". But I guess this
has already been discussed, and current implementation is that it is
allowed to create more replica than you have nodes.
>> What if you want to add more replicants to the collection in the future?
> I advocated that replicationFactor / maxShardsPerNode only be a
> target, not a requirement in
> https://issues.apache.org/jira/browse/SOLR-4114
> and I hope that's in what will be 4.1, but I haven't verified.
>
> -Yonik
> http://lucidworks.com
Re: Solr Collection API doesn't seem to be working
Posted by Yonik Seeley <yo...@lucidworks.com>.
On Wed, Jan 2, 2013 at 9:21 PM, davers <db...@improvementdirect.com> wrote:
> So by providing the correct replicationFactor parameter for the number of
> servers has fixed my issue.
>
> So can you not provide a higher replicationFactor than you have live_nodes?
> What if you want to add more replicants to the collection in the future?
I advocated that replicationFactor / maxShardsPerNode only be a
target, not a requirement in
https://issues.apache.org/jira/browse/SOLR-4114
and I hope that's in what will be 4.1, but I haven't verified.
-Yonik
http://lucidworks.com
Re: Solr Collection API doesn't seem to be working
Posted by davers <db...@improvementdirect.com>.
So by providing the correct replicationFactor parameter for the number of
servers has fixed my issue.
So can you not provide a higher replicationFactor than you have live_nodes?
What if you want to add more replicants to the collection in the future?
Would you have to manually add them to the collection using the core admin
api?
--
View this message in context: http://lucene.472066.n3.nabble.com/Solr-Collection-API-doesn-t-seem-to-be-working-tp4030182p4030190.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solr Collection API doesn't seem to be working
Posted by davers <db...@improvementdirect.com>.
The strange thing is that it actually updated 4/6 of the solr.xml files
--
View this message in context: http://lucene.472066.n3.nabble.com/Solr-Collection-API-doesn-t-seem-to-be-working-tp4030182p4030189.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solr Collection API doesn't seem to be working
Posted by Per Steffensen <st...@designware.dk>.
On 1/3/13 3:05 AM, davers wrote:
> This is what I get from the leader overseer log:
>
> 2013-01-02 18:04:24,663 - INFO [ProcessThread:-1:PrepRequestProcessor@419]
> - Got user-level KeeperException when processing sessionid:0x23bfe1d4c280001
> type:create cxid:0x58 zxid:0xfffffffffffffffe txntype:unknown reqpath:n/a
> Error Path:/overseer Error:KeeperErrorCode = NodeExists for /overseer
Believe this is just a dump error because we try to create the /overseer
z-node without first checking if it is already there. Believe it doesnt
stop the job from being carried out. It is also only logged on INFO level.
Re: Solr Collection API doesn't seem to be working
Posted by davers <db...@improvementdirect.com>.
This is what I get from the leader overseer log:
2013-01-02 18:04:24,663 - INFO [ProcessThread:-1:PrepRequestProcessor@419]
- Got user-level KeeperException when processing sessionid:0x23bfe1d4c280001
type:create cxid:0x58 zxid:0xfffffffffffffffe txntype:unknown reqpath:n/a
Error Path:/overseer Error:KeeperErrorCode = NodeExists for /overseer
--
View this message in context: http://lucene.472066.n3.nabble.com/Solr-Collection-API-doesn-t-seem-to-be-working-tp4030182p4030188.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solr Collection API doesn't seem to be working
Posted by Mark Miller <ma...@gmail.com>.
Unfortunately, for 4.0, the collections API was pretty bare bones. You don't actually get back responses currently - you just pass off the create command to zk for the Overseer to pick up and execute.
So you actually have to check the logs of the Overseer to see what the problem may be. I'm working on making sure we address this for 4.1.
If you look at the admin UI, in the zk tree, you should be able to see what node is the overseer (look for its election node). The logs for that node should indicate the problem.
FYI, if I remember right, replication factor is not currently optional.
In the future, I'd like it so you can say like replicationFactor=max_int, and the overseer will periodically try to match that given the nodes it sees - but we don't have that yet.
When you add new nodes, to add them to a current collection you will either have to use CoreAdmin API or pre configure the cores in solr.xml. All you need is to specify a matching collection name for the new core.
- Mark
On Jan 2, 2013, at 7:58 PM, davers <db...@improvementdirect.com> wrote:
> Hello I have an external zookeeper ensemble and I have started 6 tomcat
> servers with solr running with the default solr.xml
>
> I have uploaded the config directory to zookeeper and linked the collection.
>
> http://d.pr/i/BkT
>
> My solr.xml is nearly the default with a minor adjustment for the jetty.port
> parameter:
>
> <cores adminPath="/admin/cores" defaultCoreName="collection1"
> host="${host:}" hostPort="${jetty.port:8080}" hostContext="${hostContext:}"
> zkClientTimeout="${zkClientTimeout:15000}">
> </cores>
>
> When I try to create the collection issuing the command:
> /solr/admin/collections?action=CREATE&name=productindex&numShards=3 (I leave
> replicationFactor out because I want my cloud to automatically re-size
> vertically as I add or remove replicant servers) I get output in the log:
>
> INFO: Creating Collection : numShards=3&name=productindex&action=CREATE
>
> But nothing happens. The solr.xml files are not updated. What am I doing
> wrong?
>
>
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Solr-Collection-API-doesn-t-seem-to-be-working-tp4030182.html
> Sent from the Solr - User mailing list archive at Nabble.com.