[jira] [Comment Edited] (SOLR-9925) Child documents missing from replicas during parallel delete+add
[ https://issues.apache.org/jira/browse/SOLR-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063663#comment-16063663 ] Brandon Chapman edited comment on SOLR-9925 at 6/26/17 8:52 PM: We have seen this same issue on Solr 6.4.2. If you send deleteByQuery, {noformat}"_root_ :THE_ROOT"{noformat} with an add for the same document in the same request, you can trigger this easily. In our case we had to use a deleteByQuery due to deleteById not working correctly on sharded collections. Our only solution is to go back to a non-sharded collection so we can use deleteById. Relevant ticket about deleteById being broken https://issues.apache.org/jira/browse/SOLR-8889 was (Author: bchapman): We have seen this same issue on Solr 6.4.2. If you send deleteByQuery, {noformat}"_root_ :THE_ROOT"{noformat} with an add for the same document in the same request, you can trigger this easily. In our case we had to use a deleteByQuery due to deleteById not working correctly on sharded collections. Our only solution is to go back to a non-sharded collection so we can use deleteById. > Child documents missing from replicas during parallel delete+add > > > Key: SOLR-9925 > URL: https://issues.apache.org/jira/browse/SOLR-9925 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 5.5.2, 6.3 > Environment: Java 1.8 (OpenJDK) on both CentOS 6.7 and Ubuntu 16.04.1 >Reporter: Dan Sirotzke > Attachments: generate.py, run.sh > > > When pushing documents to Solr in parallel, doing a delete-by-query and then > add for the same set of IDs within each thread results in some of the > replicas missing some of the child documents. All the parent documents are > successfully replicated. > This appears to trigger some sort of race condition, since: > * Documents are never missing from the leader. > * Documents _might_ be missing from the replicas. > * When they are missing, the number and which documents are different for > each replica and each run. > * It happens more easily with large documents; my test script needs a huge > number of documents to trigger it a small number of times, whereas it happens > ~5% of the time on our dataset. > * We're currently on Solr 5.5.2, but I've also managed to trigger it on 6.3.0 > * When not running anything in parallel, this doesn't occur. > Quick aside, since this is surely the first thing that will jump out: We > can't just do an update due to to the uniqueKey/\_root\_ issue behind > SOLR-5211. -- 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] [Comment Edited] (SOLR-9925) Child documents missing from replicas during parallel delete+add
[ https://issues.apache.org/jira/browse/SOLR-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063663#comment-16063663 ] Brandon Chapman edited comment on SOLR-9925 at 6/26/17 8:04 PM: We have seen this same issue on Solr 6.4.2. If you send deleteByQuery, {noformat}"_root_ :THE_ROOT"{noformat} with an add for the same document in the same request, you can trigger this easily. In our case we had to use a deleteByQuery due to deleteById not working correctly on sharded collections. Our only solution is to go back to a non-sharded collection so we can use deleteById. was (Author: bchapman): We have seen this same issue on Solr 6.4.2. If you send deleteByQuery {noformat}"_root_ :THE_ROOT"{noformat}, with an add for the same document in the same request, you can trigger this easily. In our case we had to use a deleteByQuery due to deleteById not working correctly on sharded collections. Our only solution is to go back to a non-sharded collection so we can use deleteById. > Child documents missing from replicas during parallel delete+add > > > Key: SOLR-9925 > URL: https://issues.apache.org/jira/browse/SOLR-9925 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 5.5.2, 6.3 > Environment: Java 1.8 (OpenJDK) on both CentOS 6.7 and Ubuntu 16.04.1 >Reporter: Dan Sirotzke > Attachments: generate.py, run.sh > > > When pushing documents to Solr in parallel, doing a delete-by-query and then > add for the same set of IDs within each thread results in some of the > replicas missing some of the child documents. All the parent documents are > successfully replicated. > This appears to trigger some sort of race condition, since: > * Documents are never missing from the leader. > * Documents _might_ be missing from the replicas. > * When they are missing, the number and which documents are different for > each replica and each run. > * It happens more easily with large documents; my test script needs a huge > number of documents to trigger it a small number of times, whereas it happens > ~5% of the time on our dataset. > * We're currently on Solr 5.5.2, but I've also managed to trigger it on 6.3.0 > * When not running anything in parallel, this doesn't occur. > Quick aside, since this is surely the first thing that will jump out: We > can't just do an update due to to the uniqueKey/\_root\_ issue behind > SOLR-5211. -- 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] [Comment Edited] (SOLR-9925) Child documents missing from replicas during parallel delete+add
[ https://issues.apache.org/jira/browse/SOLR-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063663#comment-16063663 ] Brandon Chapman edited comment on SOLR-9925 at 6/26/17 8:04 PM: We have seen this same issue on Solr 6.4.2. If you send deleteByQuery {noformat}"_root_ :THE_ROOT"{noformat}, with an add for the same document in the same request, you can trigger this easily. In our case we had to use a deleteByQuery due to deleteById not working correctly on sharded collections. Our only solution is to go back to a non-sharded collection so we can use deleteById. was (Author: bchapman): We have seen this same issue on Solr 6.4.2. If you send deleteByQuery "_root_:THE_ROOT", with an add for the same document in the same request, you can trigger this easily. In our case we had to use a deleteByQuery due to deleteById not working correctly on sharded collections. Our only solution is to go back to a non-sharded collection so we can use deleteById. > Child documents missing from replicas during parallel delete+add > > > Key: SOLR-9925 > URL: https://issues.apache.org/jira/browse/SOLR-9925 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 5.5.2, 6.3 > Environment: Java 1.8 (OpenJDK) on both CentOS 6.7 and Ubuntu 16.04.1 >Reporter: Dan Sirotzke > Attachments: generate.py, run.sh > > > When pushing documents to Solr in parallel, doing a delete-by-query and then > add for the same set of IDs within each thread results in some of the > replicas missing some of the child documents. All the parent documents are > successfully replicated. > This appears to trigger some sort of race condition, since: > * Documents are never missing from the leader. > * Documents _might_ be missing from the replicas. > * When they are missing, the number and which documents are different for > each replica and each run. > * It happens more easily with large documents; my test script needs a huge > number of documents to trigger it a small number of times, whereas it happens > ~5% of the time on our dataset. > * We're currently on Solr 5.5.2, but I've also managed to trigger it on 6.3.0 > * When not running anything in parallel, this doesn't occur. > Quick aside, since this is surely the first thing that will jump out: We > can't just do an update due to to the uniqueKey/\_root\_ issue behind > SOLR-5211. -- 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-9925) Child documents missing from replicas during parallel delete+add
[ https://issues.apache.org/jira/browse/SOLR-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063663#comment-16063663 ] Brandon Chapman commented on SOLR-9925: --- We have seen this same issue on Solr 6.4.2. If you send deleteByQuery "_root_:THE_ROOT", with an add for the same document in the same request, you can trigger this easily. In our case we had to use a deleteByQuery due to deleteById not working correctly on sharded collections. Our only solution is to go back to a non-sharded collection so we can use deleteById. > Child documents missing from replicas during parallel delete+add > > > Key: SOLR-9925 > URL: https://issues.apache.org/jira/browse/SOLR-9925 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 5.5.2, 6.3 > Environment: Java 1.8 (OpenJDK) on both CentOS 6.7 and Ubuntu 16.04.1 >Reporter: Dan Sirotzke > Attachments: generate.py, run.sh > > > When pushing documents to Solr in parallel, doing a delete-by-query and then > add for the same set of IDs within each thread results in some of the > replicas missing some of the child documents. All the parent documents are > successfully replicated. > This appears to trigger some sort of race condition, since: > * Documents are never missing from the leader. > * Documents _might_ be missing from the replicas. > * When they are missing, the number and which documents are different for > each replica and each run. > * It happens more easily with large documents; my test script needs a huge > number of documents to trigger it a small number of times, whereas it happens > ~5% of the time on our dataset. > * We're currently on Solr 5.5.2, but I've also managed to trigger it on 6.3.0 > * When not running anything in parallel, this doesn't occur. > Quick aside, since this is surely the first thing that will jump out: We > can't just do an update due to to the uniqueKey/\_root\_ issue behind > SOLR-5211. -- 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] [Comment Edited] (SOLR-7435) NPE in FieldCollapsingQParser
[ https://issues.apache.org/jira/browse/SOLR-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14735003#comment-14735003 ] Brandon Chapman edited comment on SOLR-7435 at 9/8/15 3:40 PM: --- [~joel.bernstein], this also sometimes works sometimes gets an exception for me in Solr 4.10.3. {code} {code} {code} { "responseHeader": { "status": 500, "QTime": 89, "params": { "facet": "true", "fl": "psid, bsin, groupId, sku, merchant", "indent": "true", "q": "type_s:parent", "_": "1441726236828", "facet.field": "bsin", "wt": "json", "fq": [ "{!collapse field=groupId min=sourceRank cost=201}", "{!collapse field=merchant cost=200}" ], "rows": "10" } }, "error": { "trace": "java.lang.NullPointerException\n\tat org.apache.solr.search.CollapsingQParserPlugin$CollapsingFieldValueCollector.finish(CollapsingQParserPlugin.java:632)\n\tat org.apache.solr.search.CollapsingQParserPlugin$CollapsingScoreCollector.finish(CollapsingQParserPlugin.java:525)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocSetScore(SolrIndexSearcher.java:918)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:938)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1366)\n\tat org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:514)\n\tat org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:484)\n\tat org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)\n\tat org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)\n\tat org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)\n\tat org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)\n\tat org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)\n\tat org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)\n\tat org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)\n\tat org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)\n\tat org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)\n\tat org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)\n\tat org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)\n\tat org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)\n\tat org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)\n\tat org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat java.lang.Thread.run(Thread.java:744)\n", "code": 500 } } {code} was (Author: bchapman): [~joel.bernstein], this also sometimes works sometimes gets an exception for me in Solr 4.10.3. {code} { "responseHeader": { "status": 500, "QTime": 89, "params": { "facet": "true", "fl": "psid, bsin, groupId, sku, merchant", "indent": "true", "q": "type_s:parent", "_": "1441726236828", "facet.field": "bsin", "wt": "json", "fq": [ "{!collapse field=groupId min=sourceRank cost=201}", "{!collapse field=merchant cost=200}" ], "rows": "10" } }, "error": { "trace": "java.lang.NullPointerException\n\tat org.apache.solr.search.CollapsingQParserPlugin$CollapsingFieldValueCollector.finish(CollapsingQParserPlugin.java:632)\n\tat org.apache.solr.search.CollapsingQParserPlugin$CollapsingScoreCollector.finish(CollapsingQParserPlugin.java:525)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocSetScore(SolrIndexSearcher.java:918)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:938)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1366)\n\tat org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:514)\n\tat org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:484)\n\tat org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)\n\tat org.apache.solr.handler.RequestHandlerBase.handleRequest(Req
[jira] [Comment Edited] (SOLR-7435) NPE in FieldCollapsingQParser
[ https://issues.apache.org/jira/browse/SOLR-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14735003#comment-14735003 ] Brandon Chapman edited comment on SOLR-7435 at 9/8/15 3:40 PM: --- [~joel.bernstein], this also sometimes works sometimes gets an exception for me in Solr 4.10.3. {code} {code} {code} { "responseHeader": { "status": 500, "QTime": 89, "params": { "facet": "true", "fl": "psid, bsin, groupId, sku, merchant", "indent": "true", "q": "type_s:parent", "_": "1441726236828", "facet.field": "bsin", "wt": "json", "fq": [ "{!collapse field=groupId min=sourceRank cost=201}", "{!collapse field=merchant cost=200}" ], "rows": "10" } }, "error": { "trace": "java.lang.NullPointerException\n\tat org.apache.solr.search.CollapsingQParserPlugin$CollapsingFieldValueCollector.finish(CollapsingQParserPlugin.java:632)\n\tat org.apache.solr.search.CollapsingQParserPlugin$CollapsingScoreCollector.finish(CollapsingQParserPlugin.java:525)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocSetScore(SolrIndexSearcher.java:918)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:938)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1366)\n\tat org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:514)\n\tat org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:484)\n\tat org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)\n\tat org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)\n\tat org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)\n\tat org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)\n\tat org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)\n\tat org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)\n\tat org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)\n\tat org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)\n\tat org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)\n\tat org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)\n\tat org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)\n\tat org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)\n\tat org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)\n\tat org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat java.lang.Thread.run(Thread.java:744)\n", "code": 500 } } {code} was (Author: bchapman): [~joel.bernstein], this also sometimes works sometimes gets an exception for me in Solr 4.10.3. {code} {code} {code} { "responseHeader": { "status": 500, "QTime": 89, "params": { "facet": "true", "fl": "psid, bsin, groupId, sku, merchant", "indent": "true", "q": "type_s:parent", "_": "1441726236828", "facet.field": "bsin", "wt": "json", "fq": [ "{!collapse field=groupId min=sourceRank cost=201}", "{!collapse field=merchant cost=200}" ], "rows": "10" } }, "error": { "trace": "java.lang.NullPointerException\n\tat org.apache.solr.search.CollapsingQParserPlugin$CollapsingFieldValueCollector.finish(CollapsingQParserPlugin.java:632)\n\tat org.apache.solr.search.CollapsingQParserPlugin$CollapsingScoreCollector.finish(CollapsingQParserPlugin.java:525)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocSetScore(SolrIndexSearcher.java:918)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:938)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1366)\n\tat org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:514)\n\tat org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:484)\n\tat org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)\n\tat org.apache.solr.han
[jira] [Commented] (SOLR-7435) NPE in FieldCollapsingQParser
[ https://issues.apache.org/jira/browse/SOLR-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14735003#comment-14735003 ] Brandon Chapman commented on SOLR-7435: --- [~joel.bernstein], this also sometimes works sometimes gets an exception for me in Solr 4.10.3. {code} { "responseHeader": { "status": 500, "QTime": 89, "params": { "facet": "true", "fl": "psid, bsin, groupId, sku, merchant", "indent": "true", "q": "type_s:parent", "_": "1441726236828", "facet.field": "bsin", "wt": "json", "fq": [ "{!collapse field=groupId min=sourceRank cost=201}", "{!collapse field=merchant cost=200}" ], "rows": "10" } }, "error": { "trace": "java.lang.NullPointerException\n\tat org.apache.solr.search.CollapsingQParserPlugin$CollapsingFieldValueCollector.finish(CollapsingQParserPlugin.java:632)\n\tat org.apache.solr.search.CollapsingQParserPlugin$CollapsingScoreCollector.finish(CollapsingQParserPlugin.java:525)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocSetScore(SolrIndexSearcher.java:918)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:938)\n\tat org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1366)\n\tat org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:514)\n\tat org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:484)\n\tat org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)\n\tat org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)\n\tat org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)\n\tat org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)\n\tat org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)\n\tat org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)\n\tat org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)\n\tat org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)\n\tat org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)\n\tat org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)\n\tat org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)\n\tat org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)\n\tat org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)\n\tat org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat java.lang.Thread.run(Thread.java:744)\n", "code": 500 } } {code} > NPE in FieldCollapsingQParser > - > > Key: SOLR-7435 > URL: https://issues.apache.org/jira/browse/SOLR-7435 > Project: Solr > Issue Type: Bug >Affects Versions: 5.1 >Reporter: Markus Jelsma >Priority: Minor > Fix For: 5.2 > > > Not even sure it would work anyway, i tried to collapse on two distinct > fields, ending up with this: > select?q=*:*&fq={!collapse field=qst}&fq={!collapse field=rdst} > {code} > 584550 [qtp1121454968-20] ERROR org.apache.solr.servlet.SolrDispatchFilter [ > suggests] – null:java.lang.NullPointerException > at > org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:743) > at > org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:780) > at > org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:203) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1660) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1479) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:556) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:518) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222) > at > org.apache.solr.handler.RequestHandlerBase
[jira] [Commented] (SOLR-7363) Expand component throws an Exception when the results have been collapsed and grouped
[ https://issues.apache.org/jira/browse/SOLR-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14523140#comment-14523140 ] Brandon Chapman commented on SOLR-7363: --- Thanks, I take a look at the highlighting component when I get a chance. > Expand component throws an Exception when the results have been collapsed and > grouped > - > > Key: SOLR-7363 > URL: https://issues.apache.org/jira/browse/SOLR-7363 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Affects Versions: 4.10.3 >Reporter: Brandon Chapman > > The expand component does not work when used on a result that has been both > collapsed and grouped. This is counter-intuitive as collapsing and grouping > work together with no issues. > {code} > { > "responseHeader":{ > "status":500, > "QTime":1198, > "params":{ > "fl":"psid", > "indent":"true", > "q":"*:*", > "expand":"true", > "group.field":"merchant", > "group":"true", > "wt":"json", > "fq":"{!collapse field=groupId}", > "rows":"1"}}, > "grouped":{ > "merchant":{ > "matches":71652, > "groups":[{ > "groupValue":"sears", > "doclist":{"numFound":30672,"start":0,"docs":[ > { > "psid":"3047500675628000"}] > }}]}}, > "error":{ > "trace":"java.lang.NullPointerException\n\tat > org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:193)\n\tat > > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)\n\tat > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat > org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)\n\tat > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)\n\tat > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)\n\tat > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)\n\tat > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)\n\tat > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)\n\tat > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)\n\tat > > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)\n\tat > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)\n\tat > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)\n\tat > > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)\n\tat > > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)\n\tat > > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)\n\tat > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\n\tat > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat > java.lang.Thread.run(Thread.java:744)\n", > "code":500}} > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7363) Expand component throws an Exception when the results have been collapsed and grouped
[ https://issues.apache.org/jira/browse/SOLR-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521995#comment-14521995 ] Brandon Chapman commented on SOLR-7363: --- [~joel.bernstein], did you get a chance to evaluate this? > Expand component throws an Exception when the results have been collapsed and > grouped > - > > Key: SOLR-7363 > URL: https://issues.apache.org/jira/browse/SOLR-7363 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Affects Versions: 4.10.3 >Reporter: Brandon Chapman > > The expand component does not work when used on a result that has been both > collapsed and grouped. This is counter-intuitive as collapsing and grouping > work together with no issues. > {code} > { > "responseHeader":{ > "status":500, > "QTime":1198, > "params":{ > "fl":"psid", > "indent":"true", > "q":"*:*", > "expand":"true", > "group.field":"merchant", > "group":"true", > "wt":"json", > "fq":"{!collapse field=groupId}", > "rows":"1"}}, > "grouped":{ > "merchant":{ > "matches":71652, > "groups":[{ > "groupValue":"sears", > "doclist":{"numFound":30672,"start":0,"docs":[ > { > "psid":"3047500675628000"}] > }}]}}, > "error":{ > "trace":"java.lang.NullPointerException\n\tat > org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:193)\n\tat > > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)\n\tat > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat > org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)\n\tat > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)\n\tat > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)\n\tat > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)\n\tat > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)\n\tat > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)\n\tat > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)\n\tat > > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)\n\tat > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)\n\tat > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)\n\tat > > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)\n\tat > > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)\n\tat > > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)\n\tat > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\n\tat > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat > java.lang.Thread.run(Thread.java:744)\n", > "code":500}} > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7363) Expand component throws an Exception when the results have been collapsed and grouped
[ https://issues.apache.org/jira/browse/SOLR-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14485268#comment-14485268 ] Brandon Chapman commented on SOLR-7363: --- [~joel.bernstein], when collapsing was introduced, "traditional" grouping was explicitly supported. Is this just an oversight that expanding the collapsed result does not work if the result has also been grouped or is there a technical limitation? > Expand component throws an Exception when the results have been collapsed and > grouped > - > > Key: SOLR-7363 > URL: https://issues.apache.org/jira/browse/SOLR-7363 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Affects Versions: 4.10.3 >Reporter: Brandon Chapman > > The expand component does not work when used on a result that has been both > collapsed and grouped. This is counter-intuitive as collapsing and grouping > work together with no issues. > {code} > { > "responseHeader":{ > "status":500, > "QTime":1198, > "params":{ > "fl":"psid", > "indent":"true", > "q":"*:*", > "expand":"true", > "group.field":"merchant", > "group":"true", > "wt":"json", > "fq":"{!collapse field=groupId}", > "rows":"1"}}, > "grouped":{ > "merchant":{ > "matches":71652, > "groups":[{ > "groupValue":"sears", > "doclist":{"numFound":30672,"start":0,"docs":[ > { > "psid":"3047500675628000"}] > }}]}}, > "error":{ > "trace":"java.lang.NullPointerException\n\tat > org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:193)\n\tat > > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)\n\tat > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat > org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)\n\tat > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)\n\tat > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)\n\tat > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)\n\tat > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)\n\tat > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)\n\tat > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)\n\tat > > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)\n\tat > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)\n\tat > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)\n\tat > > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)\n\tat > > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)\n\tat > > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)\n\tat > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\n\tat > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat > java.lang.Thread.run(Thread.java:744)\n", > "code":500}} > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7363) Expand component throws an Exception when the results have been collapsed and grouped
Brandon Chapman created SOLR-7363: - Summary: Expand component throws an Exception when the results have been collapsed and grouped Key: SOLR-7363 URL: https://issues.apache.org/jira/browse/SOLR-7363 Project: Solr Issue Type: Bug Components: SearchComponents - other Affects Versions: 4.10.3 Reporter: Brandon Chapman The expand component does not work when used on a result that has been both collapsed and grouped. This is counter-intuitive as collapsing and grouping work together with no issues. {code} { "responseHeader":{ "status":500, "QTime":1198, "params":{ "fl":"psid", "indent":"true", "q":"*:*", "expand":"true", "group.field":"merchant", "group":"true", "wt":"json", "fq":"{!collapse field=groupId}", "rows":"1"}}, "grouped":{ "merchant":{ "matches":71652, "groups":[{ "groupValue":"sears", "doclist":{"numFound":30672,"start":0,"docs":[ { "psid":"3047500675628000"}] }}]}}, "error":{ "trace":"java.lang.NullPointerException\n\tat org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:193)\n\tat org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)\n\tat org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)\n\tat org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)\n\tat org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)\n\tat org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)\n\tat org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)\n\tat org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)\n\tat org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)\n\tat org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)\n\tat org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)\n\tat org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)\n\tat org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)\n\tat org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)\n\tat org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat java.lang.Thread.run(Thread.java:744)\n", "code":500}} {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6136) ConcurrentUpdateSolrServer includes a Spin Lock
[ https://issues.apache.org/jira/browse/SOLR-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Chapman updated SOLR-6136: -- Attachment: wait___notify_all.patch Attached patch for Solr 4.7.1 drastically improves performance. The patch is a workaround of the spin lock by using a simple wait / notify mechanism. It is not a suggestion on how to fix ConcurrentUpdateSolrServer for an official release. > ConcurrentUpdateSolrServer includes a Spin Lock > --- > > Key: SOLR-6136 > URL: https://issues.apache.org/jira/browse/SOLR-6136 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.6, 4.6.1, 4.7, 4.7.1, 4.7.2, 4.8, 4.8.1 >Reporter: Brandon Chapman >Priority: Critical > Attachments: wait___notify_all.patch > > > ConcurrentUpdateSolrServer.blockUntilFinished() includes a Spin Lock. This > causes an extremely high amount of CPU to be used on the Cloud Leader during > indexing. > Here is a summary of our system testing. > Importing data on Solr4.5.0: > Throughput gets as high as 240 documents per second. > [tomcat@solr-stg01 logs]$ uptime > 09:53:50 up 310 days, 23:52, 1 user, load average: 3.33, 3.72, 5.43 > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 9547 tomcat 21 0 6850m 1.2g 16m S 86.2 5.0 1:48.81 java > Importing data on Solr4.7.0 with no replicas: > Throughput peaks at 350 documents per second. > [tomcat@solr-stg01 logs]$ uptime > 10:03:44 up 311 days, 2 min, 1 user, load average: 4.57, 2.55, 4.18 > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 9728 tomcat 23 0 6859m 2.2g 28m S 62.3 9.0 2:20.20 java > Importing data on Solr4.7.0 with replicas: > Throughput peaks at 30 documents per second because the Solr machine is out > of CPU. > [tomcat@solr-stg01 logs]$ uptime > 09:40:04 up 310 days, 23:38, 1 user, load average: 30.54, 12.39, 4.79 > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 9190 tomcat 17 0 7005m 397m 15m S 198.5 1.6 7:14.87 java -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6136) ConcurrentUpdateSolrServer includes a Spin Lock
[ https://issues.apache.org/jira/browse/SOLR-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14017838#comment-14017838 ] Brandon Chapman commented on SOLR-6136: --- Applying the patch from the linked ticket to Solr 4.5 will cause the same issue to be present in Solr 4.5. > ConcurrentUpdateSolrServer includes a Spin Lock > --- > > Key: SOLR-6136 > URL: https://issues.apache.org/jira/browse/SOLR-6136 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.6, 4.6.1, 4.7, 4.7.1, 4.7.2, 4.8, 4.8.1 >Reporter: Brandon Chapman >Priority: Critical > > ConcurrentUpdateSolrServer.blockUntilFinished() includes a Spin Lock. This > causes an extremely high amount of CPU to be used on the Cloud Leader during > indexing. > Here is a summary of our system testing. > Importing data on Solr4.5.0: > Throughput gets as high as 240 documents per second. > [tomcat@solr-stg01 logs]$ uptime > 09:53:50 up 310 days, 23:52, 1 user, load average: 3.33, 3.72, 5.43 > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 9547 tomcat 21 0 6850m 1.2g 16m S 86.2 5.0 1:48.81 java > Importing data on Solr4.7.0 with no replicas: > Throughput peaks at 350 documents per second. > [tomcat@solr-stg01 logs]$ uptime > 10:03:44 up 311 days, 2 min, 1 user, load average: 4.57, 2.55, 4.18 > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 9728 tomcat 23 0 6859m 2.2g 28m S 62.3 9.0 2:20.20 java > Importing data on Solr4.7.0 with replicas: > Throughput peaks at 30 documents per second because the Solr machine is out > of CPU. > [tomcat@solr-stg01 logs]$ uptime > 09:40:04 up 310 days, 23:38, 1 user, load average: 30.54, 12.39, 4.79 > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 9190 tomcat 17 0 7005m 397m 15m S 198.5 1.6 7:14.87 java -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6136) ConcurrentUpdateSolrServer includes a Spin Lock
Brandon Chapman created SOLR-6136: - Summary: ConcurrentUpdateSolrServer includes a Spin Lock Key: SOLR-6136 URL: https://issues.apache.org/jira/browse/SOLR-6136 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.8.1, 4.8, 4.7.2, 4.7.1, 4.7, 4.6.1, 4.6 Reporter: Brandon Chapman Priority: Critical ConcurrentUpdateSolrServer.blockUntilFinished() includes a Spin Lock. This causes an extremely high amount of CPU to be used on the Cloud Leader during indexing. Here is a summary of our system testing. Importing data on Solr4.5.0: Throughput gets as high as 240 documents per second. [tomcat@solr-stg01 logs]$ uptime 09:53:50 up 310 days, 23:52, 1 user, load average: 3.33, 3.72, 5.43 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9547 tomcat 21 0 6850m 1.2g 16m S 86.2 5.0 1:48.81 java Importing data on Solr4.7.0 with no replicas: Throughput peaks at 350 documents per second. [tomcat@solr-stg01 logs]$ uptime 10:03:44 up 311 days, 2 min, 1 user, load average: 4.57, 2.55, 4.18 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9728 tomcat 23 0 6859m 2.2g 28m S 62.3 9.0 2:20.20 java Importing data on Solr4.7.0 with replicas: Throughput peaks at 30 documents per second because the Solr machine is out of CPU. [tomcat@solr-stg01 logs]$ uptime 09:40:04 up 310 days, 23:38, 1 user, load average: 30.54, 12.39, 4.79 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9190 tomcat 17 0 7005m 397m 15m S 198.5 1.6 7:14.87 java -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821735#comment-13821735 ] Brandon Chapman commented on SOLR-5408: --- Joel, The file you provided worked. I did a brief test in our staging environment for the sorting and ran all our integration tests. Thanks, Brandon > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: CollapsingQParserPlugin.java, > CollapsingQParserPlugin.java, SOLR-5027.patch, SOLR-5408.2.patch, > SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Chapman updated SOLR-5408: -- Attachment: CollapsingQParserPlugin.java attaching java file instead of patch > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: CollapsingQParserPlugin.java, SOLR-5027.patch, > SOLR-5408.2.patch, SOLR-5408.patch, SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
[ https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Chapman updated SOLR-5408: -- Attachment: SOLR-5027.patch Attached patch that we are using. > Collapsing Query Parser does not respect multiple Sort fields > - > > Key: SOLR-5408 > URL: https://issues.apache.org/jira/browse/SOLR-5408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Brandon Chapman >Assignee: Joel Bernstein >Priority: Critical > Attachments: SOLR-5027.patch, SOLR-5408.2.patch, SOLR-5408.patch, > SOLR-5408.patch > > > When using the collapsing query parser, only the last sort field appears to > be used. > http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} > > > 3002010250210 > > ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) > > 0.41423172 > > The same query without using the collapsing query parser produces the > expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields
Brandon Chapman created SOLR-5408: - Summary: Collapsing Query Parser does not respect multiple Sort fields Key: SOLR-5408 URL: https://issues.apache.org/jira/browse/SOLR-5408 Project: Solr Issue Type: Bug Affects Versions: 4.5 Reporter: Brandon Chapman Priority: Critical When using the collapsing query parser, only the last sort field appears to be used. http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20desc&qf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_eng&pf2=name_eng^2&defType=edismax&rows=12&pf=name_eng~5^3&start=0&q=ipad&boost=sqrt(popularity)&qt=/select_eng&fq=productType:MERCHANDISE&fq=merchant:bestbuycanada&fq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)&fq=translations:eng&fl=psid,name_eng,score&debug=true&debugQuery=true&fq={!collapse+field%3DgroupId+nullPolicy%3Dexpand} 3002010250210 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD) 0.41423172 The same query without using the collapsing query parser produces the expected result. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org