Hi,

I have recently started experimenting with solrCloud. I want to use it for
below mentioned requirements:

 - create one collection per client
 - create several shards per collection (say 1 shard for each day of month)
 - all of the collection would follow the same schema.
 - may need to add more machines to the cluster to index faster or provide
quick turnaround for queries.  (think this is possible with zookeeper)
 - programmatic access ( and create, if possible) shard names and add data
to that shard.

I was looking into tutorial online and could get a sense that one needs to
create collections and shards manually and there is no programmatic way to
create them dynamically from code, say, using solrj.

I now know that adding shards to an already running cluster is not possible.
( http://wiki.apache.org/solr/SolrCloud Re-sizing your cluster )

Is there something wrong in the way i want to organise my indexes? Am i
missing something very obvious?

Thanks!
Ravi

--
View this message in context: http://lucene.472066.n3.nabble.com/SolrCloud-Programmatically-create-multiple-collections-tp3916927p3916927.html
Sent from the Solr - User mailing list archive at Nabble.com.

On Apr 17, 2012, at 7:07 AM, ravi wrote:

> Hi,
>
> I have recently started experimenting with solrCloud. I want to use it for
> below mentioned requirements:
>
> - create one collection per client
> - create several shards per collection (say 1 shard for each day of month)
> - all of the collection would follow the same schema.
> - may need to add more machines to the cluster to index faster or provide
> quick turnaround for queries.  (think this is possible with zookeeper)
> - programmatic access ( and create, if possible) shard names and add data
> to that shard.
>
> I was looking into tutorial online and could get a sense that one needs to
> create collections and shards manually and there is no programmatic way to
> create them dynamically from code, say, using solrj.

You can - see http://wiki.apache.org/solr/SolrCloud#Creating_cores_via_CoreAdmin
http://wiki.apache.org/solr/CoreAdmin#CoreAdminHandler
>
> I now know that adding shards to an already running cluster is not possible.
> ( http://wiki.apache.org/solr/SolrCloud Re-sizing your cluster )
>
> Is there something wrong in the way i want to organise my indexes? Am i
> missing something very obvious?
>
> Thanks!
> Ravi
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/SolrCloud-Programmatically-create-multiple-collections-tp3916927p3916927.html
> Sent from the Solr - User mailing list archive at Nabble.com.

- Mark Miller
lucidimagination.com

Hi Mark,

Thanks for your response. I did manage to one example running with 2 solr
instance running and i checked that shards are created and replicated
properly.

The problem that i am now facing is zookeeper's clusterstate. If i kill one
solr instance (which may hold one or more cores) by pressing CTRL+C,
zookeeper never show's that instance as *down* and keeps on sowing that
instance as *active*.

The other instance, becomes the leader for some of the shards that were
present in the first instance though. This suggests that zookeeper gets to
know that one instance went down but for some strange reason its not
updating clusterstate.json thing.

Has this already been reported? or there is something that i am missing?

Thanks!
Ravi

--
View this message in context: http://lucene.472066.n3.nabble.com/SolrCloud-Programmatically-create-multiple-collections-tp3916927p3924698.html
Sent from the Solr - User mailing list archive at Nabble.com.

Hey Ravi - yeah, I know this is kind of confusing. The issue is that the true state is actually the advertised state in clusterstate.json *and* whether or not a node is listed on live_nodes.

The reason this is the case is that if a node just dies, it may have left its current in *any* state. The way we know that its no longer connected to zookeeper is looking at live_nodes - which are ephemeral and will go away if a node goes away.

I've discussed with Sami in the past the idea of the Overseer perhaps taking a look when a node goes down and updating it's state in clusterstate.json - not sure if there are some gotchyas with that or not though. Right now only a node updates its own state and the Overseer reads those states and compiles them into clusterstate.json.

In any case, it's not a bug, its expected - but at the same time it might be nice if things worked a little nicer if possible.

On Apr 19, 2012, at 7:11 PM, ravi wrote:

> Hi Mark,
>
> Thanks for your response. I did manage to one example running with 2 solr
> instance running and i checked that shards are created and replicated
> properly.
>
> The problem that i am now facing is zookeeper's clusterstate. If i kill one
> solr instance (which may hold one or more cores) by pressing CTRL+C,
> zookeeper never show's that instance as *down* and keeps on sowing that
> instance as *active*.
>
> The other instance, becomes the leader for some of the shards that were
> present in the first instance though. This suggests that zookeeper gets to
> know that one instance went down but for some strange reason its not
> updating clusterstate.json thing.
>
> Has this already been reported? or there is something that i am missing?
>
> Thanks!
> Ravi
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/SolrCloud-Programmatically-create-multiple-collections-tp3916927p3924698.html
> Sent from the Solr - User mailing list archive at Nabble.com.

- Mark Miller
lucidimagination.com

Hey Mark, Thanks again for your reply.

/*"The way we know that its no longer connected to zookeeper is looking at
live_nodes - which are ephemeral and will go away if a node goes away"*/

 i am not too sure if this is really the case. As far as i remember, even
after a node was dead, live_nodes still reported that node as active /but/
the leader was changed to the one that was /really/ alive.

I had a look in the Overseer's code and it seems its looping on FIFO queue
and wait for new state update requests. So if a node was killed, it would
never be sending a state update request and i guess that's why the state is
out of sync.

If we can set up a wait time for each known node and then declare a node as
INACTIVE if overseer does not hear from that node within the wait time.
Something similar to heartbeats in several other systems.

--
View this message in context: http://lucene.472066.n3.nabble.com/SolrCloud-Programmatically-create-multiple-collections-tp3916927p3944327.html
Sent from the Solr - User mailing list archive at Nabble.com.

On Apr 27, 2012, at 9:54 AM, ravi wrote:

> Hey Mark, Thanks again for your reply.
>
> /*"The way we know that its no longer connected to zookeeper is looking at
> live_nodes - which are ephemeral and will go away if a node goes away"*/
>
> i am not too sure if this is really the case. As far as i remember, even
> after a node was dead, live_nodes still reported that node as active /but/
> the leader was changed to the one that was /really/ alive.

Should not be the case.

>
> I had a look in the Overseer's code and it seems its looping on FIFO queue
> and wait for new state update requests. So if a node was killed, it would
> never be sending a state update request and i guess that's why the state is
> out of sync.
>
> If we can set up a wait time for each known node and then declare a node as
> INACTIVE if overseer does not hear from that node within the wait time.
> Something similar to heartbeats in several other systems.

The /live_nodes stuff does use a heartbeat. That's why we use it as we do in combination with the state.

>
>
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/SolrCloud-Programmatically-create-multiple-collections-tp3916927p3944327.html
> Sent from the Solr - User mailing list archive at Nabble.com.

- Mark Miller
lucidimagination.com