[jira] [Resolved] (SOLR-3256) Distributed search throws NPE when using fl=score
[ https://issues.apache.org/jira/browse/SOLR-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3256. --- Resolution: Fixed Thanks Tomas! > Distributed search throws NPE when using fl=score > - > > Key: SOLR-3256 > URL: https://issues.apache.org/jira/browse/SOLR-3256 > Project: Solr > Issue Type: Bug >Reporter: Tomás Fernández Löbbe >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3256.patch, SOLR-3256.patch > > > Steps to reproduce the problem: > Start two Solr instances (may use the example configuration) > add some documents to both instances > execute a query like: > http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:8984/solr&q=(ipod%20OR%20display)&*fl=score* > Expected result: > List of scores or at least an exception saying that this request is not > supported (may not make too much sense to do fl=score, but a descriptive > exception can help debug the problem) > Getting: > SEVERE: null:java.lang.NullPointerException > at > org.apache.solr.handler.component.QueryComponent.returnFields(QueryComponent.java:985) > at > org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:637) > at > org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:612) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:435) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) > at org.eclipse.jetty.server.Server.handle(Server.java:351) > at > org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) > at > org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) > at > org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) > at > org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) > at > org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) > at > org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) > at java.lang.Thread.run(Thread.java:636) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3214) If you use multiple fl entries rather than a comma separated list, all but the first entry can be ignored if you are using distributed search.
[ https://issues.apache.org/jira/browse/SOLR-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3214. --- Resolution: Fixed Resolved using Tomas' patch in SOLR-3256 > If you use multiple fl entries rather than a comma separated list, all but > the first entry can be ignored if you are using distributed search. > -- > > Key: SOLR-3214 > URL: https://issues.apache.org/jira/browse/SOLR-3214 > Project: Solr > Issue Type: Bug > Components: search >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > > I have not checked yet, but prob in 3.x too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2191) Change SolrException cstrs that take Throwable to default to alreadyLogged=false
[ https://issues.apache.org/jira/browse/SOLR-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2191. --- Resolution: Fixed > Change SolrException cstrs that take Throwable to default to > alreadyLogged=false > > > Key: SOLR-2191 > URL: https://issues.apache.org/jira/browse/SOLR-2191 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 3.6, 4.0 > > Attachments: SOLR-2191.patch > > > Because of misuse, many exceptions are now not logged at all - can be painful > when doing dev. I think we should flip this setting and work at removing any > double logging - losing logging is worse (and it almost looks like we lose > more logging than we would get in double logging) - and bad > solrexception/logging patterns are proliferating. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3129) Move a lot of the startup logging to trace.
[ https://issues.apache.org/jira/browse/SOLR-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3129. --- Resolution: Fixed I think yonik has already done this, just using debug rather than trace. > Move a lot of the startup logging to trace. > --- > > Key: SOLR-3129 > URL: https://issues.apache.org/jira/browse/SOLR-3129 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > > We should make the start up logging cleaner - 9 times out of 10 you don't > need all that info and 9 times out of 10 it just makes it harder to find what > you do need - especially if you have a lot of core reloads. > I think most of the "added" and "created" events can go to trace - when you > need that info you can easily broaden the log level - but for the majority > case when you don't, lets clean this up? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3126) We should try to do a quick sync on std start up recovery before trying to do a full blown replication.
[ https://issues.apache.org/jira/browse/SOLR-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3126. --- Resolution: Fixed > We should try to do a quick sync on std start up recovery before trying to do > a full blown replication. > --- > > Key: SOLR-3126 > URL: https://issues.apache.org/jira/browse/SOLR-3126 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-3126.patch, SOLR-3126.patch > > > just more efficient - especially on cluster shutdown/start where the replicas > may all be up to date and match anway. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3166) Allow bootstrapping multiple config sets from multi-core setups.
[ https://issues.apache.org/jira/browse/SOLR-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3166. --- Resolution: Fixed > Allow bootstrapping multiple config sets from multi-core setups. > > > Key: SOLR-3166 > URL: https://issues.apache.org/jira/browse/SOLR-3166 > Project: Solr > Issue Type: New Feature >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-3166.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3194) Attaching a commit to an update request results in too many commits on each node.
[ https://issues.apache.org/jira/browse/SOLR-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3194. --- Resolution: Fixed > Attaching a commit to an update request results in too many commits on each > node. > - > > Key: SOLR-3194 > URL: https://issues.apache.org/jira/browse/SOLR-3194 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-3194.patch > > > As reported to me by Alexey Serba, if you choose to pass a commit=true param > with an update request, too many commits are asked for on each node. > The problem is that it causes a local commit which triggers commits on the > other nodes, and it also forwards on the commit=true param causing further > commits. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3153) When a leader goes down he should ask replicas to sync in parallel rather than serially.
[ https://issues.apache.org/jira/browse/SOLR-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3153. --- Resolution: Fixed Committed. > When a leader goes down he should ask replicas to sync in parallel rather > than serially. > > > Key: SOLR-3153 > URL: https://issues.apache.org/jira/browse/SOLR-3153 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3153.patch > > > Need to finish this todo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3819) Clean up what we show in right side bar of website.
[ https://issues.apache.org/jira/browse/LUCENE-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved LUCENE-3819. - Resolution: Fixed > Clean up what we show in right side bar of website. > --- > > Key: LUCENE-3819 > URL: https://issues.apache.org/jira/browse/LUCENE-3819 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > I'd love to remove a couple things - it's pretty crowded on the right side > bar. I find the latest JIRA and email displays are hard to read, tend to > format badly, and don't offer much value. > I'd like to remove them and just leave svn commits and twitter mentions > (which are much easier to read and format better). Will help with some info > overload on each page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3137) When solr.xml is persisted, you lose all system property substitution that was used.
[ https://issues.apache.org/jira/browse/SOLR-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3137. --- Resolution: Fixed > When solr.xml is persisted, you lose all system property substitution that > was used. > - > > Key: SOLR-3137 > URL: https://issues.apache.org/jira/browse/SOLR-3137 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-3137.patch, SOLR-3137.patch > > > A lesser issue is that we also write out properties that where not originally > in the file with the defaults they picked up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3125) When a SolrCore registers in zk there may be stale leader state in the clusterstate.json.
[ https://issues.apache.org/jira/browse/SOLR-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3125. --- Resolution: Fixed This is good for now - works - any improvement can go to another issue. > When a SolrCore registers in zk there may be stale leader state in the > clusterstate.json. > - > > Key: SOLR-3125 > URL: https://issues.apache.org/jira/browse/SOLR-3125 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-3125.patch > > > This can be a problem when stop the whole cluster and then start it - a > leader that has not yet showed up in the cluster state may see a stale leader > and try to recover from it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3122) RecoveryStrat can not use interrupt due to the use of Channels.
[ https://issues.apache.org/jira/browse/SOLR-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3122. --- Resolution: Fixed > RecoveryStrat can not use interrupt due to the use of Channels. > --- > > Key: SOLR-3122 > URL: https://issues.apache.org/jira/browse/SOLR-3122 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > > along the lines of LUCENE-2239, we cannot use interrupt unfortunetly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2354) CoreAdminRequest#createCore should allow you to specify the data dir
[ https://issues.apache.org/jira/browse/SOLR-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2354. --- Resolution: Invalid > CoreAdminRequest#createCore should allow you to specify the data dir > > > Key: SOLR-2354 > URL: https://issues.apache.org/jira/browse/SOLR-2354 > Project: Solr > Issue Type: Improvement > Components: clients - java >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3137) When solr.xml is persisted, you lose all system property substitution that was used.
[ https://issues.apache.org/jira/browse/SOLR-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3137. --- Resolution: Fixed > When solr.xml is persisted, you lose all system property substitution that > was used. > - > > Key: SOLR-3137 > URL: https://issues.apache.org/jira/browse/SOLR-3137 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-3137.patch, SOLR-3137.patch > > > A lesser issue is that we also write out properties that where not originally > in the file with the defaults they picked up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3138) Add node roles to core admin handler 'create core' and solrj.
[ https://issues.apache.org/jira/browse/SOLR-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3138. --- Resolution: Fixed > Add node roles to core admin handler 'create core' and solrj. > - > > Key: SOLR-3138 > URL: https://issues.apache.org/jira/browse/SOLR-3138 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3138.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3126) We should try to do a quick sync on std start up recovery before trying to do a full blown replication.
[ https://issues.apache.org/jira/browse/SOLR-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3126. --- Resolution: Fixed Alright, this is in. > We should try to do a quick sync on std start up recovery before trying to do > a full blown replication. > --- > > Key: SOLR-3126 > URL: https://issues.apache.org/jira/browse/SOLR-3126 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-3126.patch > > > just more efficient - especially on cluster shutdown/start where the replicas > may all be up to date and match anway. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3117) CoreDescriptor attempts to use the name before checking if it is null
[
https://issues.apache.org/jira/browse/SOLR-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller resolved SOLR-3117.
---
Resolution: Fixed
Thanks Jaime!
> CoreDescriptor attempts to use the name before checking if it is null
> -
>
> Key: SOLR-3117
> URL: https://issues.apache.org/jira/browse/SOLR-3117
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Affects Versions: 4.0
>Reporter: Jamie Johnson
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.0
>
> Attachments: CoreDescriptor.patch
>
>
> in CoreDescriptor when creating the cloudDesc the name is accessed before
> checking if it is null
> I believe it should be the following instead
> {code}
> public CoreDescriptor(CoreContainer coreContainer, String name, String
> instanceDir) {
> this.coreContainer = coreContainer;
> this.name = name;
>
> if (name == null) {
> throw new RuntimeException("Core needs a name");
> }
>
> if(coreContainer != null && coreContainer.getZkController() != null) {
> this.cloudDesc = new CloudDescriptor();
> // cloud collection defaults to core name
> cloudDesc.setCollectionName(name.isEmpty() ?
> coreContainer.getDefaultCoreName() : name);
> }
>
> if (instanceDir == null) {
> throw new NullPointerException("Missing required \'instanceDir\'");
> }
> instanceDir = SolrResourceLoader.normalizeDir(instanceDir);
> this.instanceDir = instanceDir;
> this.configName = getDefaultConfigName();
> this.schemaName = getDefaultSchemaName();
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2957) collection URLs in a cluster
[ https://issues.apache.org/jira/browse/SOLR-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2957. --- Resolution: Fixed I've got a new issue for the remaining suggestion: SOLR-3119 > collection URLs in a cluster > > > Key: SOLR-2957 > URL: https://issues.apache.org/jira/browse/SOLR-2957 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud, update >Reporter: Yonik Seeley >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2957.patch > > > In solrcloud, one can hit a URL of /collection1/select and get a distributed > search over collection1. > If we wish to maintain this, we'll need some more flexible URL to core > mapping since there may be more than one core for the collection on a node, > and the "collection1" core on that node could go away altogether. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3108) Error in SolrCloud's replica lookup code when replica's are hosted in same Solr instance
[ https://issues.apache.org/jira/browse/SOLR-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3108. --- Resolution: Fixed Thanks Sami and Bruno! > Error in SolrCloud's replica lookup code when replica's are hosted in same > Solr instance > > > Key: SOLR-3108 > URL: https://issues.apache.org/jira/browse/SOLR-3108 > Project: Solr > Issue Type: Bug > Components: SolrCloud > Environment: Solr trunk as of today (r1241575) >Reporter: Bruno Dumon >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-3108.patch, SOLR-3108.patch > > > There's a small bug in ZkStateReader.getReplicaProps() when you have multiple > replicas of the same shard/slice hosted in one CoreContainer. Not that you > would often do this, but I was playing around with shards & replicas using > just one Solr instance and noticed it. The attached patch should make it > clear, the check on !coreNodeName.equals(filterNodeName) will always be false > in such case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3091) When running in SolrCloud mode, whether a instance is supposed to be part of the quorum or not, it tries to start a local Solr ZK server.
[ https://issues.apache.org/jira/browse/SOLR-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3091. --- Resolution: Fixed > When running in SolrCloud mode, whether a instance is supposed to be part of > the quorum or not, it tries to start a local Solr ZK server. > - > > Key: SOLR-3091 > URL: https://issues.apache.org/jira/browse/SOLR-3091 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-3091.patch > > > When a Solr instance that is not part of the quorum tries to start the Solr > Zk server, no zkRun is set, and if not using localhost for the host, the ZK > server fails to start as we cannot match it with any URL in the zkHost > string. We shouldn't be trying to start the Zk Server at all - some bug that > snuck in and was not spotted earlier because it didn't manifest in Solr not > starting when using localhost addresses. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3082) If you use a lazy replication request handler, the commit listener will not be registered right away, and might miss tracking the last commit.
[ https://issues.apache.org/jira/browse/SOLR-3082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3082. --- Resolution: Fixed > If you use a lazy replication request handler, the commit listener will not > be registered right away, and might miss tracking the last commit. > -- > > Key: SOLR-3082 > URL: https://issues.apache.org/jira/browse/SOLR-3082 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-3082.patch > > > The result is that you might see version 0 as the latest commit version when > it's really not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2752) leader-per-shard
[ https://issues.apache.org/jira/browse/SOLR-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2752. --- Resolution: Fixed > leader-per-shard > > > Key: SOLR-2752 > URL: https://issues.apache.org/jira/browse/SOLR-2752 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Yonik Seeley >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2752.patch, SOLR-2752.patch, SOLR-2752.patch, > SOLR-2752.patch, SOLR-2752.patch > > > We need to add metadata into zookeeper about who is the leader for each > shard, and have some kind of leader election. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2962) I'd like to default the replication to be a master with replicateOnCommit when no request handler properties are specified.
[ https://issues.apache.org/jira/browse/SOLR-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2962. --- Resolution: Fixed this is in trunk now. > I'd like to default the replication to be a master with replicateOnCommit > when no request handler properties are specified. > --- > > Key: SOLR-2962 > URL: https://issues.apache.org/jira/browse/SOLR-2962 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > > Right now you would have to specify that the replication handler is a master > and to replicateAfterCommit for it to work properly with SolrCloud's recovery > process. It would be nicer if you just had to specify name="/replication" class="solr.ReplicationHandler" /> The request handler > master/slave concept does not really apply in SolrCloud. > This seems like it is a fine default, so I'd like to just change it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2806) If only one config set is in zk and a collection node does not explicitly have a config name set on its node, use the one config set.
[ https://issues.apache.org/jira/browse/SOLR-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2806. --- Resolution: Fixed > If only one config set is in zk and a collection node does not explicitly > have a config name set on its node, use the one config set. > - > > Key: SOLR-2806 > URL: https://issues.apache.org/jira/browse/SOLR-2806 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > > thought this was already the case but it's not - it's just if you use the > boot strap collection upload property, that conf set is written to the > collection node - more convient to do this as well I think -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2622) ShowFileRequestHandler does not work in SolrCloud mode.
[
https://issues.apache.org/jira/browse/SOLR-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller resolved SOLR-2622.
---
Resolution: Fixed
> ShowFileRequestHandler does not work in SolrCloud mode.
> ---
>
> Key: SOLR-2622
> URL: https://issues.apache.org/jira/browse/SOLR-2622
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud, web gui
> Environment: SVN-Revision: {{1139570}}
> Startup-Command: {{cd solr/example && java -Dbootstrap_confdir=./solr/conf
> -Dcollection.configName=myconf -DzkRun -jar start.jar}}
>Reporter: Stefan Matheis (steffkes)
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.0
>
>
> Requesting
> {{/solr/admin/file/?contentType=text/xml;charset=utf-8&file=schema.xml}}
> generates an HTTP 500:
> {code}org.apache.solr.common.cloud.ZooKeeperException: ZkSolrResourceLoader
> does not support getConfigDir() - likely, what you are trying to do is not
> supported in ZooKeeper mode
> at
> org.apache.solr.cloud.ZkSolrResourceLoader.getConfigDir(ZkSolrResourceLoader.java:99)
> at
> org.apache.solr.handler.admin.ShowFileRequestHandler.handleRequestBody(ShowFileRequestHandler.java:126)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:353)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:248)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:326)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
> at
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
> at
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582){code}
> It's not related to a specific file, requesting {{/solr/admin/file}} is
> enough.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2805) Add a main method to ZkController so that it's easier to script config upload with SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2805. --- Resolution: Fixed This is essentially done and in trunk - further improvements can get new issues. > Add a main method to ZkController so that it's easier to script config upload > with SolrCloud > > > Key: SOLR-2805 > URL: https://issues.apache.org/jira/browse/SOLR-2805 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > Attachments: jackhanna.zip > > > when scripting a cluster setup, it would be nice if it was easy to upload a > set of configs - otherwise you have to wait to start secondary servers until > the first server has uploaded the config - kind of a pain > You should be able to do something like: > java -classpath .:* org.apache.solr.cloud.ZkController 127.0.0.1:9983 > 127.0.0.1 8983 solr /home/mark/workspace/SolrCloud/solr/example/solr/conf > conf1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3065) Let overseer process cluster state changes asynchronously
[ https://issues.apache.org/jira/browse/SOLR-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3065. --- Resolution: Fixed > Let overseer process cluster state changes asynchronously > - > > Key: SOLR-3065 > URL: https://issues.apache.org/jira/browse/SOLR-3065 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 4.0 >Reporter: Sami Siren >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3065.patch > > > Currently the overseer updates clusterstate.json on almost every change - one > change at a time. This is not efficient when there are a lot of changes > happening in short period of time (for example when a number of hosts are > started at once). > It would be better if changes were published on timely manner instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3081) Default warming queries to distrib=false.
[ https://issues.apache.org/jira/browse/SOLR-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3081. --- Resolution: Fixed > Default warming queries to distrib=false. > - > > Key: SOLR-3081 > URL: https://issues.apache.org/jira/browse/SOLR-3081 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-3081.patch > > > We changed this default in general, but it seems warming queries still need > to default to distrib=false. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2312) CloudSolrServer -- calling add(Collection docs) throws NPE.
[
https://issues.apache.org/jira/browse/SOLR-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller resolved SOLR-2312.
---
Resolution: Cannot Reproduce
I can't reproduce this and a lot has changed in this area.
> CloudSolrServer -- calling add(Collection docs) throws NPE.
> --
>
> Key: SOLR-2312
> URL: https://issues.apache.org/jira/browse/SOLR-2312
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.0
> Environment: Mac OSX v10.5.8
> java version "1.6.0_22"
> Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-9M3263)
> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)
>Reporter: Stan Burnitt
>Assignee: Mark Miller
>Priority: Critical
> Fix For: 4.0
>
>
> Cannot index documents using the CloudSolrServer.
> Below is a code snippet that reproduces the error.
> {code:borderStyle=solid}
> @Test
> public void jiraTestCase() {
> CloudSolrServer solrj = null;
>
> try {
> solrj = new
> CloudSolrServer("your.zookeeper.localdomain:2181");
> // Also tried creating CloudSolrServer using
> alternative contstuctor below...
> // public CloudSolrServer(String zkHost,
> LBHttpSolrServer lbServer)
> //
> // LBHttpSolrServer lbHttpSolrServer = new
> LBHttpSolrServer("http://solr.localdomain:8983/solr";);
> // solrj = new
> CloudSolrServer("your.zookeeper.localdomain:2181", lbHttpSolrServer);
> //
> // (Same result -- NPE @ line 105 in
> CloudSolrServer.java)
> solrj.setDefaultCollection("your-collection");
> solrj.setZkClientTimeout(5000);
> solrj.setZkConnectTimeout(5000);
> final Collection batch = new
> ArrayList();
> SolrInputDocument doc = new SolrInputDocument();
> doc.addField("id", 1L, 1.0f);
> doc.addField("title", "Document A");
> doc.addField("description", "Test document");
> batch.add(doc);
> doc = new SolrInputDocument();
> doc.addField("id", 2L, 1.0f);
> doc.addField("title", "Document B");
> doc.addField("description", "Another test
> document");
> batch.add(doc);
> solrj.add(batch);
> } catch (Exception e) {
> log.error(e.getMessage(), e);
> Assert.fail("java.lang.NullPointerException:
> null \n"
> + " at
> org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:105)
> \n"
> + " Line 105: NULL request object here
> --> String collection = request.getParams().get(\"collection\",
> defaultCollection);");
> } finally {
> solrj.close();
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2287) SolrCloud - Allow users to query by multiple, compatible collections
[ https://issues.apache.org/jira/browse/SOLR-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2287. --- Resolution: Fixed This is in trunk now - thanks again! > SolrCloud - Allow users to query by multiple, compatible collections > > > Key: SOLR-2287 > URL: https://issues.apache.org/jira/browse/SOLR-2287 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Soheb Mahmood >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-2287.patch, SOLR-2287.patch, SOLR-2287.patch > > > This code fixes the todo items mentioned on the SolrCloud wiki: > -optionally allow user to query by collection > -optionally allow user to query by multiple collections (assume schemas are > compatible) > We are going to put a patch to see if anyone has any trouble with this code > and/or if there is any comments on how to improve this code. > Unfortunately, as of now, we don't have a test class as we are working on it. > We are sorry about this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2722) In solr.xml, default hostPort to ${jetty.port}
[
https://issues.apache.org/jira/browse/SOLR-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller resolved SOLR-2722.
---
Resolution: Fixed
> In solr.xml, default hostPort to ${jetty.port}
> --
>
> Key: SOLR-2722
> URL: https://issues.apache.org/jira/browse/SOLR-2722
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Trivial
> Fix For: 4.0
>
>
> Originally we didn't rely on jetty.port as it's container specific - but
> rather than require you specify the port twice in this case, we should simply
> use jetty.port when it's there.
> The example from the SolrCloud wiki:
> java -Djetty.port=7574 -DhostPort=7574 -DzkHost=localhost:9983 -jar start.jar
> instead becomes:
> java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar
> We should also look at simply specifying the shard name in this example case
> (see the solrwiki examples) by system property rather than asking the user to
> edit solr.xml.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2723) If you don't choose a shard name for a SolrCore, the system should auto assign shard names.
[ https://issues.apache.org/jira/browse/SOLR-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2723. --- Resolution: Fixed Thanks! > If you don't choose a shard name for a SolrCore, the system should auto > assign shard names. > --- > > Key: SOLR-2723 > URL: https://issues.apache.org/jira/browse/SOLR-2723 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > > When you first boot up a node with the collection files to use, you might > also pass how many slices you want - if you choose 3 slices, the first 3 > nodes that come up would each go to a different slice and get a unique shard > name - further nodes that come up would be replicas in each slice and get one > of the 3 shard names. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2880) Investigate adding an overseer that can assign shards, later do re-balancing, etc
[ https://issues.apache.org/jira/browse/SOLR-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2880. --- Resolution: Fixed Thanks Sami! > Investigate adding an overseer that can assign shards, later do re-balancing, > etc > - > > Key: SOLR-2880 > URL: https://issues.apache.org/jira/browse/SOLR-2880 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2880-merge-elections.patch, SOLR-2880.patch, > SOLR-2880.patch, SOLR-2880.patch, SOLR-2880.patch, SOLR-2880.patch, > SOLR-2880.patch, SOLR-2880.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2808) Node Recovery
[ https://issues.apache.org/jira/browse/SOLR-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2808. --- Resolution: Fixed > Node Recovery > - > > Key: SOLR-2808 > URL: https://issues.apache.org/jira/browse/SOLR-2808 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Yonik Seeley >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: TEST-org.apache.solr.cloud.RecoveryZkTest.xml > > > Node recovery encompasses everything involved in getting a node to the > "active" state after coming (back) up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2765) Shard/Node states
[ https://issues.apache.org/jira/browse/SOLR-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2765. --- Resolution: Fixed Assignee: Mark Miller Thanks! > Shard/Node states > - > > Key: SOLR-2765 > URL: https://issues.apache.org/jira/browse/SOLR-2765 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud, update >Reporter: Yonik Seeley >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: cluster_state-file.patch, combined.patch, > incremental_update.patch, scheduled_executors.patch, shard-roles.patch, > solrcloud.patch, solrcloud.patch, solrcloud.patch > > > Need state for shards that indicate they are recovering, active/enabled, or > disabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2821) Improve how cluster state is managed in ZooKeeper.
[ https://issues.apache.org/jira/browse/SOLR-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2821. --- Resolution: Fixed Thanks! > Improve how cluster state is managed in ZooKeeper. > -- > > Key: SOLR-2821 > URL: https://issues.apache.org/jira/browse/SOLR-2821 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2821.patch, noggit-1.0-SNAPSHOT.jar > > > Currently, we have issues supporting both incremental cluster state updates > (needed because reading the state with many ZK requests does not scale) and > allowing shard/node properties to change on the fly. We be nice to have a > solution that allows faster cluster state reads and easy on the fly > shard/node prop changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3075) Overseer does not check cloudstate for previously assigned shardId but generates a new one
[ https://issues.apache.org/jira/browse/SOLR-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3075. --- Resolution: Fixed Thanks Sami! Committed. > Overseer does not check cloudstate for previously assigned shardId but > generates a new one > -- > > Key: SOLR-3075 > URL: https://issues.apache.org/jira/browse/SOLR-3075 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 >Reporter: Sami Siren >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-3075.patch > > > Overseer does not check if core has already been assigned an shardId before > assigning it a new shardId -> same core could end up having multiple shardIds > in CloudState. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3063) Bug in LeaderElectionIntgrationTest
[ https://issues.apache.org/jira/browse/SOLR-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3063. --- Resolution: Fixed > Bug in LeaderElectionIntgrationTest > --- > > Key: SOLR-3063 > URL: https://issues.apache.org/jira/browse/SOLR-3063 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 >Reporter: Sami Siren >Assignee: Mark Miller >Priority: Minor > Attachments: SOLR-3063.patch > > > #getLeader() tries to get leader props from stale zkStateReader (one that has > not set watches). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2654) not used consistently in all places Directory objects are instantiated
[ https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2654. --- Resolution: Fixed > not used consistently in all places Directory objects are > instantiated > -- > > Key: SOLR-2654 > URL: https://issues.apache.org/jira/browse/SOLR-2654 > Project: Solr > Issue Type: Bug >Reporter: Hoss Man >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, > SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, > SOLR-2654.patch, SOLR-2698.patch > > > nipunb noted on the mailing list then when configuring solr to use an > alternate (ie: simple) the stats for the SolrIndexSearcher list > NativeFSLockFactory being used by the Directory. > The problem seems to be that SolrIndexConfig is not consulted when > constructing Directory objects used for IndexReader (it's only used by > SolrIndexWriter) > I don't _think_ this is a problem in most cases since the IndexReaders should > all be readOnly in the core solr code) but plugins could attempt to use them > in other ways. In general it seems like a really bad bug waiting to happen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2979) ShowFileRequestHandler should really also work with config files in ZooKeeper - our UI relies on it to see the solrconfig and schema.
[ https://issues.apache.org/jira/browse/SOLR-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2979. --- Resolution: Duplicate > ShowFileRequestHandler should really also work with config files in ZooKeeper > - our UI relies on it to see the solrconfig and schema. > - > > Key: SOLR-2979 > URL: https://issues.apache.org/jira/browse/SOLR-2979 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2807) Upgrade to Tika 0.10
[ https://issues.apache.org/jira/browse/SOLR-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2807. --- Resolution: Duplicate looks like this is a dupe of an issue that is resolved > Upgrade to Tika 0.10 > > > Key: SOLR-2807 > URL: https://issues.apache.org/jira/browse/SOLR-2807 > Project: Solr > Issue Type: Improvement >Reporter: Michael McCandless > Fix For: 3.5, 4.0 > > > Tika 0.10 was recently released... seems like we should upgrade? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2565) Prevent IW#close and cut over to IW#commit
[ https://issues.apache.org/jira/browse/SOLR-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2565. --- Resolution: Fixed > Prevent IW#close and cut over to IW#commit > -- > > Key: SOLR-2565 > URL: https://issues.apache.org/jira/browse/SOLR-2565 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 4.0 >Reporter: Simon Willnauer >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2565-revert.patch, SOLR-2565.patch, > SOLR-2565.patch, SOLR-2565.patch, SOLR-2565__HuperDuperAutoCommitTest.patch, > dump.txt, fix+hossmans-test.patch, slowtests.txt > > > Spinnoff from SOLR-2193. We already have a branch to work on this issue here > https://svn.apache.org/repos/asf/lucene/dev/branches/solr2193 > The main goal here is to prevent solr from closing the IW and use IW#commit > instead. AFAIK the main issues here are: > The update handler needs an overhaul. > A few goals I think we might want to look at: > 1. Expose the SolrIndexWriter in the api or add the proper abstractions to > get done what we now do with special casing: > 2. Stop closing the IndexWriter and start using commit (still lazy IW init > though). > 3. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level. > 4. Address the current issues we face because multiple original/'reloaded' > cores can have a different IndexWriter on the same index. > Eventually this is a preparation for NRT support in Solr which I will create > a followup issue for. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2799) SolrCloud reads its entire state from Zookeeper on every update instead of what has changed
[ https://issues.apache.org/jira/browse/SOLR-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2799. --- Resolution: Fixed Thanks Jamie! > SolrCloud reads its entire state from Zookeeper on every update instead of > what has changed > --- > > Key: SOLR-2799 > URL: https://issues.apache.org/jira/browse/SOLR-2799 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Jamie Johnson >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-2799.patch, cloudstate.patch, cloudstate.patch > > > Currently solrcloud reads the entire cloud state from ZK anytime an update is > scheduled which can be very inefficient with a large number of shards. > see discussion on user list: > http://www.lucidimagination.com/search/document/54fa402cf3171bc3/solr_cloud_number_of_shard_limitation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
