> If I correctly understand what you're trying to do with the static
> collections, Solr cannot do it directly. If you have collection A in
> cluster 1, and collection A in cluster 2, they are entirely separate and
> cannot be managed as a single collection. Queries and updates sent to
> one clus
On 9/7/2016 5:15 PM, Eric Young wrote:
> Also, adding/removing ZooKeeper nodes can be problematic to manage
> over a large cluster (partly because 3.4.6 doesn't support live config
> changes b3.5.0+ does).
When an actual stable 3.5 release comes out, Solr can begin the process
of upgrading its ZK
> The zookeeper list isn't really the right place for most of this. The
> residents of this list will to have zero knowledge of how Solr uses
> zookeeper. I'm on both lists -- and I'm a lot more familiar with Solr
> than Zookeeper.
I think I see that now. I was under the impression that this mi
On 9/7/2016 4:04 PM, Shawn Heisey wrote:
> You *might* be able to just use the DELETE action on the Collections API
> to delete collections instead of manually editing clusterstate, but I'm
> not 100% positive about that.
On second thought, DON'T TRY THIS.
I wouldn't want to take the chance that
On 9/7/2016 3:19 PM, Eric Young wrote:
> I have a very large ZooKeeper cluster which manages config and replication
> for multiple SolrCloud clusters. I want to split the monolithic ZooKeeper
> cluster into smaller, more manageable clusters in a live migration (i.e.
> minimal or no downtime).
The
I have a very large ZooKeeper cluster which manages config and replication
for multiple SolrCloud clusters. I want to split the monolithic ZooKeeper
cluster into smaller, more manageable clusters in a live migration (i.e.
minimal or no downtime).
I have collections that can be updated dynamically
Yes, the sync operation really applies to the client’s entire view of ZooKeeper
state, not a specific path or sub-tree, so I would not expect to see any
significant difference in time for sync(/path1) vs. sync(/path2). The presence
of the path is only a client API convenience.
Expanding a bit
So path is completely for ZooKeeper client. It has nothing to do with server.
Therefore whether I execute sync /path1 or sync /path2, sync request will
complete in the same time. right?
-Arshad
-Original Message-
From: Flavio Junqueira [mailto:f...@apache.org]
Sent: 07 September 2016 16
The path parameter helps the app determine the path that the response is
referring to. A sync call is typically associated to a read request to a given
path, so the path in the sync call helps the application make the association
to that path.
-Flavio
> On 07 Sep 2016, at 11:35, Mohammad arsha
Hello Everyone
ZooKeeper sync API takes a path argument.
But it seems this path is no where used in the server code. Same path is
returned from the server to client again in SyncResponse.
Is the any other purpose of sync API path parameter.
Will there be any different impact for below sync command
11 matches
Mail list logo
