Recently I stored the configs of a new Solr service in a ZK ensemble andstruggled because I'd made an error (numShards incorrectly set) butfound I couldn't edit it without risking the other configs stored in theZK ensemble.

In general, do you recommend that a ZK ensemble is dedicated to a singleservice, or do you recommend an ensemble be used for many services? Ifthe latter, what's the recommended way of correcting individual serviceissues without affecting the other existing configs in the ensemble?

For production settings with well-behaved applications, sharing is not abad idea. I would definitely isolate development efforts onto a devinstance of ZK. And if you have trigger happy admins who think rebootingfixes all ills, I would consider separating apps.

How is it that you wound up with your problem of being unable to manipulateone thing without changing others?On Mon, Oct 28, 2013 at 7:20 AM, Hoggarth, Gil <[EMAIL PROTECTED]> wrote:

> Hi all,>>>> Recently I stored the configs of a new Solr service in a ZK ensemble and> struggled because I'd made an error (numShards incorrectly set) but> found I couldn't edit it without risking the other configs stored in the> ZK ensemble.>>>> In general, do you recommend that a ZK ensemble is dedicated to a single> service, or do you recommend an ensemble be used for many services? If> the latter, what's the recommended way of correcting individual service> issues without affecting the other existing configs in the ensemble?>>>> Thanks in advance, Gil>>>> Gil Hoggarth>> Web Archiving Technical Services Engineer>> The British Library, Boston Spa, West Yorkshire, LS23 7BQ>>

"being unable to manipulate" is more an issue of my skills rather than anything else. Up to now we'd always used dedicated ZK ensembles, but it seemed sensible to reuse the formal, production ensemble (which previously only managed one service). Then I realised the numShards mistake had been made, and I didn't like the look of using zkCli to fix it as I'd never used it before (never had a reason to before either).

I'm assuming the way you'd 'manipulate one thing without changing others' is via zkCli, yes? Any suggestions of good tutorials to its use? I can set up a dev scenario so I can test and learn, but I'm unaware of how to use it. (Or would you recommend something else? If so, what?)

For production settings with well-behaved applications, sharing is not a bad idea. I would definitely isolate development efforts onto a dev instance of ZK. And if you have trigger happy admins who think rebooting fixes all ills, I would consider separating apps.

How is it that you wound up with your problem of being unable to manipulate one thing without changing others?On Mon, Oct 28, 2013 at 7:20 AM, Hoggarth, Gil <[EMAIL PROTECTED]> wrote:

> Hi all,>>>> Recently I stored the configs of a new Solr service in a ZK ensemble > and struggled because I'd made an error (numShards incorrectly set) > but found I couldn't edit it without risking the other configs stored > in the ZK ensemble.>>>> In general, do you recommend that a ZK ensemble is dedicated to a > single service, or do you recommend an ensemble be used for many > services? If the latter, what's the recommended way of correcting > individual service issues without affecting the other existing configs in the ensemble?>>>> Thanks in advance, Gil>>>> Gil Hoggarth>> Web Archiving Technical Services Engineer>> The British Library, Boston Spa, West Yorkshire, LS23 7BQ>>

NEW: Monitor These Apps!

All projects made searchable here are trademarks of the Apache Software Foundation.
Service operated by Sematext