lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-5473) Make one state.json per collection
Date Sun, 27 Apr 2014 03:52:15 GMT

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

Mark Miller commented on SOLR-5473:
-----------------------------------

Thanks for chiming in.

bq. Do we intend to support both formats or do we intend to just migrate to the split approach?


We intend to migrate - I think supporting both would be a terrible long term burden. The way
the API's are currently designed, this was obviously not taken into account. It's designed
as if both things are first class.

bq. Are there any other things design / architecture wise that are controversial?

I think that mostly captures it.

bq. This seems like the biggest area of contention right now. 

Yup - this is what makes me insist on backing this out for now, rather than pushing forward.

bq.  The main issue is that the API changes still give the impression of two state tracking
formats, whereas we really only want one format.

That is part of it, but I also think the API's are somewhat poorly designed from an overall
architecture point - it feels to me like shortcuts around more difficult issues to make nice
and I think that is the wrong approach. I've got a variety of other issues, for instance,
I think it's an abomination the way ZkStateReader has been worked into ClusterState, and I
think the documentation is much too weak in areas that would call for it.

bq. The common ground here is that there should be no mention of "external" in any public
method or state format for that matter, right?

Right. We should have the new format, and the old one is around for back compat. There is
no reason to name things in this case. We are pushing forward the architecture, not adding
a feature.

bq. In other words, we're changing the internals of where state is kept, so why does that
have to impact the public API? I

That was also my thought - and I think it probably gets sticky due to supporting both formats
per collection, but I think we have to tackle those hard problems.

bq.  It seems to me that we need to be more diligent about API impacts of this change and
focus on not breaking the public view of cluster state as much as possible.

I agree - though it's too early to really hold to that. I do think we should be better about
labeling unstable API's though. We can't lock our selves in to early though - it would block
a lot of progress and we tend to be loose with Solr java API's - it's standard that you may
have to recompile. We should be sensible though. However, I think a user would have a very
terrible time migrating to the new API's. I'm hoping we can back them out before it becomes
too much harder to do so.

bq. To recap, I see a lot of common ground here and to move forward, we need to move this
out to a branch and off trunk where we'll focus on cleaning up the API impacts of this work,
support only the split format going forward (with a migration plan for existing installations).


+1

Thanks [~thelabdude], I am on the same page as you with all of that.

> Make one state.json per collection
> ----------------------------------
>
>                 Key: SOLR-5473
>                 URL: https://issues.apache.org/jira/browse/SOLR-5473
>             Project: Solr
>          Issue Type: Sub-task
>          Components: SolrCloud
>            Reporter: Noble Paul
>            Assignee: Noble Paul
>             Fix For: 5.0
>
>         Attachments: SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log
>
>
> As defined in the parent issue, store the states of each collection under /collections/collectionname/state.json
node



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message