[jira] [Resolved] (SOLR-12013) collections API CUSTERSTATUS command fails when configset missing
[
https://issues.apache.org/jira/browse/SOLR-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-12013.
---
Resolution: Fixed
Fixed up a missed failure path.
> collections API CUSTERSTATUS command fails when configset missing
> -
>
> Key: SOLR-12013
> URL: https://issues.apache.org/jira/browse/SOLR-12013
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 6.0, 7.0, 7.1, 7.2
>Reporter: Ben DeMott
>Assignee: Erick Erickson
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-12013.supplemental.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CLUSTERSTATUS command can be given independent of a given collection.
> http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
> I would expect that you can still inspect the status of a cluster even if a
> single collection has failed, or is missing its configuration.
> *Expected behavior*: all healthy collections status is returned, unhealthy
> collections are either reported with a stacktrace in the response, reported
> in a failure state, or are not present from the response.
> For example, CLUSTERSTATUS fails when a collection config-set is missing from
> ZooKeeper with:
> {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
> exist in ZooKeeper: config-set-name*}}
> {{ *at
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
> {{ at
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
> {{ at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
> {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}}
> {{ at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}}
> {{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}}
> {{ at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)}}
> {{ at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)}}
> {{ at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)}}
> {{ at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannel
[jira] [Commented] (SOLR-12013) collections API CUSTERSTATUS command fails when configset missing
[
https://issues.apache.org/jira/browse/SOLR-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16863520#comment-16863520
]
ASF subversion and git services commented on SOLR-12013:
Commit 47e67be775659d5e58d750edbde2e7fa0a90cd2f in lucene-solr's branch
refs/heads/branch_8x from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=47e67be ]
SOLR-12013: collections API CUSTERSTATUS command fails when configset missing
(cherry picked from commit 81e8b385a4cac5268c2cd920240d0e717f55713a)
> collections API CUSTERSTATUS command fails when configset missing
> -
>
> Key: SOLR-12013
> URL: https://issues.apache.org/jira/browse/SOLR-12013
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 6.0, 7.0, 7.1, 7.2
>Reporter: Ben DeMott
>Assignee: Erick Erickson
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-12013.supplemental.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CLUSTERSTATUS command can be given independent of a given collection.
> http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
> I would expect that you can still inspect the status of a cluster even if a
> single collection has failed, or is missing its configuration.
> *Expected behavior*: all healthy collections status is returned, unhealthy
> collections are either reported with a stacktrace in the response, reported
> in a failure state, or are not present from the response.
> For example, CLUSTERSTATUS fails when a collection config-set is missing from
> ZooKeeper with:
> {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
> exist in ZooKeeper: config-set-name*}}
> {{ *at
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
> {{ at
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
> {{ at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
> {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}}
> {{ at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}}
> {{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}}
&
[jira] [Updated] (SOLR-12013) collections API CUSTERSTATUS command fails when configset missing
[
https://issues.apache.org/jira/browse/SOLR-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-12013:
--
Attachment: SOLR-12013.supplemental.patch
Status: Reopened (was: Reopened)
covered a case I missed earlier
> collections API CUSTERSTATUS command fails when configset missing
> -
>
> Key: SOLR-12013
> URL: https://issues.apache.org/jira/browse/SOLR-12013
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 7.2, 7.1, 7.0, 6.0
>Reporter: Ben DeMott
>Assignee: Erick Erickson
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-12013.supplemental.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CLUSTERSTATUS command can be given independent of a given collection.
> http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
> I would expect that you can still inspect the status of a cluster even if a
> single collection has failed, or is missing its configuration.
> *Expected behavior*: all healthy collections status is returned, unhealthy
> collections are either reported with a stacktrace in the response, reported
> in a failure state, or are not present from the response.
> For example, CLUSTERSTATUS fails when a collection config-set is missing from
> ZooKeeper with:
> {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
> exist in ZooKeeper: config-set-name*}}
> {{ *at
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
> {{ at
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
> {{ at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
> {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}}
> {{ at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}}
> {{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}}
> {{ at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)}}
> {{ at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)}}
> {{ at org.eclipse.jetty.io.Fill
[jira] [Commented] (SOLR-12013) collections API CUSTERSTATUS command fails when configset missing
[
https://issues.apache.org/jira/browse/SOLR-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16863516#comment-16863516
]
ASF subversion and git services commented on SOLR-12013:
Commit 81e8b385a4cac5268c2cd920240d0e717f55713a in lucene-solr's branch
refs/heads/master from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=81e8b38 ]
SOLR-12013: collections API CUSTERSTATUS command fails when configset missing
> collections API CUSTERSTATUS command fails when configset missing
> -
>
> Key: SOLR-12013
> URL: https://issues.apache.org/jira/browse/SOLR-12013
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 6.0, 7.0, 7.1, 7.2
>Reporter: Ben DeMott
>Assignee: Erick Erickson
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CLUSTERSTATUS command can be given independent of a given collection.
> http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
> I would expect that you can still inspect the status of a cluster even if a
> single collection has failed, or is missing its configuration.
> *Expected behavior*: all healthy collections status is returned, unhealthy
> collections are either reported with a stacktrace in the response, reported
> in a failure state, or are not present from the response.
> For example, CLUSTERSTATUS fails when a collection config-set is missing from
> ZooKeeper with:
> {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
> exist in ZooKeeper: config-set-name*}}
> {{ *at
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
> {{ at
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
> {{ at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
> {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}}
> {{ at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}}
> {{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}}
> {{ at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)}}
> {{ at
>
[jira] [Reopened] (SOLR-12013) collections API CUSTERSTATUS command fails when configset missing
[
https://issues.apache.org/jira/browse/SOLR-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reopened SOLR-12013:
---
Looking more carefully at the code, the current patch fixes the specific
situation where the configset is missing. It does _not_ fix the issue where,
for some reason, the entire collection is not found. We need to throw the
NoNodeException in that case too.
> collections API CUSTERSTATUS command fails when configset missing
> -
>
> Key: SOLR-12013
> URL: https://issues.apache.org/jira/browse/SOLR-12013
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 6.0, 7.0, 7.1, 7.2
>Reporter: Ben DeMott
>Assignee: Erick Erickson
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CLUSTERSTATUS command can be given independent of a given collection.
> http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
> I would expect that you can still inspect the status of a cluster even if a
> single collection has failed, or is missing its configuration.
> *Expected behavior*: all healthy collections status is returned, unhealthy
> collections are either reported with a stacktrace in the response, reported
> in a failure state, or are not present from the response.
> For example, CLUSTERSTATUS fails when a collection config-set is missing from
> ZooKeeper with:
> {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
> exist in ZooKeeper: config-set-name*}}
> {{ *at
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
> {{ at
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
> {{ at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
> {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}}
> {{ at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}}
> {{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}}
> {{ at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)}}
> {{ at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)}}
> {{ at org.eclipse.jett
[jira] [Resolved] (SOLR-13235) Split Ref Guide Collections API page into several sub-pages
[ https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-13235. -- Resolution: Fixed > Split Ref Guide Collections API page into several sub-pages > --- > > Key: SOLR-13235 > URL: https://issues.apache.org/jira/browse/SOLR-13235 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The Collections API page in the Ref Guide has become the de-facto place where > information about how to work with Solr collections is stored, but it is so > huge with API examples that information gets lost. > I did some work a couple months ago to split this up, and came up with this > approach to splitting up the content: > * *Cluster and Node Management*: Define properties for the entire cluster; > check the status of a cluster; remove replicas from a node; utilize a newly > added node; add or remove roles for a node. > * *Collection Management*: Create, list, reload and delete collections; set > collection properties; migrate documents to another collection; rebalance > leaders; backup and restore collections. > * *Collection Aliasing*: Create, list or delete collection aliases; set alias > properties. > * *Shard Management*: Create and delete a shard; split a shard into two or > more additional shards; force a shard leader. > * *Replica Management*: Add or delete a replica; set replica properties; move > a replica to a different node. > My existing local WIP leaves info on Async commands on the main > collections-api.adoc page, but creates new pages for each of the bullets > mentioned above, and moves the related API calls to those pages. Each topic > will be smaller and easier for us to manage on an ongoing basis. > Since I did the work a while ago, I need to bring it up to date with master, > so a patch & a branch with this work will be forthcoming shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13235) Split Ref Guide Collections API page into several sub-pages
[ https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862577#comment-16862577 ] ASF subversion and git services commented on SOLR-13235: Commit 8c5dd4a98b9bc85e4245886ccd40f95af8b5956e in lucene-solr's branch refs/heads/branch_8x from Cassandra Targett [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8c5dd4a ] SOLR-13235: update doc links in apispec files to new pages > Split Ref Guide Collections API page into several sub-pages > --- > > Key: SOLR-13235 > URL: https://issues.apache.org/jira/browse/SOLR-13235 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The Collections API page in the Ref Guide has become the de-facto place where > information about how to work with Solr collections is stored, but it is so > huge with API examples that information gets lost. > I did some work a couple months ago to split this up, and came up with this > approach to splitting up the content: > * *Cluster and Node Management*: Define properties for the entire cluster; > check the status of a cluster; remove replicas from a node; utilize a newly > added node; add or remove roles for a node. > * *Collection Management*: Create, list, reload and delete collections; set > collection properties; migrate documents to another collection; rebalance > leaders; backup and restore collections. > * *Collection Aliasing*: Create, list or delete collection aliases; set alias > properties. > * *Shard Management*: Create and delete a shard; split a shard into two or > more additional shards; force a shard leader. > * *Replica Management*: Add or delete a replica; set replica properties; move > a replica to a different node. > My existing local WIP leaves info on Async commands on the main > collections-api.adoc page, but creates new pages for each of the bullets > mentioned above, and moves the related API calls to those pages. Each topic > will be smaller and easier for us to manage on an ongoing basis. > Since I did the work a while ago, I need to bring it up to date with master, > so a patch & a branch with this work will be forthcoming shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13235) Split Ref Guide Collections API page into several sub-pages
[ https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862578#comment-16862578 ] ASF subversion and git services commented on SOLR-13235: Commit e139c86769b34c5e6658900e951c4b41117c3cbd in lucene-solr's branch refs/heads/branch_8x from Cassandra Targett [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e139c86 ] SOLR-13235: Split Collections API Ref Guide page into several smaller child pages > Split Ref Guide Collections API page into several sub-pages > --- > > Key: SOLR-13235 > URL: https://issues.apache.org/jira/browse/SOLR-13235 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The Collections API page in the Ref Guide has become the de-facto place where > information about how to work with Solr collections is stored, but it is so > huge with API examples that information gets lost. > I did some work a couple months ago to split this up, and came up with this > approach to splitting up the content: > * *Cluster and Node Management*: Define properties for the entire cluster; > check the status of a cluster; remove replicas from a node; utilize a newly > added node; add or remove roles for a node. > * *Collection Management*: Create, list, reload and delete collections; set > collection properties; migrate documents to another collection; rebalance > leaders; backup and restore collections. > * *Collection Aliasing*: Create, list or delete collection aliases; set alias > properties. > * *Shard Management*: Create and delete a shard; split a shard into two or > more additional shards; force a shard leader. > * *Replica Management*: Add or delete a replica; set replica properties; move > a replica to a different node. > My existing local WIP leaves info on Async commands on the main > collections-api.adoc page, but creates new pages for each of the bullets > mentioned above, and moves the related API calls to those pages. Each topic > will be smaller and easier for us to manage on an ongoing basis. > Since I did the work a while ago, I need to bring it up to date with master, > so a patch & a branch with this work will be forthcoming shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13235) Split Ref Guide Collections API page into several sub-pages
[ https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862576#comment-16862576 ] ASF subversion and git services commented on SOLR-13235: Commit 65b539104122d487c0cbed6ef38c3fd962b8f9e5 in lucene-solr's branch refs/heads/master from Cassandra Targett [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=65b5391 ] SOLR-13235: update doc links in apispec files to new pages > Split Ref Guide Collections API page into several sub-pages > --- > > Key: SOLR-13235 > URL: https://issues.apache.org/jira/browse/SOLR-13235 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The Collections API page in the Ref Guide has become the de-facto place where > information about how to work with Solr collections is stored, but it is so > huge with API examples that information gets lost. > I did some work a couple months ago to split this up, and came up with this > approach to splitting up the content: > * *Cluster and Node Management*: Define properties for the entire cluster; > check the status of a cluster; remove replicas from a node; utilize a newly > added node; add or remove roles for a node. > * *Collection Management*: Create, list, reload and delete collections; set > collection properties; migrate documents to another collection; rebalance > leaders; backup and restore collections. > * *Collection Aliasing*: Create, list or delete collection aliases; set alias > properties. > * *Shard Management*: Create and delete a shard; split a shard into two or > more additional shards; force a shard leader. > * *Replica Management*: Add or delete a replica; set replica properties; move > a replica to a different node. > My existing local WIP leaves info on Async commands on the main > collections-api.adoc page, but creates new pages for each of the bullets > mentioned above, and moves the related API calls to those pages. Each topic > will be smaller and easier for us to manage on an ongoing basis. > Since I did the work a while ago, I need to bring it up to date with master, > so a patch & a branch with this work will be forthcoming shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13235) Split Ref Guide Collections API page into several sub-pages
[ https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862575#comment-16862575 ] ASF subversion and git services commented on SOLR-13235: Commit c8b38d8969a14e2139ee79e2d9bde55d0850abed in lucene-solr's branch refs/heads/master from Cassandra Targett [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c8b38d8 ] SOLR-13235: Split Collections API Ref Guide page into several smaller child pages > Split Ref Guide Collections API page into several sub-pages > --- > > Key: SOLR-13235 > URL: https://issues.apache.org/jira/browse/SOLR-13235 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The Collections API page in the Ref Guide has become the de-facto place where > information about how to work with Solr collections is stored, but it is so > huge with API examples that information gets lost. > I did some work a couple months ago to split this up, and came up with this > approach to splitting up the content: > * *Cluster and Node Management*: Define properties for the entire cluster; > check the status of a cluster; remove replicas from a node; utilize a newly > added node; add or remove roles for a node. > * *Collection Management*: Create, list, reload and delete collections; set > collection properties; migrate documents to another collection; rebalance > leaders; backup and restore collections. > * *Collection Aliasing*: Create, list or delete collection aliases; set alias > properties. > * *Shard Management*: Create and delete a shard; split a shard into two or > more additional shards; force a shard leader. > * *Replica Management*: Add or delete a replica; set replica properties; move > a replica to a different node. > My existing local WIP leaves info on Async commands on the main > collections-api.adoc page, but creates new pages for each of the bullets > mentioned above, and moves the related API calls to those pages. Each topic > will be smaller and easier for us to manage on an ongoing basis. > Since I did the work a while ago, I need to bring it up to date with master, > so a patch & a branch with this work will be forthcoming shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13235) Split Ref Guide Collections API page into several sub-pages
[
https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862206#comment-16862206
]
Cassandra Targett commented on SOLR-13235:
--
I closed the PR as I didn't get it done in the timeline I hoped and now there
are all sort of merge conflicts it would take forever to straighten out. I'll
make the same changes as that PR but not via the branch/PR.
It occurred to me yesterday splitting up the collections-api page also requires
updating the doc links in all the API specs in
{{solr/solrj/src/java/resources/apispec}}, so I will include that also.
> Split Ref Guide Collections API page into several sub-pages
> ---
>
> Key: SOLR-13235
> URL: https://issues.apache.org/jira/browse/SOLR-13235
> Project: Solr
> Issue Type: Improvement
> Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The Collections API page in the Ref Guide has become the de-facto place where
> information about how to work with Solr collections is stored, but it is so
> huge with API examples that information gets lost.
> I did some work a couple months ago to split this up, and came up with this
> approach to splitting up the content:
> * *Cluster and Node Management*: Define properties for the entire cluster;
> check the status of a cluster; remove replicas from a node; utilize a newly
> added node; add or remove roles for a node.
> * *Collection Management*: Create, list, reload and delete collections; set
> collection properties; migrate documents to another collection; rebalance
> leaders; backup and restore collections.
> * *Collection Aliasing*: Create, list or delete collection aliases; set alias
> properties.
> * *Shard Management*: Create and delete a shard; split a shard into two or
> more additional shards; force a shard leader.
> * *Replica Management*: Add or delete a replica; set replica properties; move
> a replica to a different node.
> My existing local WIP leaves info on Async commands on the main
> collections-api.adoc page, but creates new pages for each of the bullets
> mentioned above, and moves the related API calls to those pages. Each topic
> will be smaller and easier for us to manage on an ongoing basis.
> Since I did the work a while ago, I need to bring it up to date with master,
> so a patch & a branch with this work will be forthcoming shortly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] ctargett closed pull request #575: SOLR-13235: Split Collections API Ref Guide page
ctargett closed pull request #575: SOLR-13235: Split Collections API Ref Guide page URL: https://github.com/apache/lucene-solr/pull/575 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] ctargett commented on issue #575: SOLR-13235: Split Collections API Ref Guide page
ctargett commented on issue #575: SOLR-13235: Split Collections API Ref Guide page URL: https://github.com/apache/lucene-solr/pull/575#issuecomment-501317655 This branch has significantly diverged from master, and I spent a little bit of time trying to straighten it out but it would take more time than I think it's worth. Since this was reviewed and got a +1, instead of trying to update the branch and update the PR for another round, I'm going to close this PR and just make my changes locally to master and branch_8x and push them up that way. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12013) collections API CUSTERSTATUS command fails when configset missing
[
https://issues.apache.org/jira/browse/SOLR-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-12013.
---
Resolution: Fixed
Fix Version/s: 8.2
master (9.0)
> collections API CUSTERSTATUS command fails when configset missing
> -
>
> Key: SOLR-12013
> URL: https://issues.apache.org/jira/browse/SOLR-12013
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 6.0, 7.0, 7.1, 7.2
>Reporter: Ben DeMott
>Assignee: Erick Erickson
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CLUSTERSTATUS command can be given independent of a given collection.
> http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
> I would expect that you can still inspect the status of a cluster even if a
> single collection has failed, or is missing its configuration.
> *Expected behavior*: all healthy collections status is returned, unhealthy
> collections are either reported with a stacktrace in the response, reported
> in a failure state, or are not present from the response.
> For example, CLUSTERSTATUS fails when a collection config-set is missing from
> ZooKeeper with:
> {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
> exist in ZooKeeper: config-set-name*}}
> {{ *at
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
> {{ at
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
> {{ at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
> {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}}
> {{ at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}}
> {{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}}
> {{ at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)}}
> {{ at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)}}
> {{ at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)}}
> {{ at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoi
[GitHub] [lucene-solr] ErickErickson closed pull request #713: SOLR-12013: collections API CUSTERSTATUS command fails when configset…
ErickErickson closed pull request #713: SOLR-12013: collections API CUSTERSTATUS command fails when configset… URL: https://github.com/apache/lucene-solr/pull/713 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12013) collections API CUSTERSTATUS command fails when configset missing
[
https://issues.apache.org/jira/browse/SOLR-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861625#comment-16861625
]
ASF subversion and git services commented on SOLR-12013:
Commit cd809ef7673c6f28306061e9349d34243715c5e4 in lucene-solr's branch
refs/heads/branch_8x from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cd809ef ]
SOLR-12013: collections API CUSTERSTATUS command fails when configset missing
> collections API CUSTERSTATUS command fails when configset missing
> -
>
> Key: SOLR-12013
> URL: https://issues.apache.org/jira/browse/SOLR-12013
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 6.0, 7.0, 7.1, 7.2
>Reporter: Ben DeMott
>Assignee: Erick Erickson
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CLUSTERSTATUS command can be given independent of a given collection.
> http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
> I would expect that you can still inspect the status of a cluster even if a
> single collection has failed, or is missing its configuration.
> *Expected behavior*: all healthy collections status is returned, unhealthy
> collections are either reported with a stacktrace in the response, reported
> in a failure state, or are not present from the response.
> For example, CLUSTERSTATUS fails when a collection config-set is missing from
> ZooKeeper with:
> {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
> exist in ZooKeeper: config-set-name*}}
> {{ *at
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
> {{ at
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
> {{ at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
> {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}}
> {{ at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}}
> {{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}}
> {{ at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)}}
> {{ at
> org.e
[jira] [Commented] (SOLR-12013) collections API CUSTERSTATUS command fails when configset missing
[
https://issues.apache.org/jira/browse/SOLR-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861624#comment-16861624
]
ASF subversion and git services commented on SOLR-12013:
Commit bfb5b41144f13e4d10d64a9c1bd53f3f498d7e4e in lucene-solr's branch
refs/heads/master from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bfb5b41 ]
SOLR-12013: collections API CUSTERSTATUS command fails when configset missing
> collections API CUSTERSTATUS command fails when configset missing
> -
>
> Key: SOLR-12013
> URL: https://issues.apache.org/jira/browse/SOLR-12013
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 6.0, 7.0, 7.1, 7.2
>Reporter: Ben DeMott
>Assignee: Erick Erickson
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CLUSTERSTATUS command can be given independent of a given collection.
> http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
> I would expect that you can still inspect the status of a cluster even if a
> single collection has failed, or is missing its configuration.
> *Expected behavior*: all healthy collections status is returned, unhealthy
> collections are either reported with a stacktrace in the response, reported
> in a failure state, or are not present from the response.
> For example, CLUSTERSTATUS fails when a collection config-set is missing from
> ZooKeeper with:
> {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
> exist in ZooKeeper: config-set-name*}}
> {{ *at
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
> {{ at
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
> {{ at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
> {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}}
> {{ at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}}
> {{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}}
> {{ at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)}}
> {{ at
> org.e
[GitHub] [lucene-solr] ErickErickson commented on a change in pull request #713: SOLR-12013: collections API CUSTERSTATUS command fails when configset…
ErickErickson commented on a change in pull request #713: SOLR-12013:
collections API CUSTERSTATUS command fails when configset…
URL: https://github.com/apache/lucene-solr/pull/713#discussion_r292630719
##
File path: solr/core/src/test/org/apache/solr/cloud/SolrCLIZkUtilsTest.java
##
@@ -690,28 +690,11 @@ public void testRm() throws Exception {
"-zkHost", zkAddr,
};
-copyConfigUp(configSet, "cloud-subdirs", "rm3");
+AbstractDistribZkTestBase.copyConfigUp(configSet, "cloud-subdirs", "rm3",
zkAddr);
res =
tool.runTool(SolrCLI.processCommandLineArgs(SolrCLI.joinCommonAndToolOptions(tool.getOptions()),
args));
assertFalse("Should fail when trying to remove /.", res == 0);
}
- // We can use this for testing since the goal is to move "some stuff" up to
ZK.
Review comment:
Refactored this out into a base class
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson opened a new pull request #713: SOLR-12013: collections API CUSTERSTATUS command fails when configset…
ErickErickson opened a new pull request #713: SOLR-12013: collections API CUSTERSTATUS command fails when configset… URL: https://github.com/apache/lucene-solr/pull/713 Trying to get all modern and use Git, so bear with me. This fixes the problem, but by throwing a NoNodeException it affected AddReplicaCmd, CloudConfigSetService and OverseerConfigSetMessageHandler, any extra eyes on those changes appreciated. precommit and all tests pass if I haven't messed up the whole PR thing. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12013) collections API CUSTERSTATUS command fails when configset missing
[
https://issues.apache.org/jira/browse/SOLR-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-12013:
--
Summary: collections API CUSTERSTATUS command fails when configset missing
(was: collections API CUSTERSTATUS command fails when collections have errors)
> collections API CUSTERSTATUS command fails when configset missing
> -
>
> Key: SOLR-12013
> URL: https://issues.apache.org/jira/browse/SOLR-12013
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 6.0, 7.0, 7.1, 7.2
>Reporter: Ben DeMott
>Assignee: Erick Erickson
>Priority: Major
>
> CLUSTERSTATUS command can be given independent of a given collection.
> http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
> I would expect that you can still inspect the status of a cluster even if a
> single collection has failed, or is missing its configuration.
> *Expected behavior*: all healthy collections status is returned, unhealthy
> collections are either reported with a stacktrace in the response, reported
> in a failure state, or are not present from the response.
> For example, CLUSTERSTATUS fails when a collection config-set is missing from
> ZooKeeper with:
> {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
> exist in ZooKeeper: config-set-name*}}
> {{ *at
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
> {{ at
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
> {{ at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
> {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}}
> {{ at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}}
> {{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}}
> {{ at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)}}
> {{ at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)}}
> {{ at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)}}
> {{ at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)}
[jira] [Commented] (SOLR-12013) collections API CUSTERSTATUS command fails when collections have errors
[
https://issues.apache.org/jira/browse/SOLR-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860497#comment-16860497
]
Erick Erickson commented on SOLR-12013:
---
*ZkStateReader.readConfigName* throws a really bogus error, which is causing
*ClusterStatus.getClusterStatus* to throw an error rather than skip a
collection that doesn't have an associated configset.
ZkStateReader.readConfigName has this code:
{code:java}
String configPath = CONFIGS_ZKNODE + "/" + configName;
if (!zkClient.exists(configPath, true)) {
log.error("Specified config=[{}] does not exist in ZooKeeper at
location=[{}]", configName, configPath);
throw new ZooKeeperException(ErrorCode.SERVER_ERROR, "Specified
config does not exist in ZooKeeper: " + configName);
} else {
log.debug("path=[{}] [{}]=[{}] specified config exists in ZooKeeper",
configPath, CONFIGNAME_PROP, configName);
}
{code}
But Clusterstatus.GetClusterStatus has this code:
{code:java}
try {
String configName = zkStateReader.readConfigName(name);
.
.
.
} catch (SolrException e) {
if (e.getCause() instanceof KeeperException.NoNodeException) {
// skip this collection because the collection's znode has been
deleted
// which can happen during aggressive collection removal, see
SOLR-10720
} else throw e;
}
{code}
which can never be true since ZooKeeperException has nothing to do with
NoNodeException. It makes no sense to me that when a znode is not present, we
throw any kind of SolrException (the superclass of ZookeeperException) so I'll
change *zkStateReader.readConfigName* to throw a NoNodeException
I'll run the full test suite and correct any tests that rely on this behavior.
It's vaguely possible this is responsible for some test failures given this
comment:
// skip this collection because the configset's znode has been deleted
// which can happen during aggressive collection removal, see SOLR-10720
Throwing an NoNodeException does propagate to some other code, we'll see if it
breaks other tests.
> collections API CUSTERSTATUS command fails when collections have errors
> ---
>
> Key: SOLR-12013
> URL: https://issues.apache.org/jira/browse/SOLR-12013
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 6.0, 7.0, 7.1, 7.2
>Reporter: Ben DeMott
>Priority: Major
>
> CLUSTERSTATUS command can be given independent of a given collection.
> http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
> I would expect that you can still inspect the status of a cluster even if a
> single collection has failed, or is missing its configuration.
> *Expected behavior*: all healthy collections status is returned, unhealthy
> collections are either reported with a stacktrace in the response, reported
> in a failure state, or are not present from the response.
> For example, CLUSTERSTATUS fails when a collection config-set is missing from
> ZooKeeper with:
> {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
> exist in ZooKeeper: config-set-name*}}
> {{ *at
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
> {{ at
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
> {{ at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
> {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHa
[jira] [Assigned] (SOLR-12013) collections API CUSTERSTATUS command fails when collections have errors
[
https://issues.apache.org/jira/browse/SOLR-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reassigned SOLR-12013:
-
Assignee: Erick Erickson
> collections API CUSTERSTATUS command fails when collections have errors
> ---
>
> Key: SOLR-12013
> URL: https://issues.apache.org/jira/browse/SOLR-12013
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 6.0, 7.0, 7.1, 7.2
>Reporter: Ben DeMott
>Assignee: Erick Erickson
>Priority: Major
>
> CLUSTERSTATUS command can be given independent of a given collection.
> http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
> I would expect that you can still inspect the status of a cluster even if a
> single collection has failed, or is missing its configuration.
> *Expected behavior*: all healthy collections status is returned, unhealthy
> collections are either reported with a stacktrace in the response, reported
> in a failure state, or are not present from the response.
> For example, CLUSTERSTATUS fails when a collection config-set is missing from
> ZooKeeper with:
> {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
> exist in ZooKeeper: config-set-name*}}
> {{ *at
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
> {{ at
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
> {{ at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
> {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}}
> {{ at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}}
> {{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}}
> {{ at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)}}
> {{ at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)}}
> {{ at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)}}
> {{ at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)}}
> {{ at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)}}
> {{ at
> org.eclipse.je
[jira] [Updated] (SOLR-13235) Split Ref Guide Collections API page into several sub-pages
[ https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-13235: - Fix Version/s: (was: 8.1) 8.2 > Split Ref Guide Collections API page into several sub-pages > --- > > Key: SOLR-13235 > URL: https://issues.apache.org/jira/browse/SOLR-13235 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 50m > Remaining Estimate: 0h > > The Collections API page in the Ref Guide has become the de-facto place where > information about how to work with Solr collections is stored, but it is so > huge with API examples that information gets lost. > I did some work a couple months ago to split this up, and came up with this > approach to splitting up the content: > * *Cluster and Node Management*: Define properties for the entire cluster; > check the status of a cluster; remove replicas from a node; utilize a newly > added node; add or remove roles for a node. > * *Collection Management*: Create, list, reload and delete collections; set > collection properties; migrate documents to another collection; rebalance > leaders; backup and restore collections. > * *Collection Aliasing*: Create, list or delete collection aliases; set alias > properties. > * *Shard Management*: Create and delete a shard; split a shard into two or > more additional shards; force a shard leader. > * *Replica Management*: Add or delete a replica; set replica properties; move > a replica to a different node. > My existing local WIP leaves info on Async commands on the main > collections-api.adoc page, but creates new pages for each of the bullets > mentioned above, and moves the related API calls to those pages. Each topic > will be smaller and easier for us to manage on an ongoing basis. > Since I did the work a while ago, I need to bring it up to date with master, > so a patch & a branch with this work will be forthcoming shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[
https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841666#comment-16841666
]
David Smiley commented on SOLR-11127:
-
You've been working on some cool and useful issues [~ab] – kudos!
I want to mention a couple suggestions to improve this feature in the future:
* Making the source collection read-only might be inconvenient or infeasible
for some apps. As an option, a best-effort attempt would be useful. Even if
some changes don't make it, the client may already have a means of detecting
data that needs to be resent, such as using a strategy involving looking at the
highest timestamp. Or it may simply not matter, like for an experiment on the
target.
* IMO {{batchSize}} would have been a more appropriate name for {{rows}}
param, which as it stands appears to be something that limits the reindexing to
just this number of documents. After all, you used the same param name that we
are all intimately familiar with for /select uses. I see this use of "rows" was
in turn used by topic() but that's the same issue there. Ah well; many users
won't touch this any way.
Also I suggest re-titling this issue to reflect your commit message –
"REINDEXCOLLECTION command for re-indexing of existing collections.", not the
original goal.
> Add a Collections API command to migrate the .system collection schema from
> Trie-based (pre-7.0) to Points-based (7.0+)
> ---
>
> Key: SOLR-11127
> URL: https://issues.apache.org/jira/browse/SOLR-11127
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki
>Priority: Blocker
> Labels: numeric-tries-to-points
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-11127.patch, SOLR-11127.patch, SOLR-11127.patch,
> SOLR-11127.patch
>
>
> SOLR-9 will switch the Trie fieldtypes in the .system collection's schema
> to Points.
> Users with pre-7.0 .system collections will no longer be able to use them
> once Trie fields have been removed (8.0).
> Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to
> automatically convert a Trie-based .system collection to a Points-based one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki resolved SOLR-11127. -- Resolution: Fixed > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Andrzej Bialecki >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: 8.1, master (9.0) > > Attachments: SOLR-11127.patch, SOLR-11127.patch, SOLR-11127.patch, > SOLR-11127.patch > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16796080#comment-16796080 ] ASF subversion and git services commented on SOLR-11127: Commit b778417054e735cf323139a43e84d6262ce9dcd7 in lucene-solr's branch refs/heads/branch_8x from Andrzej Bialecki [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b778417 ] SOLR-11127: REINDEXCOLLECTION command for re-indexing of existing collections. > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Andrzej Bialecki >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: 8.1, master (9.0) > > Attachments: SOLR-11127.patch, SOLR-11127.patch, SOLR-11127.patch, > SOLR-11127.patch > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16796048#comment-16796048 ] ASF subversion and git services commented on SOLR-11127: Commit 6f2b7bf5c0144f19572b54eed4fc340c13cf8c2a in lucene-solr's branch refs/heads/master from Andrzej Bialecki [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6f2b7bf ] SOLR-11127: REINDEXCOLLECTION command for re-indexing of existing collections. > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Andrzej Bialecki >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: 8.1, master (9.0) > > Attachments: SOLR-11127.patch, SOLR-11127.patch, SOLR-11127.patch, > SOLR-11127.patch > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[
https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16795401#comment-16795401
]
Andrzej Bialecki commented on SOLR-11127:
--
The latest patch. This includes a {{.system}} compatibility check that is
performed on {{Overseer}} leader startup. This verification only logs a warning
about the potentially incompatible index data, providing details of schema
fields that are likely incompatible. This should provide sufficient information
for users to decide whether to re-index the collection.
If there are no objections I'd like to commit this shortly.
> Add a Collections API command to migrate the .system collection schema from
> Trie-based (pre-7.0) to Points-based (7.0+)
> ---
>
> Key: SOLR-11127
> URL: https://issues.apache.org/jira/browse/SOLR-11127
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki
>Priority: Blocker
> Labels: numeric-tries-to-points
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-11127.patch, SOLR-11127.patch, SOLR-11127.patch,
> SOLR-11127.patch
>
>
> SOLR-9 will switch the Trie fieldtypes in the .system collection's schema
> to Points.
> Users with pre-7.0 .system collections will no longer be able to use them
> once Trie fields have been removed (8.0).
> Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to
> automatically convert a Trie-based .system collection to a Points-based one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11127: - Attachment: SOLR-11127.patch > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Andrzej Bialecki >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: 8.1, master (9.0) > > Attachments: SOLR-11127.patch, SOLR-11127.patch, SOLR-11127.patch, > SOLR-11127.patch > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792125#comment-16792125 ] Andrzej Bialecki commented on SOLR-11127: -- Another update - support for checking status and progress of reindexing, RefGuide documentation. > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Andrzej Bialecki >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: 8.0 > > Attachments: SOLR-11127.patch, SOLR-11127.patch, SOLR-11127.patch > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11127: - Attachment: SOLR-11127.patch > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Andrzej Bialecki >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: 8.0 > > Attachments: SOLR-11127.patch, SOLR-11127.patch, SOLR-11127.patch > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790861#comment-16790861 ] Andrzej Bialecki commented on SOLR-11127: -- Updated patch, with a lot more internal error checking and additional unit tests. I think this is fairly complete in functionality, more documentation to follow soon. > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Andrzej Bialecki >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: 8.0 > > Attachments: SOLR-11127.patch, SOLR-11127.patch > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11127: - Attachment: SOLR-11127.patch > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Andrzej Bialecki >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: 8.0 > > Attachments: SOLR-11127.patch, SOLR-11127.patch > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] gerlowskija commented on issue #575: SOLR-13235: Split Collections API Ref Guide page
gerlowskija commented on issue #575: SOLR-13235: Split Collections API Ref Guide page URL: https://github.com/apache/lucene-solr/pull/575#issuecomment-470254065 > Do you know more about how it works ... No. In fact, apparently I know less. Not sure what I was thinking. Looking closer at the docs, and trying it out, it doesn't work the way I thought it did. You're right that it only works on a single collection. Ignore my original comment, sorry. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] ctargett commented on issue #575: SOLR-13235: Split Collections API Ref Guide page
ctargett commented on issue #575: SOLR-13235: Split Collections API Ref Guide page URL: https://github.com/apache/lucene-solr/pull/575#issuecomment-469383469 > The only classification I thought twice about was your choice in putting `REBALANCELEADERS` in the collection-mgmt page, instead of the cluster-mgmt page. I might've put it on the cluster-mgmt page, since it affects all collections on the cluster. (It's a bit like `BALANCESHARDUNIQUE` that way) But I see the argument the other way too. 🤷♂️ Interesting. I put it with the collection management commands because it seemed it only works on a single collection (it has a required `collection` param to define the collection name), and the example just shows it working on a single collection. Do you know more about how it works on all collections? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16780903#comment-16780903 ] Andrzej Bialecki commented on SOLR-11127: -- This patch implements a REINDEX_COLLECTION command (NOTE: it depends on the changes in SOLR-13271). It uses the procedure described above. A daemon streaming expression is used for copying documents between collections. The new command supports reindexing any collection, with the usual caveats about potential data loss, and it supports the following: * different or the same source and target collection name (by using aliases, as described above) * most collection CREATE parameters are supported too, which allows re-shaping the collection (eg. changing the number of shards, the router, etc) Comments and review very appreciated! > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Andrzej Bialecki >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: 8.0 > > Attachments: SOLR-11127.patch > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11127: - Attachment: SOLR-11127.patch > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Andrzej Bialecki >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: 8.0 > > Attachments: SOLR-11127.patch > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[
https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777262#comment-16777262
]
Andrzej Bialecki commented on SOLR-11127:
--
Implementing a read-only mode for a collection allows us to use a better
solution to this problem:
* create a new unique collection using the new schema, eg.
{{.reindex__}}
* put the source collection in read-only mode. This entails:
** blocking new updates,
** issuing a hard commit
** closing the IndexWriter to make sure there aren't any ongoing background
merges.
* copy all documents from source to the new collection
* create an alias pointing from the source name to the new collection. The new
collection is already in read-write mode by default, and this operation is
atomic.
* optionally delete the original source
In this scenario we never lose the ability to search the source collection, at
the cost of losing the ability to process updates during the reindexing.
BTW. this scenario is applicable to basically any collection, not just the
{{.system}}, with the usual caveats about potentially losing the data from
document fields that can't be retrieved from the source collection.
> Add a Collections API command to migrate the .system collection schema from
> Trie-based (pre-7.0) to Points-based (7.0+)
> ---
>
> Key: SOLR-11127
> URL: https://issues.apache.org/jira/browse/SOLR-11127
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki
>Priority: Blocker
> Labels: numeric-tries-to-points
> Fix For: 8.0
>
>
> SOLR-9 will switch the Trie fieldtypes in the .system collection's schema
> to Points.
> Users with pre-7.0 .system collections will no longer be able to use them
> once Trie fields have been removed (8.0).
> Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to
> automatically convert a Trie-based .system collection to a Points-based one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] gerlowskija commented on a change in pull request #575: SOLR-13235: Split Collections API Ref Guide page
gerlowskija commented on a change in pull request #575: SOLR-13235: Split
Collections API Ref Guide page
URL: https://github.com/apache/lucene-solr/pull/575#discussion_r257728062
##
File path: solr/solr-ref-guide/src/cluster-node-management.adoc
##
@@ -0,0 +1,496 @@
+= Cluster and Node Management Commands
+:page-tocclass: right
+:page-toclevels: 1
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements. See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership. The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License. You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied. See the License for the
+// specific language governing permissions and limitations
+// under the License.
+
+A cluster is a set of Solr nodes operating in coordination with each other.
+
+These API commands work with a SolrCloud cluster at the entire cluster level,
or on individual nodes.
+
+[[clusterstatus]]
+== CLUSTERSTATUS: Cluster Status
+
+Fetch the cluster status including collections, shards, replicas,
configuration name as well as collection aliases and cluster properties.
+
+`/admin/collections?action=CLUSTERSTATUS`
+
+=== CLUSTERSTATUS Parameters
+
+`collection`::
+The collection name for which information is requested. If omitted,
information on all collections in the cluster will be returned.
+
+`shard`::
+The shard(s) for which information is requested. Multiple shard names can be
specified as a comma-separated list.
+
+`\_route_`::
+This can be used if you need the details of the shard where a particular
document belongs to and you don't know which shard it falls under.
+
+=== CLUSTERSTATUS Response
+
+The response will include the status of the request and the status of the
cluster.
+
+=== Examples using CLUSTERSTATUS
+
+*Input*
+
+[source,text]
+
+http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
+
+
+*Output*
+
+[source,json]
+
+{
+ "responseHeader":{
+"status":0,
+"QTime":333},
+ "cluster":{
+"collections":{
+ "collection1":{
+"shards":{
+ "shard1":{
+"range":"8000-",
+"state":"active",
+"replicas":{
+ "core_node1":{
+"state":"active",
+"core":"collection1",
+"node_name":"127.0.1.1:8983_solr",
+"base_url":"http://127.0.1.1:8983/solr";,
+"leader":"true"},
+ "core_node3":{
+"state":"active",
+"core":"collection1",
+"node_name":"127.0.1.1:8900_solr",
+"base_url":"http://127.0.1.1:8900/solr"}}},
+ "shard2":{
+"range":"0-7fff",
+"state":"active",
+"replicas":{
+ "core_node2":{
+"state":"active",
+"core":"collection1",
+"node_name":"127.0.1.1:7574_solr",
+"base_url":"http://127.0.1.1:7574/solr";,
+"leader":"true"},
+ "core_node4":{
+"state":"active",
+"core":"collection1",
+"node_name":"127.0.1.1:7500_solr",
+"base_url":"http://127.0.1.1:7500/solr",
+"maxShardsPerNode":"1",
+"router":{"name":"compositeId"},
+"replicationFactor":"1",
+"znodeVersion": 11,
+"autoCreated":"true",
+"configName" : "my_config",
+"aliases":["both_collections"]
+ },
+ "collection2":{
+"..."
+ }
+},
+"aliases":{ "both_collections":"collection1,collection2" },
+"roles":{
+ "overseer":[
+"127.0.1.1:8983_solr",
+"127.0.1.
[GitHub] gerlowskija commented on a change in pull request #575: SOLR-13235: Split Collections API Ref Guide page
gerlowskija commented on a change in pull request #575: SOLR-13235: Split Collections API Ref Guide page URL: https://github.com/apache/lucene-solr/pull/575#discussion_r257733502 ## File path: solr/solr-ref-guide/src/collection-management.adoc ## @@ -0,0 +1,752 @@ += Collection Management Commands +:page-tocclass: right +:page-toclevels: 1 +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +A collection is a single logical index that uses a single Solr configuration file (`solrconfig.xml`) and a single index schema. + +[[create]] +== CREATE: Create a Collection + +`/admin/collections?action=CREATE&name=_name_` + +=== CREATE Parameters + +The CREATE action allows the following parameters: + +`name`:: +The name of the collection to be created. This parameter is required. + +`router.name`:: +The router name that will be used. The router defines how documents will be distributed among the shards. Possible values are `implicit` or `compositeId`, which is the default. ++ +The `implicit` router does not automatically route documents to different shards. Whichever shard you indicate on the indexing request (or within each document) will be used as the destination for those documents. ++ +The `compositeId` router hashes the value in the uniqueKey field and looks up that hash in the collection's clusterstate to determine which shard will receive the document, with the additional ability to manually direct the routing. ++ +When using the `implicit` router, the `shards` parameter is required. When using the `compositeId` router, the `numShards` parameter is required. ++ +For more information, see also the section <>. + +`numShards`:: +The number of shards to be created as part of the collection. This is a required parameter when the `router.name` is `compositeId`. + +`shards`:: +A comma separated list of shard names, e.g., `shard-x,shard-y,shard-z`. This is a required parameter when the `router.name` is `implicit`. + +`replicationFactor`:: +The number of replicas to be created for each shard. The default is `1`. ++ +This will create a NRT type of replica. If you want another type of replica, see the `tlogReplicas` and `pullReplica` parameters below. See the section <> for more information about replica types. + +`nrtReplicas`:: +The number of NRT (Near-Real-Time) replicas to create for this collection. This type of replica maintains a transaction log and updates its index locally. If you want all of your replicas to be of this type, you can simply use `replicationFactor` instead. + +`tlogReplicas`:: +The number of TLOG replicas to create for this collection. This type of replica maintains a transaction log but only updates its index via replication from a leader. See the section <> for more information about replica types. + +`pullReplicas`:: +The number of PULL replicas to create for this collection. This type of replica does not maintain a transaction log and only updates its index via replication from a leader. This type is not eligible to become a leader and should not be the only type of replicas in the collection. See the section <> for more information about replica types. + +`maxShardsPerNode`:: +When creating collections, the shards and/or replicas are spread across all available (i.e., live) nodes, and two replicas of the same shard will never be on the same node. ++ +If a node is not live when the CREATE action is called, it will not get any parts of the new collection, which could lead to too many replicas being created on a single live node. Defining `maxShardsPerNode` sets a limit on the number of replicas the CREATE action will spread to each node. ++ +If the entire collection can not be fit into the live nodes, no collection will be created at all. The default `maxShardsPerNode` value is `1`. + +`createNodeSet`:: +Allows defining the nodes to spread the new collection across. The format is a comma-separated list of node_names, such as `localhost:8983_solr,localhost:8984_solr,localhost:8985_solr`. ++ +If not provided, the CREATE operation will create shard-replicas spread across all live Solr nodes. ++ +Alternatively, use the special v
[jira] [Commented] (SOLR-13235) Split Ref Guide Collections API page into several sub-pages
[ https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16769756#comment-16769756 ] Cassandra Targett commented on SOLR-13235: -- I've created a PR for this in lieu of a patch: https://github.com/apache/lucene-solr/pull/575 > Split Ref Guide Collections API page into several sub-pages > --- > > Key: SOLR-13235 > URL: https://issues.apache.org/jira/browse/SOLR-13235 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: 8.0, master (9.0) > > Time Spent: 10m > Remaining Estimate: 0h > > The Collections API page in the Ref Guide has become the de-facto place where > information about how to work with Solr collections is stored, but it is so > huge with API examples that information gets lost. > I did some work a couple months ago to split this up, and came up with this > approach to splitting up the content: > * *Cluster and Node Management*: Define properties for the entire cluster; > check the status of a cluster; remove replicas from a node; utilize a newly > added node; add or remove roles for a node. > * *Collection Management*: Create, list, reload and delete collections; set > collection properties; migrate documents to another collection; rebalance > leaders; backup and restore collections. > * *Collection Aliasing*: Create, list or delete collection aliases; set alias > properties. > * *Shard Management*: Create and delete a shard; split a shard into two or > more additional shards; force a shard leader. > * *Replica Management*: Add or delete a replica; set replica properties; move > a replica to a different node. > My existing local WIP leaves info on Async commands on the main > collections-api.adoc page, but creates new pages for each of the bullets > mentioned above, and moves the related API calls to those pages. Each topic > will be smaller and easier for us to manage on an ongoing basis. > Since I did the work a while ago, I need to bring it up to date with master, > so a patch & a branch with this work will be forthcoming shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] ctargett opened a new pull request #575: SOLR-13235: Split Collections API Ref Guide page
ctargett opened a new pull request #575: SOLR-13235: Split Collections API Ref Guide page URL: https://github.com/apache/lucene-solr/pull/575 This PR takes the massive collections-api.adoc page for the Collections API and splits it into several smaller, more focused, child pages. The following new pages will be added: - Cluster and Node Management (cluster-node-management.adoc): Define properties for the entire cluster; check the status of a cluster; remove replicas from a node; utilize a newly added node; add or remove roles for a node. - Collection Management (collection-management.adoc): Create, list, reload and delete collections; set collection properties; migrate documents to another collection; rebalance leaders; backup and restore collections. - Collection Aliasing (collection-aliasing.adoc): Create, list or delete collection aliases; set alias properties. - Shard Management (shard-management.adoc): Create and delete a shard; split a shard into two or more additional shards; force a shard leader. - Replica Management (replica-management.adoc): Add or delete a replica; set replica properties; move a replica to a different node. Remaining on the Collections API page is the detail about how to make asynchronous API requests, since it applies to all commands. Intro text on collections-api.adoc is also changed to reflect it's new role. Link references to specific API commands throughout the Ref Guide are also updated. The page still "lives" in the same place under "SolrCloud Configuration and Parameters", where it has been in the page hierarchy. A broader re-org of the pages under the SolrCloud section is warranted, but is out of scope for now. Also not included in this PR is any new content for v2-style API commands or missing params or examples, and those are out of scope for this change. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13235) Split Ref Guide Collections API page into several sub-pages
[ https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-13235: - Description: The Collections API page in the Ref Guide has become the de-facto place where information about how to work with Solr collections is stored, but it is so huge with API examples that information gets lost. I did some work a couple months ago to split this up, and came up with this approach to splitting up the content: * *Cluster and Node Management*: Define properties for the entire cluster; check the status of a cluster; remove replicas from a node; utilize a newly added node; add or remove roles for a node. * *Collection Management*: Create, list, reload and delete collections; set collection properties; migrate documents to another collection; rebalance leaders; backup and restore collections. * *Collection Aliasing*: Create, list or delete collection aliases; set alias properties. * *Shard Management*: Create and delete a shard; split a shard into two or more additional shards; force a shard leader. * *Replica Management*: Add or delete a replica; set replica properties; move a replica to a different node. My existing local WIP leaves info on Async commands on the main collections-api.adoc page, but creates new pages for each of the bullets mentioned above, and moves the related API calls to those pages. Each topic will be smaller and easier for us to manage on an ongoing basis. Since I did the work a while ago, I need to bring it up to date with master, so a patch & a branch with this work will be forthcoming shortly. was: The Collections API page has become the de-facto place where information about how to work with Solr collections is stored, but it is so huge with API examples that information gets lost. I did some work a couple months ago to split this up, and came up with this approach to splitting up the content: * *Cluster and Node Management*: Define properties for the entire cluster; check the status of a cluster; remove replicas from a node; utilize a newly added node; add or remove roles for a node. * *Collection Management*: Create, list, reload and delete collections; set collection properties; migrate documents to another collection; rebalance leaders; backup and restore collections. * *Collection Aliasing*: Create, list or delete collection aliases; set alias properties. * *Shard Management*: Create and delete a shard; split a shard into two or more additional shards; force a shard leader. * *Replica Management*: Add or delete a replica; set replica properties; move a replica to a different node. My existing local WIP leaves info on Async commands on the main collections-api.adoc page, but creates new pages for each of the bullets mentioned above, and moves the related API calls to those pages. Each topic will be smaller and easier for us to manage on an ongoing basis. Since I did the work a while ago, I need to bring it up to date with master, so a patch & a branch with this work will be forthcoming shortly. > Split Ref Guide Collections API page into several sub-pages > --- > > Key: SOLR-13235 > URL: https://issues.apache.org/jira/browse/SOLR-13235 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: 8.0, master (9.0) > > > The Collections API page in the Ref Guide has become the de-facto place where > information about how to work with Solr collections is stored, but it is so > huge with API examples that information gets lost. > I did some work a couple months ago to split this up, and came up with this > approach to splitting up the content: > * *Cluster and Node Management*: Define properties for the entire cluster; > check the status of a cluster; remove replicas from a node; utilize a newly > added node; add or remove roles for a node. > * *Collection Management*: Create, list, reload and delete collections; set > collection properties; migrate documents to another collection; rebalance > leaders; backup and restore collections. > * *Collection Aliasing*: Create, list or delete collection aliases; set alias > properties. > * *Shard Management*: Create and delete a shard; split a shard into two or > more additional shards; force a shard leader. > * *Replica Management*: Add or delete a replica; set replica properties; move > a replica to a different node. > My existing local WIP leaves info on Async commands on the main > collections-api.adoc page, but creates ne
[jira] [Created] (SOLR-13235) Split Ref Guide Collections API page into several sub-pages
Cassandra Targett created SOLR-13235: Summary: Split Ref Guide Collections API page into several sub-pages Key: SOLR-13235 URL: https://issues.apache.org/jira/browse/SOLR-13235 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Reporter: Cassandra Targett Assignee: Cassandra Targett Fix For: 8.0, master (9.0) The Collections API page has become the de-facto place where information about how to work with Solr collections is stored, but it is so huge with API examples that information gets lost. I did some work a couple months ago to split this up, and came up with this approach to splitting up the content: * *Cluster and Node Management*: Define properties for the entire cluster; check the status of a cluster; remove replicas from a node; utilize a newly added node; add or remove roles for a node. * *Collection Management*: Create, list, reload and delete collections; set collection properties; migrate documents to another collection; rebalance leaders; backup and restore collections. * *Collection Aliasing*: Create, list or delete collection aliases; set alias properties. * *Shard Management*: Create and delete a shard; split a shard into two or more additional shards; force a shard leader. * *Replica Management*: Add or delete a replica; set replica properties; move a replica to a different node. My existing local WIP leaves info on Async commands on the main collections-api.adoc page, but creates new pages for each of the bullets mentioned above, and moves the related API calls to those pages. Each topic will be smaller and easier for us to manage on an ongoing basis. Since I did the work a while ago, I need to bring it up to date with master, so a patch & a branch with this work will be forthcoming shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[
https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755022#comment-16755022
]
Jan Høydahl commented on SOLR-11127:
How to handle the two time gaps when .system will return 0 hits during copying?
Let's say we add a config option to configure {{BlobHandler}} and
{{UpdateRequestHandler}} into R/O mode (readOnly=true) where update requests
return HTTP 503 Service Unavailable. Then we could start by setting .system in
R/O and then safely copy back and forth and move alias only when copy is
complete, then at the end set .system back to readOnly=false and RELOAD .system
collection to get back to normal operation. Don't know how much work that would
be, sounds doable.
> Add a Collections API command to migrate the .system collection schema from
> Trie-based (pre-7.0) to Points-based (7.0+)
> ---
>
> Key: SOLR-11127
> URL: https://issues.apache.org/jira/browse/SOLR-11127
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki
>Priority: Blocker
> Labels: numeric-tries-to-points
> Fix For: 8.0
>
>
> SOLR-9 will switch the Trie fieldtypes in the .system collection's schema
> to Points.
> Users with pre-7.0 .system collections will no longer be able to use them
> once Trie fields have been removed (8.0).
> Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to
> automatically convert a Trie-based .system collection to a Points-based one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[
https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755022#comment-16755022
]
Jan Høydahl edited comment on SOLR-11127 at 1/29/19 1:46 PM:
-
How to handle the two time gaps when .system will return 0 hits during copying?
Let's say we add a config option to configure {{BlobHandler}} and
{{UpdateRequestHandler}} into R/O mode (readOnly=true) where update requests
return HTTP 503 Service Unavailable. Then we could start by setting .system in
R/O and then safely copy back and forth and move alias only when copy is
complete, then at the end set .system back to readOnly=false and RELOAD .system
collection to get back to normal operation. Don't know how much work that would
be, sounds doable.
The assumption is of course that any client should gracefully handle a
temporary error like 503 :)
was (Author: janhoy):
How to handle the two time gaps when .system will return 0 hits during copying?
Let's say we add a config option to configure {{BlobHandler}} and
{{UpdateRequestHandler}} into R/O mode (readOnly=true) where update requests
return HTTP 503 Service Unavailable. Then we could start by setting .system in
R/O and then safely copy back and forth and move alias only when copy is
complete, then at the end set .system back to readOnly=false and RELOAD .system
collection to get back to normal operation. Don't know how much work that would
be, sounds doable.
> Add a Collections API command to migrate the .system collection schema from
> Trie-based (pre-7.0) to Points-based (7.0+)
> ---
>
> Key: SOLR-11127
> URL: https://issues.apache.org/jira/browse/SOLR-11127
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki
>Priority: Blocker
> Labels: numeric-tries-to-points
> Fix For: 8.0
>
>
> SOLR-9 will switch the Trie fieldtypes in the .system collection's schema
> to Points.
> Users with pre-7.0 .system collections will no longer be able to use them
> once Trie fields have been removed (8.0).
> Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to
> automatically convert a Trie-based .system collection to a Points-based one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[
https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755007#comment-16755007
]
Andrzej Bialecki edited comment on SOLR-11127 at 1/29/19 1:24 PM:
---
My plan of attack is to implement a collection command that orchestrates the
following steps:
* create a temporary collection with a unique name, eg. {{tmpCollection_123}},
using the updated {{.system}} schema
* define an alias that points {{.system -> tmpCollection_123}}. This should
redirect all updates and queries to the temp collection.
* copy the documents from {{.system}} to the temp collection, avoiding
overwriting updated docs (incremental updates won't work during this process,
but AFAIK no Solr component uses incremental updates when indexing to
{{.system}})
* delete the original {{.system}} and create it again using the updated schema.
* remove the alias
* copy over the documents from temporary collection to {{.system}}, again
avoiding overwrites.
The collection command will take care of async processing, resuming the
operation on Overseer restarts, etc.
I considered doing this as a sort of rolling in-place update but this wouldn't
be any less expensive and I think it would have been impossible to do (and to
get it right) - updated schema uses points instead of trie fields for the same
fields.
Comments and feedback are welcome (thanks [~janhoy] for useful suggestions).
(Also, given that the 8.0 release is imminent I'm not sure I can fix this in
time for the 8.0 release.)
was (Author: ab):
My plan of attack is to implement a collection command that orchestrates the
following steps:
* create a temporary collection with a unique name, eg. {{tmpCollection_123}},
using the updated {{.system}} schema
* define an alias that points {{.system -> tmpCollection_123}}. This should
redirect all updates and queries to the temp collection.
* copy the documents from {{.system}} to the temp collection, avoiding
overwriting updated docs (incremental updates won't work during this process,
but AFAIK no Solr component uses incremental updates when indexing to
{{.system}})
* delete the original {{.system}} and create it again using the updated schema.
* remove the alias
* copy over the documents from temporary collection to {{.system}}, again
avoiding overwrites.
The collection command will take care of async processing, resuming the
operation on Overseer restarts, etc.
Comments and feedback are welcome.
(Also, given that the 8.0 release is imminent I'm not sure I can fix this in
time for the 8.0 release.)
> Add a Collections API command to migrate the .system collection schema from
> Trie-based (pre-7.0) to Points-based (7.0+)
> ---
>
> Key: SOLR-11127
> URL: https://issues.apache.org/jira/browse/SOLR-11127
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki
>Priority: Blocker
> Labels: numeric-tries-to-points
> Fix For: 8.0
>
>
> SOLR-9 will switch the Trie fieldtypes in the .system collection's schema
> to Points.
> Users with pre-7.0 .system collections will no longer be able to use them
> once Trie fields have been removed (8.0).
> Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to
> automatically convert a Trie-based .system collection to a Points-based one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[
https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755007#comment-16755007
]
Andrzej Bialecki commented on SOLR-11127:
--
My plan of attack is to implement a collection command that orchestrates the
following steps:
* create a temporary collection with a unique name, eg. {{tmpCollection_123}},
using the updated {{.system}} schema
* define an alias that points {{.system -> tmpCollection_123}}. This should
redirect all updates and queries to the temp collection.
* copy the documents from {{.system}} to the temp collection, avoiding
overwriting updated docs (incremental updates won't work during this process,
but AFAIK no Solr component uses incremental updates when indexing to
{{.system}})
* delete the original {{.system}} and create it again using the updated schema.
* remove the alias
* copy over the documents from temporary collection to {{.system}}, again
avoiding overwrites.
The collection command will take care of async processing, resuming the
operation on Overseer restarts, etc.
Comments and feedback are welcome.
(Also, given that the 8.0 release is imminent I'm not sure I can fix this in
time for the 8.0 release.)
> Add a Collections API command to migrate the .system collection schema from
> Trie-based (pre-7.0) to Points-based (7.0+)
> ---
>
> Key: SOLR-11127
> URL: https://issues.apache.org/jira/browse/SOLR-11127
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki
>Priority: Blocker
> Labels: numeric-tries-to-points
> Fix For: 8.0
>
>
> SOLR-9 will switch the Trie fieldtypes in the .system collection's schema
> to Points.
> Users with pre-7.0 .system collections will no longer be able to use them
> once Trie fields have been removed (8.0).
> Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to
> automatically convert a Trie-based .system collection to a Points-based one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[
https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755007#comment-16755007
]
Andrzej Bialecki edited comment on SOLR-11127 at 1/29/19 1:25 PM:
---
My plan of attack is to implement a collection command that orchestrates the
following steps:
* create a temporary collection with a unique name, eg.
{{.tmpCollection_123}}, using the updated {{.system}} schema
* define an alias that points {{.system -> .tmpCollection_123}}. This should
redirect all updates and queries to the temp collection.
* copy the documents from {{.system}} to the temp collection, avoiding
overwriting updated docs (incremental updates won't work during this process,
but AFAIK no Solr component uses incremental updates when indexing to
{{.system}})
* delete the original {{.system}} and create it again using the updated schema.
* remove the alias
* copy over the documents from temporary collection to {{.system}}, again
avoiding overwrites.
The collection command will take care of async processing, resuming the
operation on Overseer restarts, etc.
I considered doing this as a sort of rolling in-place update but this wouldn't
be any less expensive and I think it would have been impossible to do (and to
get it right) - updated schema uses points instead of trie fields for the same
fields.
Comments and feedback are welcome (thanks [~janhoy] for useful suggestions).
(Also, given that the 8.0 release is imminent I'm not sure I can fix this in
time for the 8.0 release.)
was (Author: ab):
My plan of attack is to implement a collection command that orchestrates the
following steps:
* create a temporary collection with a unique name, eg. {{tmpCollection_123}},
using the updated {{.system}} schema
* define an alias that points {{.system -> tmpCollection_123}}. This should
redirect all updates and queries to the temp collection.
* copy the documents from {{.system}} to the temp collection, avoiding
overwriting updated docs (incremental updates won't work during this process,
but AFAIK no Solr component uses incremental updates when indexing to
{{.system}})
* delete the original {{.system}} and create it again using the updated schema.
* remove the alias
* copy over the documents from temporary collection to {{.system}}, again
avoiding overwrites.
The collection command will take care of async processing, resuming the
operation on Overseer restarts, etc.
I considered doing this as a sort of rolling in-place update but this wouldn't
be any less expensive and I think it would have been impossible to do (and to
get it right) - updated schema uses points instead of trie fields for the same
fields.
Comments and feedback are welcome (thanks [~janhoy] for useful suggestions).
(Also, given that the 8.0 release is imminent I'm not sure I can fix this in
time for the 8.0 release.)
> Add a Collections API command to migrate the .system collection schema from
> Trie-based (pre-7.0) to Points-based (7.0+)
> ---
>
> Key: SOLR-11127
> URL: https://issues.apache.org/jira/browse/SOLR-11127
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki
>Priority: Blocker
> Labels: numeric-tries-to-points
> Fix For: 8.0
>
>
> SOLR-9 will switch the Trie fieldtypes in the .system collection's schema
> to Points.
> Users with pre-7.0 .system collections will no longer be able to use them
> once Trie fields have been removed (8.0).
> Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to
> automatically convert a Trie-based .system collection to a Points-based one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki reassigned SOLR-11127: Assignee: Andrzej Bialecki > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Andrzej Bialecki >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: 8.0 > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733325#comment-16733325 ] Jan Høydahl commented on SOLR-11127: Anyone planning to look into this for 8.0? > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: master (8.0) > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6399) Implement unloadCollection in the Collections API
[ https://issues.apache.org/jira/browse/SOLR-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729865#comment-16729865 ] Gus Heck commented on SOLR-6399: This also seems like it would be useful for A/B testing schema configurations on the same hardware if "unloaded" truly meant no resources were consumed. Imagine one tries a change and it's worse not better. It would be nice to be able to delete the experiment and simply reload the old collection. If the change is good delete (or back up and archive) the old one... saves standing up extra hardware, or re-indexing or backup/restore of the old collection when the experiment fails. The bigger the cluster and the bigger the data set the more useful this is. > Implement unloadCollection in the Collections API > - > > Key: SOLR-6399 > URL: https://issues.apache.org/jira/browse/SOLR-6399 > Project: Solr > Issue Type: New Feature >Reporter: dfdeshom >Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: 6.0 > > > There is currently no way to unload a collection without deleting its > contents. There should be a way in the collections API to unload a collection > and reload it later, as needed. > A use case for this is the following: you store logs by day, with each day > having its own collection. You are required to store up to 2 years of data, > which adds up to 730 collections. Most of the time, you'll want to have 3 > days of data loaded for search. Having just 3 collections loaded into memory, > instead of 730 will make managing Solr easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10209) UI: Convert all Collections api calls to async requests, add new features/buttons
[
https://issues.apache.org/jira/browse/SOLR-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614832#comment-16614832
]
Amrit Sarkar commented on SOLR-10209:
-
Hi [~janhoy] , thank you for noticing this Jira and improvement. I agree it
would be nice to have a simple synchronous option for Backup & Restore.
Unfortunately, I lost track of what I was doing a year ago but can definitely
work on this somewhere after mid-October (Activate'18). Else happy and
comfortable with fellow contributors and committers taking it forward.
> UI: Convert all Collections api calls to async requests, add new
> features/buttons
> -
>
> Key: SOLR-10209
> URL: https://issues.apache.org/jira/browse/SOLR-10209
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Reporter: Amrit Sarkar
>Priority: Major
> Attachments: SOLR-10209-v1.patch, SOLR-10209.patch, SOLR-10209.patch,
> SOLR-10209.patch
>
>
> We are having discussion on multiple jiras for requests for Collections apis
> from UI and how to improve them:
> -SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses
> connection with the server-
> -SOLR-10146: Admin UI: Button to delete a shard-
> SOLR-10201: Add Collection "creates collection", "Connection to Solr lost",
> when replicationFactor>1
> Proposal =>
> *Phase 1:*
> Convert all Collections api calls to async requests and utilise REQUESTSTATUS
> to fetch the information. There will be performance hit, but the requests
> will be safe and sound. A progress bar will be added for request status.
> {noformat}
> > submit the async request
> if (the initial call failed or there was no status to be found)
> { report an error and suggest the user look check their system before
> resubmitting the request. Bail out in this case, no retries, no attempt to
> drive on. }
> else
> { put up a progress indicator while periodically checking the status,
> Continue spinning until we can report the final status. }
> {noformat}
> *Phase 2:*
> Add new buttons/features to collections.html
> a) "Split" shard
> -b) "Delete" shard-
> c) "Backup" collection
> d) "Restore" collection
> Open to suggestions and feedbacks on this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10209) UI: Convert all Collections api calls to async requests, add new features/buttons
[
https://issues.apache.org/jira/browse/SOLR-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16611368#comment-16611368
]
Jan Høydahl commented on SOLR-10209:
Hi [~sarkaramr...@gmail.com], any plans to move this forward? Would be great to
have a UI for doing collection backup/restore etc.
> UI: Convert all Collections api calls to async requests, add new
> features/buttons
> -
>
> Key: SOLR-10209
> URL: https://issues.apache.org/jira/browse/SOLR-10209
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Reporter: Amrit Sarkar
>Priority: Major
> Attachments: SOLR-10209-v1.patch, SOLR-10209.patch, SOLR-10209.patch,
> SOLR-10209.patch
>
>
> We are having discussion on multiple jiras for requests for Collections apis
> from UI and how to improve them:
> -SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses
> connection with the server-
> -SOLR-10146: Admin UI: Button to delete a shard-
> SOLR-10201: Add Collection "creates collection", "Connection to Solr lost",
> when replicationFactor>1
> Proposal =>
> *Phase 1:*
> Convert all Collections api calls to async requests and utilise REQUESTSTATUS
> to fetch the information. There will be performance hit, but the requests
> will be safe and sound. A progress bar will be added for request status.
> {noformat}
> > submit the async request
> if (the initial call failed or there was no status to be found)
> { report an error and suggest the user look check their system before
> resubmitting the request. Bail out in this case, no retries, no attempt to
> drive on. }
> else
> { put up a progress indicator while periodically checking the status,
> Continue spinning until we can report the final status. }
> {noformat}
> *Phase 2:*
> Add new buttons/features to collections.html
> a) "Split" shard
> -b) "Delete" shard-
> c) "Backup" collection
> d) "Restore" collection
> Open to suggestions and feedbacks on this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510799#comment-16510799 ] Jan Høydahl commented on SOLR-11127: Perhaps also that there should be a check on system startup in version 7.x which logs an ERROR log line if the system collection is not converted so people are alerted of the need before it's too late? That could be a new Jira issue for 7.5? > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: master (8.0) > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10209) UI: Convert all Collections api calls to async requests, add new features/buttons
[
https://issues.apache.org/jira/browse/SOLR-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16469655#comment-16469655
]
Jan Høydahl commented on SOLR-10209:
Looking forward to this, seeing such behaviour with thousands of request when
developing for the Admin UI.
> UI: Convert all Collections api calls to async requests, add new
> features/buttons
> -
>
> Key: SOLR-10209
> URL: https://issues.apache.org/jira/browse/SOLR-10209
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Reporter: Amrit Sarkar
>Priority: Major
> Attachments: SOLR-10209-v1.patch, SOLR-10209.patch, SOLR-10209.patch,
> SOLR-10209.patch
>
>
> We are having discussion on multiple jiras for requests for Collections apis
> from UI and how to improve them:
> -SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses
> connection with the server-
> -SOLR-10146: Admin UI: Button to delete a shard-
> SOLR-10201: Add Collection "creates collection", "Connection to Solr lost",
> when replicationFactor>1
> Proposal =>
> *Phase 1:*
> Convert all Collections api calls to async requests and utilise REQUESTSTATUS
> to fetch the information. There will be performance hit, but the requests
> will be safe and sound. A progress bar will be added for request status.
> {noformat}
> > submit the async request
> if (the initial call failed or there was no status to be found)
> { report an error and suggest the user look check their system before
> resubmitting the request. Bail out in this case, no retries, no attempt to
> drive on. }
> else
> { put up a progress indicator while periodically checking the status,
> Continue spinning until we can report the final status. }
> {noformat}
> *Phase 2:*
> Add new buttons/features to collections.html
> a) "Split" shard
> -b) "Delete" shard-
> c) "Backup" collection
> d) "Restore" collection
> Open to suggestions and feedbacks on this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6399) Implement unloadCollection in the Collections API
[ https://issues.apache.org/jira/browse/SOLR-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16420139#comment-16420139 ] Erick Erickson commented on SOLR-6399: -- I don't think this can be dealt with by backup/restore for the reasons Yago outlines. Loading a collection might take a few minutes, whereas a multi-terabyte index could take hours/days. > Implement unloadCollection in the Collections API > - > > Key: SOLR-6399 > URL: https://issues.apache.org/jira/browse/SOLR-6399 > Project: Solr > Issue Type: New Feature >Reporter: dfdeshom >Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: 6.0 > > > There is currently no way to unload a collection without deleting its > contents. There should be a way in the collections API to unload a collection > and reload it later, as needed. > A use case for this is the following: you store logs by day, with each day > having its own collection. You are required to store up to 2 years of data, > which adds up to 730 collections. Most of the time, you'll want to have 3 > days of data loaded for search. Having just 3 collections loaded into memory, > instead of 730 will make managing Solr easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6634) The Collections API should have a UNLOAD and LOAD command
[ https://issues.apache.org/jira/browse/SOLR-6634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-6634. -- Resolution: Duplicate > The Collections API should have a UNLOAD and LOAD command > - > > Key: SOLR-6634 > URL: https://issues.apache.org/jira/browse/SOLR-6634 > Project: Solr > Issue Type: Improvement >Reporter: Varun Thacker >Priority: Major > > It would be useful if we allowed users to take their collection offline and > bring it back online. > The UNLOAD command can just unload all the cores in the collection, leaving > the ZK information in place. > Then the LOAD command can just use the clusterstate/state.json file to fire > CREATE core commands. I guess it should fail if the node hosting the core > earlier is not present anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6634) The Collections API should have a UNLOAD and LOAD command
[ https://issues.apache.org/jira/browse/SOLR-6634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16420074#comment-16420074 ] Steve Rowe commented on SOLR-6634: -- Can this issue be closed as a duplicate of SOLR-6399 ? > The Collections API should have a UNLOAD and LOAD command > - > > Key: SOLR-6634 > URL: https://issues.apache.org/jira/browse/SOLR-6634 > Project: Solr > Issue Type: Improvement >Reporter: Varun Thacker >Priority: Major > > It would be useful if we allowed users to take their collection offline and > bring it back online. > The UNLOAD command can just unload all the cores in the collection, leaving > the ZK information in place. > Then the LOAD command can just use the clusterstate/state.json file to fire > CREATE core commands. I guess it should fail if the node hosting the core > earlier is not present anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12013) collections API CUSTERSTATUS command fails when collections have errors
[
https://issues.apache.org/jira/browse/SOLR-12013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-12013:
-
Component/s: SolrCloud
> collections API CUSTERSTATUS command fails when collections have errors
> ---
>
> Key: SOLR-12013
> URL: https://issues.apache.org/jira/browse/SOLR-12013
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 6.0, 7.0, 7.1, 7.2
>Reporter: Ben DeMott
>Priority: Major
>
> CLUSTERSTATUS command can be given independent of a given collection.
> http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
> I would expect that you can still inspect the status of a cluster even if a
> single collection has failed, or is missing its configuration.
> *Expected behavior*: all healthy collections status is returned, unhealthy
> collections are either reported with a stacktrace in the response, reported
> in a failure state, or are not present from the response.
> For example, CLUSTERSTATUS fails when a collection config-set is missing from
> ZooKeeper with:
> {{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
> exist in ZooKeeper: config-set-name*}}
> {{ *at
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
> {{ at
> org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
> {{ at
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
> {{ at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
> {{ at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
> {{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
> {{ at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}}
> {{ at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}}
> {{ at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}}
> {{ at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}}
> {{ at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}}
> {{ at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}}
> {{ at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
> {{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}}
> {{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}}
> {{ at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)}}
> {{ at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)}}
> {{ at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)}}
> {{ at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)}}
> {{ at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteP
[jira] [Created] (SOLR-12013) collections API CUSTERSTATUS command fails when collections have errors
Ben DeMott created SOLR-12013:
-
Summary: collections API CUSTERSTATUS command fails when
collections have errors
Key: SOLR-12013
URL: https://issues.apache.org/jira/browse/SOLR-12013
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.2, 7.1, 7.0, 6.0
Reporter: Ben DeMott
CLUSTERSTATUS command can be given independent of a given collection.
http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS
I would expect that you can still inspect the status of a cluster even if a
single collection has failed, or is missing its configuration.
*Expected behavior*: all healthy collections status is returned, unhealthy
collections are either reported with a stacktrace in the response, reported in
a failure state, or are not present from the response.
For example, CLUSTERSTATUS fails when a collection config-set is missing from
ZooKeeper with:
{{*org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
exist in ZooKeeper: config-set-name*}}
{{ *at
org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:189)*}}
{{ at
org.apache.solr.handler.admin.ClusterStatus.getClusterStatus(ClusterStatus.java:141)}}
{{ at
org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.lambda$static$19(CollectionsHandler.java:649)}}
{{ at
org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation.execute(CollectionsHandler.java:888)}}
{{ at
org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:226)}}
{{ at
org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:213)}}
{{ at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)}}
{{ at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:748)}}
{{ at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:729)}}
{{ at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)}}
{{ at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)}}
{{ at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)}}
{{ at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)}}
{{ at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)}}
{{ at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)}}
{{ at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)}}
{{ at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)}}
{{ at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)}}
{{ at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)}}
{{ at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)}}
{{ at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)}}
{{ at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)}}
{{ at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)}}
{{ at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)}}
{{ at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
{{ at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)}}
{{ at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)}}
{{ at org.eclipse.jetty.server.Server.handle(Server.java:534)}}
{{ at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)}}
{{ at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)}}
{{ at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)}}
{{ at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)}}
{{ at
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)}}
{{ at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)}}
{{ at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)}}
{{ at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)}}
{{ at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)}}
{{ at
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)}}
{{ at java.lang.Thread.run(Thread.java:745)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11817) Move Collections API classes to it's own package
[
https://issues.apache.org/jira/browse/SOLR-11817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker resolved SOLR-11817.
--
Resolution: Fixed
Fix Version/s: 7.3
master (8.0)
> Move Collections API classes to it's own package
>
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11817.patch, SOLR-11817.patch, SOLR-11817.patch
>
>
> Today all collections api classes and tests are in the
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move
> the respected classes under that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11817) Move Collections API classes to it's own package
[
https://issues.apache.org/jira/browse/SOLR-11817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327762#comment-16327762
]
ASF subversion and git services commented on SOLR-11817:
Commit 1c6cc20ebb3a5096eff33d2ed8eb102508821d24 in lucene-solr's branch
refs/heads/branch_7x from [~varun_saxena]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1c6cc20 ]
SOLR-11817: Move Collections API classes to it's own package
(cherry picked from commit a3c4f73)
> Move Collections API classes to it's own package
>
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11817.patch, SOLR-11817.patch, SOLR-11817.patch
>
>
> Today all collections api classes and tests are in the
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move
> the respected classes under that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11817) Move Collections API classes to it's own package
[
https://issues.apache.org/jira/browse/SOLR-11817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327597#comment-16327597
]
Chris Lambertus edited comment on SOLR-11817 at 1/16/18 8:03 PM:
-
Commit a3c4f7388c13cfdeb66d83b434b991e5e159d4cc in lucene-solr's branch
refs/heads/master from [~varunthacker]
[ [https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a3c4f73] ]
SOLR-11817: Move Collections API classes to it's own package
was (Author: jira-bot):
Commit a3c4f7388c13cfdeb66d83b434b991e5e159d4cc in lucene-solr's branch
refs/heads/master from [~varun_saxena]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a3c4f73 ]
SOLR-11817: Move Collections API classes to it's own package
> Move Collections API classes to it's own package
>
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11817.patch, SOLR-11817.patch, SOLR-11817.patch
>
>
> Today all collections api classes and tests are in the
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move
> the respected classes under that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11817) Move Collections API classes to it's own package
[
https://issues.apache.org/jira/browse/SOLR-11817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327597#comment-16327597
]
ASF subversion and git services commented on SOLR-11817:
Commit a3c4f7388c13cfdeb66d83b434b991e5e159d4cc in lucene-solr's branch
refs/heads/master from [~varun_saxena]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a3c4f73 ]
SOLR-11817: Move Collections API classes to it's own package
> Move Collections API classes to it's own package
>
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11817.patch, SOLR-11817.patch, SOLR-11817.patch
>
>
> Today all collections api classes and tests are in the
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move
> the respected classes under that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11817) Move Collections API classes to it's own package
[
https://issues.apache.org/jira/browse/SOLR-11817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326695#comment-16326695
]
Varun Thacker commented on SOLR-11817:
--
I plan on committing this patch tomorrow. I can delay it if people have any
suggestions that they would like me to incorporate
> Move Collections API classes to it's own package
>
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11817.patch, SOLR-11817.patch, SOLR-11817.patch
>
>
> Today all collections api classes and tests are in the
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move
> the respected classes under that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11817) Move Collections API classes to it's own package
[
https://issues.apache.org/jira/browse/SOLR-11817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker updated SOLR-11817:
-
Attachment: SOLR-11817.patch
> Move Collections API classes to it's own package
>
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11817.patch, SOLR-11817.patch, SOLR-11817.patch
>
>
> Today all collections api classes and tests are in the
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move
> the respected classes under that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11817) Move Collections API classes to it's own package
[
https://issues.apache.org/jira/browse/SOLR-11817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker updated SOLR-11817:
-
Attachment: SOLR-11817.patch
tests pass. I'll run it a few more times as it touches a lot of files but
what's the general feedback on this approach?
> Move Collections API classes to it's own package
>
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11817.patch, SOLR-11817.patch
>
>
> Today all collections api classes and tests are in the
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move
> the respected classes under that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11817) Move Collections API classes to it's own package
[
https://issues.apache.org/jira/browse/SOLR-11817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker updated SOLR-11817:
-
Attachment: SOLR-11817.patch
Patch which moves collection api's to their own package including tests
There is lots of room for cleaning the code up and also making things more
modular . But we can tackle that in separate Jiras. The patch is pretty big
already because of all the shuffling
> Move Collections API classes to it's own package
>
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11817.patch
>
>
> Today all collections api classes and tests are in the
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move
> the respected classes under that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11817) Move Collections API classes to it's own package
[
https://issues.apache.org/jira/browse/SOLR-11817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16310660#comment-16310660
]
Varun Thacker commented on SOLR-11817:
--
Noticed SOLR-11818 was very odd. In general a lot of the test framework stuff
could be cleaned up but that's beyond the scope here
> Move Collections API classes to it's own package
>
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Priority: Minor
>
> Today all collections api classes and tests are in the
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move
> the respected classes under that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11817) Move Collections API classes to it's own package
Varun Thacker created SOLR-11817:
Summary: Move Collections API classes to it's own package
Key: SOLR-11817
URL: https://issues.apache.org/jira/browse/SOLR-11817
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker
Assignee: Varun Thacker
Priority: Minor
Today all collections api classes and tests are in the
{{org.apache.solr.cloud}} package.
We should create a {{org.apache.solr.cloud.api.collections}} package and move
the respected classes under that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11751) Collections API: Implement collection properties that block Collections API actions
[ https://issues.apache.org/jira/browse/SOLR-11751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288156#comment-16288156 ] Shawn Heisey commented on SOLR-11751: - [~erickerickson], I didn't see your comment until after I had finished adding my optional ideas. Which I did type immediately, but forgot to click "Add" until later. Regarding the optional idea where an override parameter must match the value in the property: If we make it so that an empty string in the property can't ever be matched, that would allow somebody to easily prevent the override. Of course the same thing could be accomplished with a special string, like "NO_OVERRIDE". > Collections API: Implement collection properties that block Collections API > actions > > > Key: SOLR-11751 > URL: https://issues.apache.org/jira/browse/SOLR-11751 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.1 >Reporter: Shawn Heisey >Priority: Minor > > [~yriveiro] asked on the mailing list whether we had any ability to prevent a > collection from being deleted with a property. > I don't know of any way to do this currently, but it does strike me as > useful, so here's the proposal: > Implement some new collection properties, that when set, block certain > Collections API actions. > At this time, I'm not even sure that user-modifiable collection-level > properties actually exist, so that may need to be implemented before this can > be implemented. It *could* be done with cluster properties, but that seems > like a hack. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11751) Collections API: Implement collection properties that block Collections API actions
[ https://issues.apache.org/jira/browse/SOLR-11751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288137#comment-16288137 ] Shawn Heisey commented on SOLR-11751: - Optional ideas: * If a blocking property can have an arbitrary value, implement an API parameter that would override the block, IF the value for that parameter matches the value in the property. * One single property that blocks ALL Collections API usage. A tangent idea, for a separate issue: * Prevent external CoreAdmin requests on SolrCloud unless a property is set that essentially makes the user declare "yes, I know what I'm doing". This one probably should work at the cluster or collection level. > Collections API: Implement collection properties that block Collections API > actions > > > Key: SOLR-11751 > URL: https://issues.apache.org/jira/browse/SOLR-11751 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.1 >Reporter: Shawn Heisey >Priority: Minor > > [~yriveiro] asked on the mailing list whether we had any ability to prevent a > collection from being deleted with a property. > I don't know of any way to do this currently, but it does strike me as > useful, so here's the proposal: > Implement some new collection properties, that when set, block certain > Collections API actions. > At this time, I'm not even sure that user-modifiable collection-level > properties actually exist, so that may need to be implemented before this can > be implemented. It *could* be done with cluster properties, but that seems > like a hack. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11751) Collections API: Implement collection properties that block Collections API actions
[ https://issues.apache.org/jira/browse/SOLR-11751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288106#comment-16288106 ] Erick Erickson commented on SOLR-11751: --- The collecitons API MODIFYCOLLECTION can add/modify collection properties I think, which would allow you to add the tags at least already. We'd need to build in code to respect such tags of course. I'd guess you'd have to change the property in order to be able to delete the collection if you _really_ wanted to delete it at some later point. I can imagine you'd like to lock down configsets too, although that'd be a sticky wicket wrt field guessing, and the schema and config APIs. > Collections API: Implement collection properties that block Collections API > actions > > > Key: SOLR-11751 > URL: https://issues.apache.org/jira/browse/SOLR-11751 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.1 >Reporter: Shawn Heisey >Priority: Minor > > [~yriveiro] asked on the mailing list whether we had any ability to prevent a > collection from being deleted with a property. > I don't know of any way to do this currently, but it does strike me as > useful, so here's the proposal: > Implement some new collection properties, that when set, block certain > Collections API actions. > At this time, I'm not even sure that user-modifiable collection-level > properties actually exist, so that may need to be implemented before this can > be implemented. It *could* be done with cluster properties, but that seems > like a hack. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Created] (SOLR-11751) Collections API: Implement collection properties that block Collections API actions
Can't get to JIRA right now, but the Collections API MODIFYCOLLECTION seems right for adding properties On Tue, Dec 12, 2017 at 10:58 AM, Shawn Heisey (JIRA) wrote: > Shawn Heisey created SOLR-11751: > --- > > Summary: Collections API: Implement collection properties that > block Collections API actions > Key: SOLR-11751 > URL: https://issues.apache.org/jira/browse/SOLR-11751 > Project: Solr > Issue Type: New Feature > Security Level: Public (Default Security Level. Issues are Public) > Components: SolrCloud > Affects Versions: 7.1 > Reporter: Shawn Heisey > Priority: Minor > > > [~yriveiro] asked on the mailing list whether we had any ability to prevent a > collection from being deleted with a property. > > I don't know of any way to do this currently, but it does strike me as > useful, so here's the proposal: > > Implement some new collection properties, that when set, block certain > Collections API actions. > > At this time, I'm not even sure that user-modifiable collection-level > properties actually exist, so that may need to be implemented before this can > be implemented. It *could* be done with cluster properties, but that seems > like a hack. > > > > > -- > This message was sent by Atlassian JIRA > (v6.4.14#64029) > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11751) Collections API: Implement collection properties that block Collections API actions
Shawn Heisey created SOLR-11751: --- Summary: Collections API: Implement collection properties that block Collections API actions Key: SOLR-11751 URL: https://issues.apache.org/jira/browse/SOLR-11751 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Affects Versions: 7.1 Reporter: Shawn Heisey Priority: Minor [~yriveiro] asked on the mailing list whether we had any ability to prevent a collection from being deleted with a property. I don't know of any way to do this currently, but it does strike me as useful, so here's the proposal: Implement some new collection properties, that when set, block certain Collections API actions. At this time, I'm not even sure that user-modifiable collection-level properties actually exist, so that may need to be implemented before this can be implemented. It *could* be done with cluster properties, but that seems like a hack. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11582) Collections API reload response only includes host/port/context info, not core names
[
https://issues.apache.org/jira/browse/SOLR-11582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-11582:
-
Affects Version/s: (was: 7.1.0)
7.1
> Collections API reload response only includes host/port/context info, not
> core names
>
>
> Key: SOLR-11582
> URL: https://issues.apache.org/jira/browse/SOLR-11582
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 7.1
>Reporter: Shawn Heisey
>Priority: Trivial
> Attachments: solr-5.5.0-reload-output.png,
> solr-7.1.0-reload-output.png
>
>
> When reloading a collection on SolrCloud, the response doesn't include enough
> info to know exactly what was reloaded. It's got host/port/context, which is
> useful, but it should also include the core name.
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":833},
> "success":{
> "10.2.0.108:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":655}},
> "10.2.0.108:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":680}},
> "10.2.0.108:7574_solr":{
> "responseHeader":{
> "status":0,
> "QTime":781}},
> "10.2.0.108:7574_solr":{
> "responseHeader":{
> "status":0,
> "QTime":785
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11582) Collections API reload response only includes host/port/context info, not core names
[
https://issues.apache.org/jira/browse/SOLR-11582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227111#comment-16227111
]
Philippe L commented on SOLR-11582:
---
Hi,
I uploaded 2 screenshots of a collection reload in 7.1.0 & 5.5.0. It's done
with a basic start of sorlcloud example on my local machine (as described here
https://lucene.apache.org/solr/guide/6_6/getting-started-with-solrcloud.html )
trying to reload "gettingstarted" collection.
I confirm that the host/port/context is missing in the 5.5.0 version, we'll
probably update to v7 soon :)
Thanks again for your help on IRC
Regards
> Collections API reload response only includes host/port/context info, not
> core names
>
>
> Key: SOLR-11582
> URL: https://issues.apache.org/jira/browse/SOLR-11582
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 7.1.0
>Reporter: Shawn Heisey
>Priority: Trivial
> Attachments: solr-5.5.0-reload-output.png,
> solr-7.1.0-reload-output.png
>
>
> When reloading a collection on SolrCloud, the response doesn't include enough
> info to know exactly what was reloaded. It's got host/port/context, which is
> useful, but it should also include the core name.
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":833},
> "success":{
> "10.2.0.108:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":655}},
> "10.2.0.108:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":680}},
> "10.2.0.108:7574_solr":{
> "responseHeader":{
> "status":0,
> "QTime":781}},
> "10.2.0.108:7574_solr":{
> "responseHeader":{
> "status":0,
> "QTime":785
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11582) Collections API reload response only includes host/port/context info, not core names
[
https://issues.apache.org/jira/browse/SOLR-11582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philippe L updated SOLR-11582:
--
Attachment: solr-5.5.0-reload-output.png
> Collections API reload response only includes host/port/context info, not
> core names
>
>
> Key: SOLR-11582
> URL: https://issues.apache.org/jira/browse/SOLR-11582
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 7.1.0
>Reporter: Shawn Heisey
>Priority: Trivial
> Attachments: solr-5.5.0-reload-output.png,
> solr-7.1.0-reload-output.png
>
>
> When reloading a collection on SolrCloud, the response doesn't include enough
> info to know exactly what was reloaded. It's got host/port/context, which is
> useful, but it should also include the core name.
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":833},
> "success":{
> "10.2.0.108:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":655}},
> "10.2.0.108:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":680}},
> "10.2.0.108:7574_solr":{
> "responseHeader":{
> "status":0,
> "QTime":781}},
> "10.2.0.108:7574_solr":{
> "responseHeader":{
> "status":0,
> "QTime":785
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11582) Collections API reload response only includes host/port/context info, not core names
[
https://issues.apache.org/jira/browse/SOLR-11582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philippe L updated SOLR-11582:
--
Attachment: solr-7.1.0-reload-output.png
> Collections API reload response only includes host/port/context info, not
> core names
>
>
> Key: SOLR-11582
> URL: https://issues.apache.org/jira/browse/SOLR-11582
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 7.1.0
>Reporter: Shawn Heisey
>Priority: Trivial
> Attachments: solr-7.1.0-reload-output.png
>
>
> When reloading a collection on SolrCloud, the response doesn't include enough
> info to know exactly what was reloaded. It's got host/port/context, which is
> useful, but it should also include the core name.
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":833},
> "success":{
> "10.2.0.108:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":655}},
> "10.2.0.108:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":680}},
> "10.2.0.108:7574_solr":{
> "responseHeader":{
> "status":0,
> "QTime":781}},
> "10.2.0.108:7574_solr":{
> "responseHeader":{
> "status":0,
> "QTime":785
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11582) Collections API reload response only includes host/port/context info, not core names
[
https://issues.apache.org/jira/browse/SOLR-11582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227022#comment-16227022
]
Shawn Heisey commented on SOLR-11582:
-
I went looking to try and figure out how to add the core name to the response,
and just like every other foray into the Collections API that I have attempted,
I cannot figure out how it works or where to consider making code changes.
> Collections API reload response only includes host/port/context info, not
> core names
>
>
> Key: SOLR-11582
> URL: https://issues.apache.org/jira/browse/SOLR-11582
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 7.1.0
>Reporter: Shawn Heisey
>Priority: Trivial
>
> When reloading a collection on SolrCloud, the response doesn't include enough
> info to know exactly what was reloaded. It's got host/port/context, which is
> useful, but it should also include the core name.
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":833},
> "success":{
> "10.2.0.108:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":655}},
> "10.2.0.108:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":680}},
> "10.2.0.108:7574_solr":{
> "responseHeader":{
> "status":0,
> "QTime":781}},
> "10.2.0.108:7574_solr":{
> "responseHeader":{
> "status":0,
> "QTime":785
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11582) Collections API reload response only includes host/port/context info, not core names
[
https://issues.apache.org/jira/browse/SOLR-11582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227005#comment-16227005
]
Shawn Heisey commented on SOLR-11582:
-
A user on the IRC channel brought this issue up. They're running 5.5.0, and
the response they're getting on that version doesn't even include
host/port/context. I doubt we'll fix this on 5.x, but it might be worth
backporting to 6.x just in case there's another security release there.
> Collections API reload response only includes host/port/context info, not
> core names
>
>
> Key: SOLR-11582
> URL: https://issues.apache.org/jira/browse/SOLR-11582
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 7.1.0
>Reporter: Shawn Heisey
>Priority: Trivial
>
> When reloading a collection on SolrCloud, the response doesn't include enough
> info to know exactly what was reloaded. It's got host/port/context, which is
> useful, but it should also include the core name.
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":833},
> "success":{
> "10.2.0.108:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":655}},
> "10.2.0.108:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":680}},
> "10.2.0.108:7574_solr":{
> "responseHeader":{
> "status":0,
> "QTime":781}},
> "10.2.0.108:7574_solr":{
> "responseHeader":{
> "status":0,
> "QTime":785
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11582) Collections API reload response only includes host/port/context info, not core names
Shawn Heisey created SOLR-11582:
---
Summary: Collections API reload response only includes
host/port/context info, not core names
Key: SOLR-11582
URL: https://issues.apache.org/jira/browse/SOLR-11582
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrCloud
Affects Versions: 7.1.0
Reporter: Shawn Heisey
Priority: Trivial
When reloading a collection on SolrCloud, the response doesn't include enough
info to know exactly what was reloaded. It's got host/port/context, which is
useful, but it should also include the core name.
{noformat}
{
"responseHeader":{
"status":0,
"QTime":833},
"success":{
"10.2.0.108:8983_solr":{
"responseHeader":{
"status":0,
"QTime":655}},
"10.2.0.108:8983_solr":{
"responseHeader":{
"status":0,
"QTime":680}},
"10.2.0.108:7574_solr":{
"responseHeader":{
"status":0,
"QTime":781}},
"10.2.0.108:7574_solr":{
"responseHeader":{
"status":0,
"QTime":785
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11479) Collections API: ADDREPLICA fails if you try to specify property.coreNodeName=foo
[
https://issues.apache.org/jira/browse/SOLR-11479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202400#comment-16202400
]
Hoss Man commented on SOLR-11479:
-
discovered while trying to fix the tests in SOLR-11469
> Collections API: ADDREPLICA fails if you try to specify
> property.coreNodeName=foo
> -
>
> Key: SOLR-11479
> URL: https://issues.apache.org/jira/browse/SOLR-11479
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: SOLR-11479.patch
>
>
> if you attempt to specify a {{property.coreNodeName}} param when using the
> Collection API's {{action=ADDREPLICA}} the request will fail -- the
> underlying cause of the failure (in the logs for the node where the
> underlying Core Admin CREATECORE request is routed) seems like a perplexing
> chicken/egg problem...
> (the various names in the error below are from a test patch i'll attach
> shortly)
> {noformat}
>[junit4] 2> Caused by: org.apache.solr.common.SolrException: Unable to
> create core [solrj_replica_explicit_coreNodeName_shard1_replica_n5]
>[junit4] 2> at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1049)
>[junit4] 2> at
> org.apache.solr.core.CoreContainer.create(CoreContainer.java:947)
>[junit4] 2> ... 34 more
>[junit4] 2> Caused by: org.apache.solr.common.SolrException:
> coreNodeName user_assigned_node_name does not exist in shard shard1:
> DocCollection(solrj_replica_explicit_coreNodeName//collections/solrj_replica_explicit_coreNodeName/state.json/7)={
> ...
>[junit4] 2> 11157 INFO (qtp1977346252-47) [n:127.0.0.1:51786_solr
> c:solrj_replica_explicit_coreNodeName s:shard1 r:user_assigned_node_name
> x:solrj_replica_explicit_coreNodeName_shard1_replica_n5] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/cores
> params={qt=/admin/cores&coreNodeName=core_node6&collection.configName=conf&name=solrj_replica_explicit_coreNodeName_shard1_replica_n5&property.coreNodeName=user_assigned_node_name&action=CREATE&collection=solrj_replica_explicit_coreNodeName&shard=shard1&wt=javabin&version=2&replicaType=NRT}
> status=400 QTime=3009
> {noformat}
> ...the CREATE core action is failing because the cloud shard we want to
> ADDREPLICA to says that a replica with that coreNodeName doesn't exist
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11479) Collections API: ADDREPLICA fails if you try to specify property.coreNodeName=foo
[
https://issues.apache.org/jira/browse/SOLR-11479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-11479:
Attachment: SOLR-11479.patch
here's a (test only) patch demonstrating the problem ... really straight
forward addition to CollectionsAPISolrJTest...
{code}
@Test
public void testAddReplicaWithCoreNodeNameProp() throws Exception {
final String collectionName = "solrj_replica_explicit_coreNodeName";
CollectionAdminRequest.createCollection(collectionName, "conf", 1, 2)
.process(cluster.getSolrClient());
final String coreNodeName = "user_assigned_node_name";
CollectionAdminResponse response =
CollectionAdminRequest.addReplicaToShard(collectionName, "shard1")
.withProperty(CoreDescriptor.CORE_NODE_NAME, coreNodeName)
.process(cluster.getSolrClient());
assertEquals(0, response.getStatus());
assertTrue(response.isSuccess());
Replica newReplica = grabNewReplica(response,
getCollectionState(collectionName));
assertTrue(newReplica.getName().equals(coreNodeName));
}
{code}
> Collections API: ADDREPLICA fails if you try to specify
> property.coreNodeName=foo
> -
>
> Key: SOLR-11479
> URL: https://issues.apache.org/jira/browse/SOLR-11479
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: SOLR-11479.patch
>
>
> if you attempt to specify a {{property.coreNodeName}} param when using the
> Collection API's {{action=ADDREPLICA}} the request will fail -- the
> underlying cause of the failure (in the logs for the node where the
> underlying Core Admin CREATECORE request is routed) seems like a perplexing
> chicken/egg problem...
> (the various names in the error below are from a test patch i'll attach
> shortly)
> {noformat}
>[junit4] 2> Caused by: org.apache.solr.common.SolrException: Unable to
> create core [solrj_replica_explicit_coreNodeName_shard1_replica_n5]
>[junit4] 2> at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1049)
>[junit4] 2> at
> org.apache.solr.core.CoreContainer.create(CoreContainer.java:947)
>[junit4] 2> ... 34 more
>[junit4] 2> Caused by: org.apache.solr.common.SolrException:
> coreNodeName user_assigned_node_name does not exist in shard shard1:
> DocCollection(solrj_replica_explicit_coreNodeName//collections/solrj_replica_explicit_coreNodeName/state.json/7)={
> ...
>[junit4] 2> 11157 INFO (qtp1977346252-47) [n:127.0.0.1:51786_solr
> c:solrj_replica_explicit_coreNodeName s:shard1 r:user_assigned_node_name
> x:solrj_replica_explicit_coreNodeName_shard1_replica_n5] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/cores
> params={qt=/admin/cores&coreNodeName=core_node6&collection.configName=conf&name=solrj_replica_explicit_coreNodeName_shard1_replica_n5&property.coreNodeName=user_assigned_node_name&action=CREATE&collection=solrj_replica_explicit_coreNodeName&shard=shard1&wt=javabin&version=2&replicaType=NRT}
> status=400 QTime=3009
> {noformat}
> ...the CREATE core action is failing because the cloud shard we want to
> ADDREPLICA to says that a replica with that coreNodeName doesn't exist
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11479) Collections API: ADDREPLICA fails if you try to specify property.coreNodeName=foo
Hoss Man created SOLR-11479:
---
Summary: Collections API: ADDREPLICA fails if you try to specify
property.coreNodeName=foo
Key: SOLR-11479
URL: https://issues.apache.org/jira/browse/SOLR-11479
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
if you attempt to specify a {{property.coreNodeName}} param when using the
Collection API's {{action=ADDREPLICA}} the request will fail -- the underlying
cause of the failure (in the logs for the node where the underlying Core Admin
CREATECORE request is routed) seems like a perplexing chicken/egg problem...
(the various names in the error below are from a test patch i'll attach shortly)
{noformat}
[junit4] 2> Caused by: org.apache.solr.common.SolrException: Unable to
create core [solrj_replica_explicit_coreNodeName_shard1_replica_n5]
[junit4] 2>at
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1049)
[junit4] 2>at
org.apache.solr.core.CoreContainer.create(CoreContainer.java:947)
[junit4] 2>... 34 more
[junit4] 2> Caused by: org.apache.solr.common.SolrException: coreNodeName
user_assigned_node_name does not exist in shard shard1:
DocCollection(solrj_replica_explicit_coreNodeName//collections/solrj_replica_explicit_coreNodeName/state.json/7)={
...
[junit4] 2> 11157 INFO (qtp1977346252-47) [n:127.0.0.1:51786_solr
c:solrj_replica_explicit_coreNodeName s:shard1 r:user_assigned_node_name
x:solrj_replica_explicit_coreNodeName_shard1_replica_n5] o.a.s.s.HttpSolrCall
[admin] webapp=null path=/admin/cores
params={qt=/admin/cores&coreNodeName=core_node6&collection.configName=conf&name=solrj_replica_explicit_coreNodeName_shard1_replica_n5&property.coreNodeName=user_assigned_node_name&action=CREATE&collection=solrj_replica_explicit_coreNodeName&shard=shard1&wt=javabin&version=2&replicaType=NRT}
status=400 QTime=3009
{noformat}
...the CREATE core action is failing because the cloud shard we want to
ADDREPLICA to says that a replica with that coreNodeName doesn't exist
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[ https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated SOLR-11127: -- Labels: numeric-tries-to-points (was: ) > Add a Collections API command to migrate the .system collection schema from > Trie-based (pre-7.0) to Points-based (7.0+) > --- > > Key: SOLR-11127 > URL: https://issues.apache.org/jira/browse/SOLR-11127 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Priority: Blocker > Labels: numeric-tries-to-points > Fix For: master (8.0) > > > SOLR-9 will switch the Trie fieldtypes in the .system collection's schema > to Points. > Users with pre-7.0 .system collections will no longer be able to use them > once Trie fields have been removed (8.0). > Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to > automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
Steve Rowe created SOLR-11127: - Summary: Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+) Key: SOLR-11127 URL: https://issues.apache.org/jira/browse/SOLR-11127 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Steve Rowe Priority: Blocker Fix For: master (8.0) SOLR-9 will switch the Trie fieldtypes in the .system collection's schema to Points. Users with pre-7.0 .system collections will no longer be able to use them once Trie fields have been removed (8.0). Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to automatically convert a Trie-based .system collection to a Points-based one. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-10689) migrate in collections api not working
[ https://issues.apache.org/jira/browse/SOLR-10689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reopened SOLR-10689: --- > migrate in collections api not working > -- > > Key: SOLR-10689 > URL: https://issues.apache.org/jira/browse/SOLR-10689 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI, clients - java >Affects Versions: 6.5.1 >Reporter: chandru > > When migrating with the same query that was given in collection api , There > was no docs that were migrated from A -> B. Please help me to proceed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10689) migrate in collections api not working
[ https://issues.apache.org/jira/browse/SOLR-10689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-10689. --- Resolution: Cannot Reproduce "Fixed" was misleading, my mistake. > migrate in collections api not working > -- > > Key: SOLR-10689 > URL: https://issues.apache.org/jira/browse/SOLR-10689 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI, clients - java >Affects Versions: 6.5.1 >Reporter: chandru > > When migrating with the same query that was given in collection api , There > was no docs that were migrated from A -> B. Please help me to proceed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10689) migrate in collections api not working
[ https://issues.apache.org/jira/browse/SOLR-10689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-10689. --- Resolution: Fixed Please raise this question on the user's list at solr-u...@lucene.apache.org, there are a _lot_ more people watching that list who may be able to help. If it's determined that this is a code issue in Solr and not a configuration/usage problem, we can raise a JIRA. When you do raise the issue on the JIRA list, you must include enough detail to help us help you. Exactly what command did you use? Was there any useful information in the logs? etc. > migrate in collections api not working > -- > > Key: SOLR-10689 > URL: https://issues.apache.org/jira/browse/SOLR-10689 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI, clients - java >Affects Versions: 6.5.1 >Reporter: chandru > > When migrating with the same query that was given in collection api , There > was no docs that were migrated from A -> B. Please help me to proceed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10689) migrate in collections api not working
chandru created SOLR-10689: -- Summary: migrate in collections api not working Key: SOLR-10689 URL: https://issues.apache.org/jira/browse/SOLR-10689 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Admin UI, clients - java Affects Versions: 6.5.1 Reporter: chandru When migrating with the same query that was given in collection api , There was no docs that were migrated from A -> B. Please help me to proceed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10209) UI: Convert all Collections api calls to async requests, add new features/buttons
[
https://issues.apache.org/jira/browse/SOLR-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15985027#comment-15985027
]
Amrit Sarkar commented on SOLR-10209:
-
Been a while posted any update on this.
With the existing UI code, it is little challenging incorporating a new message
box, floating preferred, to show current status, as we intend to refresh the
entire scope at the end of each request. I intend to change that specially for
heavy APIs and post full and final patch within a week.
> UI: Convert all Collections api calls to async requests, add new
> features/buttons
> -
>
> Key: SOLR-10209
> URL: https://issues.apache.org/jira/browse/SOLR-10209
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Reporter: Amrit Sarkar
> Attachments: SOLR-10209.patch, SOLR-10209.patch, SOLR-10209.patch,
> SOLR-10209-v1.patch
>
>
> We are having discussion on multiple jiras for requests for Collections apis
> from UI and how to improve them:
> -SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses
> connection with the server-
> -SOLR-10146: Admin UI: Button to delete a shard-
> SOLR-10201: Add Collection "creates collection", "Connection to Solr lost",
> when replicationFactor>1
> Proposal =>
> *Phase 1:*
> Convert all Collections api calls to async requests and utilise REQUESTSTATUS
> to fetch the information. There will be performance hit, but the requests
> will be safe and sound. A progress bar will be added for request status.
> {noformat}
> > submit the async request
> if (the initial call failed or there was no status to be found)
> { report an error and suggest the user look check their system before
> resubmitting the request. Bail out in this case, no retries, no attempt to
> drive on. }
> else
> { put up a progress indicator while periodically checking the status,
> Continue spinning until we can report the final status. }
> {noformat}
> *Phase 2:*
> Add new buttons/features to collections.html
> a) "Split" shard
> -b) "Delete" shard-
> c) "Backup" collection
> d) "Restore" collection
> Open to suggestions and feedbacks on this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8589) Add aliases to the LIST action results in the Collections API
[ https://issues.apache.org/jira/browse/SOLR-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15971715#comment-15971715 ] ASF subversion and git services commented on SOLR-8589: --- Commit 05ed7cf02440ede6f1f67786ea85a49c8af8ea76 in lucene-solr's branch refs/heads/branch_6x from [~ichattopadhyaya] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=05ed7cf ] SOLR-10447, SOLR-8589: Adding Yago Riveiro to changelog > Add aliases to the LIST action results in the Collections API > - > > Key: SOLR-8589 > URL: https://issues.apache.org/jira/browse/SOLR-8589 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.4.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Attachments: solr-8589-new-list-details-aliases.png, SOLR-8589.patch, > SOLR-8589.patch, SOLR-8589.patch, SOLR-8589.patch > > > Although it is possible to get a list of SolrCloud aliases vi an HTTP API, it > is not available as a typical query response, I believe it is only available > via the http API for zookeeper. > The results from the LIST action in the Collections API is well-situated to > handle this. The current results are contained in a "collections" node, we > can simply add an "aliases" node if there are any aliases defined. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8589) Add aliases to the LIST action results in the Collections API
[ https://issues.apache.org/jira/browse/SOLR-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15971717#comment-15971717 ] ASF subversion and git services commented on SOLR-8589: --- Commit d286864d801bc3ba2c51714a41d58632e7da1200 in lucene-solr's branch refs/heads/master from [~ichattopadhyaya] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d286864 ] SOLR-10447, SOLR-8589: Adding Yago Riveiro to changelog > Add aliases to the LIST action results in the Collections API > - > > Key: SOLR-8589 > URL: https://issues.apache.org/jira/browse/SOLR-8589 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.4.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Attachments: solr-8589-new-list-details-aliases.png, SOLR-8589.patch, > SOLR-8589.patch, SOLR-8589.patch, SOLR-8589.patch > > > Although it is possible to get a list of SolrCloud aliases vi an HTTP API, it > is not available as a typical query response, I believe it is only available > via the http API for zookeeper. > The results from the LIST action in the Collections API is well-situated to > handle this. The current results are contained in a "collections" node, we > can simply add an "aliases" node if there are any aliases defined. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8589) Add aliases to the LIST action results in the Collections API
[ https://issues.apache.org/jira/browse/SOLR-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15971698#comment-15971698 ] ASF subversion and git services commented on SOLR-8589: --- Commit 3e5f76251a31a629ebcb3a504be6202714d5ce52 in lucene-solr's branch refs/heads/branch_6x from [~ichattopadhyaya] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3e5f762 ] SOLR-10447, SOLR-4968, SOLR-8589: Adding contributors to CHANGES.txt > Add aliases to the LIST action results in the Collections API > - > > Key: SOLR-8589 > URL: https://issues.apache.org/jira/browse/SOLR-8589 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.4.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Attachments: solr-8589-new-list-details-aliases.png, SOLR-8589.patch, > SOLR-8589.patch, SOLR-8589.patch, SOLR-8589.patch > > > Although it is possible to get a list of SolrCloud aliases vi an HTTP API, it > is not available as a typical query response, I believe it is only available > via the http API for zookeeper. > The results from the LIST action in the Collections API is well-situated to > handle this. The current results are contained in a "collections" node, we > can simply add an "aliases" node if there are any aliases defined. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8589) Add aliases to the LIST action results in the Collections API
[ https://issues.apache.org/jira/browse/SOLR-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15971681#comment-15971681 ] ASF subversion and git services commented on SOLR-8589: --- Commit 201ebbc5049e5c389ed0a79f6621cd057ed624ea in lucene-solr's branch refs/heads/master from [~ichattopadhyaya] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=201ebbc ] SOLR-10447, SOLR-4968, SOLR-8589: Adding contributors to CHANGES.txt > Add aliases to the LIST action results in the Collections API > - > > Key: SOLR-8589 > URL: https://issues.apache.org/jira/browse/SOLR-8589 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.4.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Attachments: solr-8589-new-list-details-aliases.png, SOLR-8589.patch, > SOLR-8589.patch, SOLR-8589.patch, SOLR-8589.patch > > > Although it is possible to get a list of SolrCloud aliases vi an HTTP API, it > is not available as a typical query response, I believe it is only available > via the http API for zookeeper. > The results from the LIST action in the Collections API is well-situated to > handle this. The current results are contained in a "collections" node, we > can simply add an "aliases" node if there are any aliases defined. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-8589) Add aliases to the LIST action results in the Collections API
[ https://issues.apache.org/jira/browse/SOLR-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya resolved SOLR-8589. Resolution: Duplicate Fixed in SOLR-10447. > Add aliases to the LIST action results in the Collections API > - > > Key: SOLR-8589 > URL: https://issues.apache.org/jira/browse/SOLR-8589 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.4.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Attachments: solr-8589-new-list-details-aliases.png, SOLR-8589.patch, > SOLR-8589.patch, SOLR-8589.patch, SOLR-8589.patch > > > Although it is possible to get a list of SolrCloud aliases vi an HTTP API, it > is not available as a typical query response, I believe it is only available > via the http API for zookeeper. > The results from the LIST action in the Collections API is well-situated to > handle this. The current results are contained in a "collections" node, we > can simply add an "aliases" node if there are any aliases defined. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10209) UI: Convert all Collections api calls to async requests, add new features/buttons
[
https://issues.apache.org/jira/browse/SOLR-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amrit Sarkar updated SOLR-10209:
Description:
We are having discussion on multiple jiras for requests for Collections apis
from UI and how to improve them:
-SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses connection
with the server-
-SOLR-10146: Admin UI: Button to delete a shard-
SOLR-10201: Add Collection "creates collection", "Connection to Solr lost",
when replicationFactor>1
Proposal =>
*Phase 1:*
Convert all Collections api calls to async requests and utilise REQUESTSTATUS
to fetch the information. There will be performance hit, but the requests will
be safe and sound. A progress bar will be added for request status.
{noformat}
> submit the async request
if (the initial call failed or there was no status to be found)
{ report an error and suggest the user look check their system before
resubmitting the request. Bail out in this case, no retries, no attempt to
drive on. }
else
{ put up a progress indicator while periodically checking the status, Continue
spinning until we can report the final status. }
{noformat}
*Phase 2:*
Add new buttons/features to collections.html
a) "Split" shard
-b) "Delete" shard-
c) "Backup" collection
d) "Restore" collection
Open to suggestions and feedbacks on this.
was:
We are having discussion on multiple jiras for requests for Collections apis
from UI and how to improve them:
-SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses connection
with the server-
SOLR-10146: Admin UI: Button to delete a shard
SOLR-10201: Add Collection "creates collection", "Connection to Solr lost",
when replicationFactor>1
Proposal =>
*Phase 1:*
Convert all Collections api calls to async requests and utilise REQUESTSTATUS
to fetch the information. There will be performance hit, but the requests will
be safe and sound. A progress bar will be added for request status.
{noformat}
> submit the async request
if (the initial call failed or there was no status to be found)
{ report an error and suggest the user look check their system before
resubmitting the request. Bail out in this case, no retries, no attempt to
drive on. }
else
{ put up a progress indicator while periodically checking the status, Continue
spinning until we can report the final status. }
{noformat}
*Phase 2:*
Add new buttons/features to collections.html
a) "Split" shard
-b) "Delete" shard-
c) "Backup" collection
d) "Restore" collection
Open to suggestions and feedbacks on this.
> UI: Convert all Collections api calls to async requests, add new
> features/buttons
> -
>
> Key: SOLR-10209
> URL: https://issues.apache.org/jira/browse/SOLR-10209
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Reporter: Amrit Sarkar
> Attachments: SOLR-10209.patch, SOLR-10209.patch, SOLR-10209-v1.patch
>
>
> We are having discussion on multiple jiras for requests for Collections apis
> from UI and how to improve them:
> -SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses
> connection with the server-
> -SOLR-10146: Admin UI: Button to delete a shard-
> SOLR-10201: Add Collection "creates collection", "Connection to Solr lost",
> when replicationFactor>1
> Proposal =>
> *Phase 1:*
> Convert all Collections api calls to async requests and utilise REQUESTSTATUS
> to fetch the information. There will be performance hit, but the requests
> will be safe and sound. A progress bar will be added for request status.
> {noformat}
> > submit the async request
> if (the initial call failed or there was no status to be found)
> { report an error and suggest the user look check their system before
> resubmitting the request. Bail out in this case, no retries, no attempt to
> drive on. }
> else
> { put up a progress indicator while periodically checking the status,
> Continue spinning until we can report the final status. }
> {noformat}
> *Phase 2:*
> Add new buttons/features to collections.html
> a) "Split" shard
> -b) "Delete" shard-
> c) "Backup" collection
> d) "Restore" collection
> Open to suggestions and feedbacks on this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10209) UI: Convert all Collections api calls to async requests, add new features/buttons
[
https://issues.apache.org/jira/browse/SOLR-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amrit Sarkar updated SOLR-10209:
Description:
We are having discussion on multiple jiras for requests for Collections apis
from UI and how to improve them:
-SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses connection
with the server-
SOLR-10146: Admin UI: Button to delete a shard
SOLR-10201: Add Collection "creates collection", "Connection to Solr lost",
when replicationFactor>1
Proposal =>
*Phase 1:*
Convert all Collections api calls to async requests and utilise REQUESTSTATUS
to fetch the information. There will be performance hit, but the requests will
be safe and sound. A progress bar will be added for request status.
{noformat}
> submit the async request
if (the initial call failed or there was no status to be found)
{ report an error and suggest the user look check their system before
resubmitting the request. Bail out in this case, no retries, no attempt to
drive on. }
else
{ put up a progress indicator while periodically checking the status, Continue
spinning until we can report the final status. }
{noformat}
*Phase 2:*
Add new buttons/features to collections.html
a) "Split" shard
-b) "Delete" shard-
c) "Backup" collection
d) "Restore" collection
Open to suggestions and feedbacks on this.
was:
We are having discussion on multiple jiras for requests for Collections apis
from UI and how to improve them:
SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses connection
with the server
SOLR-10146: Admin UI: Button to delete a shard
SOLR-10201: Add Collection "creates collection", "Connection to Solr lost",
when replicationFactor>1
Proposal =>
*Phase 1:*
Convert all Collections api calls to async requests and utilise REQUESTSTATUS
to fetch the information. There will be performance hit, but the requests will
be safe and sound. A progress bar will be added for request status.
{noformat}
> submit the async request
if (the initial call failed or there was no status to be found)
{ report an error and suggest the user look check their system before
resubmitting the request. Bail out in this case, no retries, no attempt to
drive on. }
else
{ put up a progress indicator while periodically checking the status, Continue
spinning until we can report the final status. }
{noformat}
*Phase 2:*
Add new buttons/features to collections.html
a) "Split" shard
b) "Delete" shard
c) "Backup" collection
d) "Restore" collection
Open to suggestions and feedbacks on this.
> UI: Convert all Collections api calls to async requests, add new
> features/buttons
> -
>
> Key: SOLR-10209
> URL: https://issues.apache.org/jira/browse/SOLR-10209
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Reporter: Amrit Sarkar
> Attachments: SOLR-10209.patch, SOLR-10209.patch, SOLR-10209-v1.patch
>
>
> We are having discussion on multiple jiras for requests for Collections apis
> from UI and how to improve them:
> -SOLR-9818: Solr admin UI rapidly retries any request(s) if it loses
> connection with the server-
> SOLR-10146: Admin UI: Button to delete a shard
> SOLR-10201: Add Collection "creates collection", "Connection to Solr lost",
> when replicationFactor>1
> Proposal =>
> *Phase 1:*
> Convert all Collections api calls to async requests and utilise REQUESTSTATUS
> to fetch the information. There will be performance hit, but the requests
> will be safe and sound. A progress bar will be added for request status.
> {noformat}
> > submit the async request
> if (the initial call failed or there was no status to be found)
> { report an error and suggest the user look check their system before
> resubmitting the request. Bail out in this case, no retries, no attempt to
> drive on. }
> else
> { put up a progress indicator while periodically checking the status,
> Continue spinning until we can report the final status. }
> {noformat}
> *Phase 2:*
> Add new buttons/features to collections.html
> a) "Split" shard
> -b) "Delete" shard-
> c) "Backup" collection
> d) "Restore" collection
> Open to suggestions and feedbacks on this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
