[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=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=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=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=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=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
[jira] [Commented] (SOLR-7435) NPE in FieldCollapsingQParser
[
https://issues.apache.org/jira/browse/SOLR-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=*:*={!collapse field=qst}={!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
>
[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=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
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] [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-6136) ConcurrentUpdateSolrServer includes a Spin Lock
[ https://issues.apache.org/jira/browse/SOLR-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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-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-tabpanelfocusedCommentId=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%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+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:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
result name=response numFound=5927 start=0 maxScore=5.6674457
doc
str name=psid3002010250210/str
str name=name_eng
ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
/str
float name=score0.41423172/float
/doc
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%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+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:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
result name=response numFound=5927 start=0 maxScore=5.6674457
doc
str name=psid3002010250210/str
str name=name_eng
ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
/str
float name=score0.41423172/float
/doc
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%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+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:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
result name=response numFound=5927 start=0 maxScore=5.6674457
doc
str name=psid3002010250210/str
str name=name_eng
ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
/str
float name=score0.41423172/float
/doc
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%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+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:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
result name=response numFound=5927 start=0 maxScore=5.6674457
doc
str name=psid3002010250210/str
str name=name_eng
ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
/str
float name=score0.41423172/float
/doc
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
