[jira] [Commented] (SOLR-9616) Solr throws exception when expand=true on empty result
[
https://issues.apache.org/jira/browse/SOLR-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15562127#comment-15562127
]
Timo Schmidt commented on SOLR-9616:
6.0.0 is not affected
> Solr throws exception when expand=true on empty result
> --
>
> Key: SOLR-9616
> URL: https://issues.apache.org/jira/browse/SOLR-9616
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.2.1
>Reporter: Timo Schmidt
>Priority: Critical
> Fix For: 6.2.1
>
>
> When i run a query with expand=true with field collapsing and the result set
> is empty an exception is thrown:
> solr:8984/solr/core_en/select?={!collapse
> field=pid}=true=10
> Produces:
> "error":{
> "msg":"Index: 0, Size: 0",
> "trace":"java.lang.IndexOutOfBoundsException: Index: 0, Size: 0\n\tat
> java.util.ArrayList.rangeCheck(ArrayList.java:653)\n\tat
> java.util.ArrayList.get(ArrayList.java:429)\n\tat
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)\n\tat
> org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:269)\n\tat
>
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:293)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)\n\tat
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:657)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)\n\tat
> java.lang.Thread.run(Thread.java:745)\n",
> "code":500}}
> Instead i would assume to get an empty result.
> Is this a bug?
--
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-9616) Solr throws exception when expand=true on empty result
[
https://issues.apache.org/jira/browse/SOLR-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15562057#comment-15562057
]
Timo Schmidt commented on SOLR-9616:
The behaviour is the same in 6.1.0
> Solr throws exception when expand=true on empty result
> --
>
> Key: SOLR-9616
> URL: https://issues.apache.org/jira/browse/SOLR-9616
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.2.1
>Reporter: Timo Schmidt
>Priority: Critical
> Fix For: 6.2.1
>
>
> When i run a query with expand=true with field collapsing and the result set
> is empty an exception is thrown:
> solr:8984/solr/core_en/select?={!collapse
> field=pid}=true=10
> Produces:
> "error":{
> "msg":"Index: 0, Size: 0",
> "trace":"java.lang.IndexOutOfBoundsException: Index: 0, Size: 0\n\tat
> java.util.ArrayList.rangeCheck(ArrayList.java:653)\n\tat
> java.util.ArrayList.get(ArrayList.java:429)\n\tat
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)\n\tat
> org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:269)\n\tat
>
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:293)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)\n\tat
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:657)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)\n\tat
> java.lang.Thread.run(Thread.java:745)\n",
> "code":500}}
> Instead i would assume to get an empty result.
> Is this a bug?
--
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-9616) Solr throws exception when expand=true on empty result
Timo Schmidt created SOLR-9616:
--
Summary: Solr throws exception when expand=true on empty result
Key: SOLR-9616
URL: https://issues.apache.org/jira/browse/SOLR-9616
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.2.1
Reporter: Timo Schmidt
Priority: Critical
Fix For: 6.2.1
When i run a query with expand=true with field collapsing and the result set is
empty an exception is thrown:
solr:8984/solr/core_en/select?={!collapse
field=pid}=true=10
Produces:
"error":{
"msg":"Index: 0, Size: 0",
"trace":"java.lang.IndexOutOfBoundsException: Index: 0, Size: 0\n\tat
java.util.ArrayList.rangeCheck(ArrayList.java:653)\n\tat
java.util.ArrayList.get(ArrayList.java:429)\n\tat
java.util.Collections$UnmodifiableList.get(Collections.java:1309)\n\tat
org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:269)\n\tat
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:293)\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat
org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)\n\tat
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:657)\n\tat
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\n\tat
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)\n\tat
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)\n\tat
java.lang.Thread.run(Thread.java:745)\n",
"code":500}}
Instead i would assume to get an empty result.
Is this a bug?
--
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-5046) IllegalArgumentException using distributed group.query when one shard does not match any docs
[
https://issues.apache.org/jira/browse/SOLR-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timo Schmidt updated SOLR-5046:
---
Attachment: 0002-Get-distributed-grouping-request-work-with-sort-with.patch
Added a second version of the patch, with tests for grouping by query, without
any sorting and with group.sort.
The group.sort does not work for all cases, there is a uncommented failing
testcase for this as well.
It would be nice when somebody could review this patch and we can get the
grouping working in this case.
IllegalArgumentException using distributed group.query when one shard does
not match any docs
-
Key: SOLR-5046
URL: https://issues.apache.org/jira/browse/SOLR-5046
Project: Solr
Issue Type: Bug
Affects Versions: 4.3
Reporter: Hoss Man
Attachments:
0001-Get-distributed-grouping-request-work-with-sort-with.patch,
0002-Get-distributed-grouping-request-work-with-sort-with.patch
[Evgeny Salnikov noted this problem on the mailing
list|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201307.mbox/%3CCADz7Cx6PbMxExhb8gsCu9%3DP6nphJd2fYayov_%3D%3D%2Bo1sEXswWLw%40mail.gmail.com%3E],
although the initial report was somewhat convoluted by suspicious
description of adding shards after the fact.
Steps to reproduce using 4.3.1 example...
* startup a 2 node SolrCloud cluster following the Example A description on
the SolrCloud wiki...
** cp example example2
** cd example java -Dbootstrap_confdir=./solr/collection1/conf
-Dcollection.configName=myconf -DzkRun -DnumShards=2 -jar start.jar
** cd example2 java -Djetty.port=7574 -DzkHost=localhost:9983 -jar
start.jar
* index exactly one doc (to ensure that subsequent distributed queries get
results from only one node)
** java -jar post.jar utf8-example.xml
* execute a request using group.query
** http://localhost:7574/solr/select?q=*:*group=truegroup.query=cat:software
stack trace...
{noformat}
166500 [qtp2092063645-19] ERROR org.apache.solr.servlet.SolrDispatchFilter –
null:java.lang.IllegalArgumentException: shard 1 did not set sort field
values (FieldDoc.fields is null); you must pass fillFields=true to
IndexSearcher.search on each shard
at
org.apache.lucene.search.TopDocs$MergeSortQueue.init(TopDocs.java:143)
at org.apache.lucene.search.TopDocs.merge(TopDocs.java:214)
at
org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:114)
at
org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:619)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:602)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:311)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
{noformat}
--
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-6712) Highlighting not working in solr cloud grouping query when using group.query=xxx
Timo Schmidt created SOLR-6712: -- Summary: Highlighting not working in solr cloud grouping query when using group.query=xxx Key: SOLR-6712 URL: https://issues.apache.org/jira/browse/SOLR-6712 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 4.10.2 Reporter: Timo Schmidt The highlighting is throwing an exception in sold cloud when you are using group.query. Example: /select?group=truegroup.query=livesuggesttype_s:game_moviehl=truehl.q=testhl.fl=content The following exception will be throwen: java.lang.NullPointerException at org.apache.solr.handler.component.HighlightComponent.finishStage(HighlightComponent.java:195) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:330) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1983) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:760) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:412) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:201) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:368) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:745) I think this is also mentioned in the following stackoverflow post: http://stackoverflow.com/questions/25548063/solr-search-with-multicore-grouping-highlighting-null-pointer -- 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-6712) Highlighting not working in solr cloud grouping query when using group.query=xxx
[ https://issues.apache.org/jira/browse/SOLR-6712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14200474#comment-14200474 ] Timo Schmidt commented on SOLR-6712: Small hint: It seems to work in other cases like using group.field /select?group=truegroup.field=livesuggesttype_shl=truehl.q=testhl.fl=content Highlighting not working in solr cloud grouping query when using group.query=xxx Key: SOLR-6712 URL: https://issues.apache.org/jira/browse/SOLR-6712 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 4.10.2 Reporter: Timo Schmidt The highlighting is throwing an exception in sold cloud when you are using group.query. Example: /select?group=truegroup.query=livesuggesttype_s:game_moviehl=truehl.q=testhl.fl=content The following exception will be throwen: java.lang.NullPointerException at org.apache.solr.handler.component.HighlightComponent.finishStage(HighlightComponent.java:195) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:330) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1983) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:760) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:412) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:201) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:368) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:745) I think this is also mentioned in the following stackoverflow post: http://stackoverflow.com/questions/25548063/solr-search-with-multicore-grouping-highlighting-null-pointer -- 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-5046) IllegalArgumentException using distributed group.query when one shard does not match any docs
[
https://issues.apache.org/jira/browse/SOLR-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14189986#comment-14189986
]
Timo Schmidt commented on SOLR-5046:
Hello together,
yesterday i could do dome debugging and just want to share the outcome, ask
some questions and hopefully get a step further.
For me it is not clear if this is a problem insight of lucene or solr
The exceptions is thrown in org.apache.lucene.search.TopDocs on line 143
(branch_4x):
if (fd.fields == null) {
throw new IllegalArgumentException(shard + shardIDX + did
not set sort field values (FieldDoc.fields is null); you must pass
fillFields=true to IndexSearcher.search on each shard);
}
From reading the code in public static TopDocs merge(Sort sort, int
start, int size, TopDocs[] shardHits)“ there are two options:
a) sort is null = in this case the ScoreMergeSortQueue is used
b) sort is defined = the mergedSortQueue will be used (Even
when sort.fields has no Sorting fields).
By default we use Sort.RELEVANCE
What i don’t understand here is, why not just pass „null“ to merge by
score? Or is there a difference between Score and Relevance?
When i change the merge method the following:
if (sort == null) {
queue = new ScoreMergeSortQueue(shardHits);
} else {
queue = new MergeSortQueue(sort, shardHits);
}
to
if (sort == null || sort.equals(Sort.RELEVANCE)) {
queue = new ScoreMergeSortQueue(shardHits);
} else {
queue = new MergeSortQueue(sort, shardHits);
}
the case without any sorting works fine from the user level (but, there
is one broken testcase in lucene)
By reading the exception message „you must pass fillFields=true to“ i checked
the code and found the following in
„org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer“:
In the „transformToNative“ method „document.get(sortValues“)“ is used to
fill the sortValues for the document.
For some reason this seems to be empty.
From where do these sortValues come? And when could they be empty? And
what should happen when they are empty?
This serializer (TopGroupsResultTransformer.transformToNative) is used in
„TopGroupsShardResponseProcessor.process“.
Finally „ org.apache.lucene.search.TopDocs.merge“ is used to merge the
topDocs
TopDocs mergedTopDocs = TopDocs.merge(sortWithinGroup, topN,
topDocs.toArray(new TopDocs[topDocs.size()]));
As mentioned in „1“ the default Sorting is sorting byScore but the
topDocs seem to have no „sortFields
Is it an options to pass here „null“ as sorting when we want to sort by
relevance?
Conclusion:
I think there could be two potential reasons:
We should use/change the lucene api for merging with no sorting / sorting by
relevance?
We should find out why „sortFields“ is empty or if the is a call where search
is used without „fillFields“?
Any ideas?
If i could help somewhere just ask and it would be nice to get some insights
from somebody who is more inside the lucene and solr core.
Cheers
timo
IllegalArgumentException using distributed group.query when one shard does
not match any docs
-
Key: SOLR-5046
URL: https://issues.apache.org/jira/browse/SOLR-5046
Project: Solr
Issue Type: Bug
Affects Versions: 4.3
Reporter: Hoss Man
[Evgeny Salnikov noted this problem on the mailing
list|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201307.mbox/%3CCADz7Cx6PbMxExhb8gsCu9%3DP6nphJd2fYayov_%3D%3D%2Bo1sEXswWLw%40mail.gmail.com%3E],
although the initial report was somewhat convoluted by suspicious
description of adding shards after the fact.
Steps to reproduce using 4.3.1 example...
* startup a 2 node SolrCloud cluster following the Example A description on
the SolrCloud wiki...
** cp example example2
** cd example java -Dbootstrap_confdir=./solr/collection1/conf
-Dcollection.configName=myconf -DzkRun -DnumShards=2 -jar start.jar
** cd example2 java -Djetty.port=7574 -DzkHost=localhost:9983 -jar
start.jar
* index exactly one doc (to ensure that subsequent distributed queries get
results from only one node)
** java -jar post.jar utf8-example.xml
* execute a request using group.query
** http://localhost:7574/solr/select?q=*:*group=truegroup.query=cat:software
stack trace...
{noformat}
166500 [qtp2092063645-19] ERROR org.apache.solr.servlet.SolrDispatchFilter –
null:java.lang.IllegalArgumentException: shard 1 did not set sort field
values (FieldDoc.fields is null); you must pass fillFields=true to
IndexSearcher.search
[jira] [Comment Edited] (SOLR-5046) IllegalArgumentException using distributed group.query when one shard does not match any docs
[
https://issues.apache.org/jira/browse/SOLR-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14189986#comment-14189986
]
Timo Schmidt edited comment on SOLR-5046 at 10/30/14 12:18 PM:
---
Hello together,
yesterday i could do dome debugging and just want to share the outcome, ask
some questions and hopefully get a step further.
For me it is not clear if this is a problem insight of lucene or solr
The exceptions is thrown in org.apache.lucene.search.TopDocs on line 143
(branch_4x):
if (fd.fields == null) {
throw new IllegalArgumentException(shard + shardIDX + did
not set sort field values (FieldDoc.fields is null); you must pass
fillFields=true to IndexSearcher.search on each shard);
}
From reading the code in public static TopDocs merge(Sort sort, int
start, int size, TopDocs[] shardHits)“ there are two options:
a) sort is null = in this case the ScoreMergeSortQueue is used
b) sort is defined = the mergedSortQueue will be used (Even
when sort.fields has no Sorting fields).
By default we use Sort.RELEVANCE
What i don’t understand here is, why not just pass „null“ to merge by
score? Or is there a difference between Score and Relevance?
When i change the merge method the following:
if (sort == null) {
queue = new ScoreMergeSortQueue(shardHits);
} else {
queue = new MergeSortQueue(sort, shardHits);
}
to
if (sort == null || sort.equals(Sort.RELEVANCE)) {
queue = new ScoreMergeSortQueue(shardHits);
} else {
queue = new MergeSortQueue(sort, shardHits);
}
the case without any sorting works fine from the user level (but, there
is one broken testcase in lucene)
By reading the exception message „you must pass fillFields=true to“ i checked
the code and found the following in
„org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer“:
In the „transformToNative“ method „document.get(sortValues“)“ is used to
fill the sortValues for the document.
For some reason this seems to be empty.
From where do these sortValues come? And when could they be empty? And
what should happen when they are empty?
This serializer (TopGroupsResultTransformer.transformToNative) is used in
„TopGroupsShardResponseProcessor.process“.
Finally „ org.apache.lucene.search.TopDocs.merge“ is used to merge the
topDocs
TopDocs mergedTopDocs = TopDocs.merge(sortWithinGroup, topN,
topDocs.toArray(new TopDocs[topDocs.size()]));
As mentioned in „1“ the default Sorting is sorting byScore but the
topDocs seem to have no „sortFields
Is it an options to pass here „null“ as sorting when we want to sort by
relevance?
Conclusion:
I think there could be two potential reasons:
We should use/change the lucene api for merging with no sorting / sorting by
relevance?
We should find out why „sortFields“ is empty or if the is a call where search
is used without „fillFields“?
Any ideas?
If i could help somewhere just ask and it would be nice to get some insights
from somebody who is more inside the lucene and solr core.
Cheers
timo
was (Author: timo.schmidt):
Hello together,
yesterday i could do dome debugging and just want to share the outcome, ask
some questions and hopefully get a step further.
For me it is not clear if this is a problem insight of lucene or solr
The exceptions is thrown in org.apache.lucene.search.TopDocs on line 143
(branch_4x):
if (fd.fields == null) {
throw new IllegalArgumentException(shard + shardIDX + did
not set sort field values (FieldDoc.fields is null); you must pass
fillFields=true to IndexSearcher.search on each shard);
}
From reading the code in public static TopDocs merge(Sort sort, int
start, int size, TopDocs[] shardHits)“ there are two options:
a) sort is null = in this case the ScoreMergeSortQueue is used
b) sort is defined = the mergedSortQueue will be used (Even
when sort.fields has no Sorting fields).
By default we use Sort.RELEVANCE
What i don’t understand here is, why not just pass „null“ to merge by
score? Or is there a difference between Score and Relevance?
When i change the merge method the following:
if (sort == null) {
queue = new ScoreMergeSortQueue(shardHits);
} else {
queue = new MergeSortQueue(sort, shardHits);
}
to
if (sort == null || sort.equals(Sort.RELEVANCE)) {
queue = new ScoreMergeSortQueue(shardHits);
} else {
queue = new MergeSortQueue(sort, shardHits);
}
the case without any sorting works fine from
[jira] [Comment Edited] (SOLR-5046) IllegalArgumentException using distributed group.query when one shard does not match any docs
[
https://issues.apache.org/jira/browse/SOLR-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14189986#comment-14189986
]
Timo Schmidt edited comment on SOLR-5046 at 10/30/14 12:21 PM:
---
Hello together,
yesterday i could do dome debugging and just want to share the outcome, ask
some questions and hopefully get a step further.
For me it is not clear if this is a problem insight of lucene or solr
(1)
The exceptions is thrown in org.apache.lucene.search.TopDocs on line 143
(branch_4x):
if (fd.fields == null) {
throw new IllegalArgumentException(shard + shardIDX + did
not set sort field values (FieldDoc.fields is null); you must pass
fillFields=true to IndexSearcher.search on each shard);
}
From reading the code in public static TopDocs merge(Sort sort, int
start, int size, TopDocs[] shardHits)“ there are two options:
a) sort is null = in this case the ScoreMergeSortQueue is used
b) sort is defined = the mergedSortQueue will be used (Even
when sort.fields has no Sorting fields).
By default we use Sort.RELEVANCE
What i don’t understand here is, why not just pass „null“ to merge by
score? Or is there a difference between Score and Relevance?
When i change the merge method the following:
if (sort == null) {
queue = new ScoreMergeSortQueue(shardHits);
} else {
queue = new MergeSortQueue(sort, shardHits);
}
to
if (sort == null || sort.equals(Sort.RELEVANCE)) {
queue = new ScoreMergeSortQueue(shardHits);
} else {
queue = new MergeSortQueue(sort, shardHits);
}
the case without any sorting works fine from the user level (but, there
is one broken testcase in lucene)
(2)
By reading the exception message „you must pass fillFields=true to“ i checked
the code and found the following in
„org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer“:
In the „transformToNative“ method „document.get(sortValues“)“ is used to
fill the sortValues for the document.
For some reason this seems to be empty.
From where do these sortValues come? And when could they be empty? And
what should happen when they are empty?
This serializer (TopGroupsResultTransformer.transformToNative) is used in
„TopGroupsShardResponseProcessor.process“.
Finally „ org.apache.lucene.search.TopDocs.merge“ is used to merge the
topDocs
TopDocs mergedTopDocs = TopDocs.merge(sortWithinGroup, topN,
topDocs.toArray(new TopDocs[topDocs.size()]));
As mentioned in „1“ the default Sorting is sorting byScore but the
topDocs seem to have no „sortFields
Is it an options to pass here „null“ as sorting when we want to sort by
relevance?
Conclusion:
I think there could be two potential reasons:
We should use/change the lucene api for merging with no sorting / sorting by
relevance?
We should find out why „sortFields“ is empty or if the is a call where search
is used without „fillFields“?
Any ideas?
If i could help somewhere just ask and it would be nice to get some insights
from somebody who is more inside the lucene and solr core.
Cheers
timo
was (Author: timo.schmidt):
Hello together,
yesterday i could do dome debugging and just want to share the outcome, ask
some questions and hopefully get a step further.
For me it is not clear if this is a problem insight of lucene or solr
The exceptions is thrown in org.apache.lucene.search.TopDocs on line 143
(branch_4x):
if (fd.fields == null) {
throw new IllegalArgumentException(shard + shardIDX + did
not set sort field values (FieldDoc.fields is null); you must pass
fillFields=true to IndexSearcher.search on each shard);
}
From reading the code in public static TopDocs merge(Sort sort, int
start, int size, TopDocs[] shardHits)“ there are two options:
a) sort is null = in this case the ScoreMergeSortQueue is used
b) sort is defined = the mergedSortQueue will be used (Even
when sort.fields has no Sorting fields).
By default we use Sort.RELEVANCE
What i don’t understand here is, why not just pass „null“ to merge by
score? Or is there a difference between Score and Relevance?
When i change the merge method the following:
if (sort == null) {
queue = new ScoreMergeSortQueue(shardHits);
} else {
queue = new MergeSortQueue(sort, shardHits);
}
to
if (sort == null || sort.equals(Sort.RELEVANCE)) {
queue = new ScoreMergeSortQueue(shardHits);
} else {
queue = new MergeSortQueue(sort, shardHits);
}
the case without any sorting works
[jira] [Updated] (SOLR-5046) IllegalArgumentException using distributed group.query when one shard does not match any docs
[
https://issues.apache.org/jira/browse/SOLR-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timo Schmidt updated SOLR-5046:
---
Attachment: 0001-Get-distributed-grouping-request-work-with-sort-with.patch
The attached patch shows that grouping in distributed mode is working with
sort and without sort (by score).
IllegalArgumentException using distributed group.query when one shard does
not match any docs
-
Key: SOLR-5046
URL: https://issues.apache.org/jira/browse/SOLR-5046
Project: Solr
Issue Type: Bug
Affects Versions: 4.3
Reporter: Hoss Man
Attachments:
0001-Get-distributed-grouping-request-work-with-sort-with.patch
[Evgeny Salnikov noted this problem on the mailing
list|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201307.mbox/%3CCADz7Cx6PbMxExhb8gsCu9%3DP6nphJd2fYayov_%3D%3D%2Bo1sEXswWLw%40mail.gmail.com%3E],
although the initial report was somewhat convoluted by suspicious
description of adding shards after the fact.
Steps to reproduce using 4.3.1 example...
* startup a 2 node SolrCloud cluster following the Example A description on
the SolrCloud wiki...
** cp example example2
** cd example java -Dbootstrap_confdir=./solr/collection1/conf
-Dcollection.configName=myconf -DzkRun -DnumShards=2 -jar start.jar
** cd example2 java -Djetty.port=7574 -DzkHost=localhost:9983 -jar
start.jar
* index exactly one doc (to ensure that subsequent distributed queries get
results from only one node)
** java -jar post.jar utf8-example.xml
* execute a request using group.query
** http://localhost:7574/solr/select?q=*:*group=truegroup.query=cat:software
stack trace...
{noformat}
166500 [qtp2092063645-19] ERROR org.apache.solr.servlet.SolrDispatchFilter –
null:java.lang.IllegalArgumentException: shard 1 did not set sort field
values (FieldDoc.fields is null); you must pass fillFields=true to
IndexSearcher.search on each shard
at
org.apache.lucene.search.TopDocs$MergeSortQueue.init(TopDocs.java:143)
at org.apache.lucene.search.TopDocs.merge(TopDocs.java:214)
at
org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:114)
at
org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:619)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:602)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:311)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
{noformat}
--
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] [Comment Edited] (SOLR-5046) IllegalArgumentException using distributed group.query when one shard does not match any docs
[
https://issues.apache.org/jira/browse/SOLR-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190292#comment-14190292
]
Timo Schmidt edited comment on SOLR-5046 at 10/30/14 4:11 PM:
--
The attached patch shows that grouping in distributed mode is working with
sort and without sort (by score).
It think this could also be handled inside TopDocs.merge by checking if there
is a sorting that needsScores
Also strange for me, it is not working for grouping.sort=... It seems that the
argument sort somewhere fills the lucene fields and group.sort not.
was (Author: timo.schmidt):
The attached patch shows that grouping in distributed mode is working with
sort and without sort (by score).
IllegalArgumentException using distributed group.query when one shard does
not match any docs
-
Key: SOLR-5046
URL: https://issues.apache.org/jira/browse/SOLR-5046
Project: Solr
Issue Type: Bug
Affects Versions: 4.3
Reporter: Hoss Man
Attachments:
0001-Get-distributed-grouping-request-work-with-sort-with.patch
[Evgeny Salnikov noted this problem on the mailing
list|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201307.mbox/%3CCADz7Cx6PbMxExhb8gsCu9%3DP6nphJd2fYayov_%3D%3D%2Bo1sEXswWLw%40mail.gmail.com%3E],
although the initial report was somewhat convoluted by suspicious
description of adding shards after the fact.
Steps to reproduce using 4.3.1 example...
* startup a 2 node SolrCloud cluster following the Example A description on
the SolrCloud wiki...
** cp example example2
** cd example java -Dbootstrap_confdir=./solr/collection1/conf
-Dcollection.configName=myconf -DzkRun -DnumShards=2 -jar start.jar
** cd example2 java -Djetty.port=7574 -DzkHost=localhost:9983 -jar
start.jar
* index exactly one doc (to ensure that subsequent distributed queries get
results from only one node)
** java -jar post.jar utf8-example.xml
* execute a request using group.query
** http://localhost:7574/solr/select?q=*:*group=truegroup.query=cat:software
stack trace...
{noformat}
166500 [qtp2092063645-19] ERROR org.apache.solr.servlet.SolrDispatchFilter –
null:java.lang.IllegalArgumentException: shard 1 did not set sort field
values (FieldDoc.fields is null); you must pass fillFields=true to
IndexSearcher.search on each shard
at
org.apache.lucene.search.TopDocs$MergeSortQueue.init(TopDocs.java:143)
at org.apache.lucene.search.TopDocs.merge(TopDocs.java:214)
at
org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:114)
at
org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:619)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:602)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:311)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
{noformat}
--
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-5046) IllegalArgumentException using distributed group.query when one shard does not match any docs
[
https://issues.apache.org/jira/browse/SOLR-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14186607#comment-14186607
]
Timo Schmidt commented on SOLR-5046:
Hey, any news on this issue?
I am new in terms on development in apache solr and this issue is very
important for one of our projects. Can i help out some how? Are there allready
some testcases that might fail, so that i could dig into the issue and try to
find a solution?
IllegalArgumentException using distributed group.query when one shard does
not match any docs
-
Key: SOLR-5046
URL: https://issues.apache.org/jira/browse/SOLR-5046
Project: Solr
Issue Type: Bug
Affects Versions: 4.3
Reporter: Hoss Man
[Evgeny Salnikov noted this problem on the mailing
list|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201307.mbox/%3CCADz7Cx6PbMxExhb8gsCu9%3DP6nphJd2fYayov_%3D%3D%2Bo1sEXswWLw%40mail.gmail.com%3E],
although the initial report was somewhat convoluted by suspicious
description of adding shards after the fact.
Steps to reproduce using 4.3.1 example...
* startup a 2 node SolrCloud cluster following the Example A description on
the SolrCloud wiki...
** cp example example2
** cd example java -Dbootstrap_confdir=./solr/collection1/conf
-Dcollection.configName=myconf -DzkRun -DnumShards=2 -jar start.jar
** cd example2 java -Djetty.port=7574 -DzkHost=localhost:9983 -jar
start.jar
* index exactly one doc (to ensure that subsequent distributed queries get
results from only one node)
** java -jar post.jar utf8-example.xml
* execute a request using group.query
** http://localhost:7574/solr/select?q=*:*group=truegroup.query=cat:software
stack trace...
{noformat}
166500 [qtp2092063645-19] ERROR org.apache.solr.servlet.SolrDispatchFilter –
null:java.lang.IllegalArgumentException: shard 1 did not set sort field
values (FieldDoc.fields is null); you must pass fillFields=true to
IndexSearcher.search on each shard
at
org.apache.lucene.search.TopDocs$MergeSortQueue.init(TopDocs.java:143)
at org.apache.lucene.search.TopDocs.merge(TopDocs.java:214)
at
org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:114)
at
org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:619)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:602)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:311)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
{noformat}
--
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-6163) special chars and ManagedSynonymFilterFactory
[ https://issues.apache.org/jira/browse/SOLR-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timo Schmidt updated SOLR-6163: --- Attachment: SOLR-6163-v2.patch special chars and ManagedSynonymFilterFactory - Key: SOLR-6163 URL: https://issues.apache.org/jira/browse/SOLR-6163 Project: Solr Issue Type: Bug Affects Versions: 4.8 Reporter: Wim Kumpen Attachments: SOLR-6163-v2.patch, SOLR-6163.patch Hey, I was playing with the ManagedSynonymFilterFactory to create a synonym list with the API. But I have difficulties when my keys contains special characters (or spaces) to delete them... I added a key ééé that matches with some other words. It's saved in the synonym file as ééé. When I try to delete it, I do: curl -X DELETE http://localhost/solr/mycore/schema/analysis/synonyms/english/ééé; error message: %C3%A9%C3%A9%C3%A9%C2%B5 not found in /schema/analysis/synonyms/english A wild guess from me is that %C3%A9 isn't decoded back to ééé. And that's why he can't find the keyword? -- 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-6163) special chars and ManagedSynonymFilterFactory
[ https://issues.apache.org/jira/browse/SOLR-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14077564#comment-14077564 ] Timo Schmidt commented on SOLR-6163: Hello together, I've added a specific test for special characters and added a new patch+commited the changes to the pull request. If you need further changes please let me know special chars and ManagedSynonymFilterFactory - Key: SOLR-6163 URL: https://issues.apache.org/jira/browse/SOLR-6163 Project: Solr Issue Type: Bug Affects Versions: 4.8 Reporter: Wim Kumpen Attachments: SOLR-6163-v2.patch, SOLR-6163.patch Hey, I was playing with the ManagedSynonymFilterFactory to create a synonym list with the API. But I have difficulties when my keys contains special characters (or spaces) to delete them... I added a key ééé that matches with some other words. It's saved in the synonym file as ééé. When I try to delete it, I do: curl -X DELETE http://localhost/solr/mycore/schema/analysis/synonyms/english/ééé; error message: %C3%A9%C3%A9%C3%A9%C2%B5 not found in /schema/analysis/synonyms/english A wild guess from me is that %C3%A9 isn't decoded back to ééé. And that's why he can't find the keyword? -- 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-6163) special chars and ManagedSynonymFilterFactory
[ https://issues.apache.org/jira/browse/SOLR-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timo Schmidt updated SOLR-6163: --- Attachment: SOLR-6163-v3.patch Grouped the commits of the last patch into one single patch special chars and ManagedSynonymFilterFactory - Key: SOLR-6163 URL: https://issues.apache.org/jira/browse/SOLR-6163 Project: Solr Issue Type: Bug Affects Versions: 4.8 Reporter: Wim Kumpen Attachments: SOLR-6163-v2.patch, SOLR-6163-v3.patch, SOLR-6163.patch Hey, I was playing with the ManagedSynonymFilterFactory to create a synonym list with the API. But I have difficulties when my keys contains special characters (or spaces) to delete them... I added a key ééé that matches with some other words. It's saved in the synonym file as ééé. When I try to delete it, I do: curl -X DELETE http://localhost/solr/mycore/schema/analysis/synonyms/english/ééé; error message: %C3%A9%C3%A9%C3%A9%C2%B5 not found in /schema/analysis/synonyms/english A wild guess from me is that %C3%A9 isn't decoded back to ééé. And that's why he can't find the keyword? -- 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-6163) special chars and ManagedSynonymFilterFactory
[ https://issues.apache.org/jira/browse/SOLR-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timo Schmidt updated SOLR-6163: --- Attachment: SOLR-6163-v4.patch special chars and ManagedSynonymFilterFactory - Key: SOLR-6163 URL: https://issues.apache.org/jira/browse/SOLR-6163 Project: Solr Issue Type: Bug Affects Versions: 4.8 Reporter: Wim Kumpen Attachments: SOLR-6163-v2.patch, SOLR-6163-v3.patch, SOLR-6163-v4.patch, SOLR-6163.patch Hey, I was playing with the ManagedSynonymFilterFactory to create a synonym list with the API. But I have difficulties when my keys contains special characters (or spaces) to delete them... I added a key ééé that matches with some other words. It's saved in the synonym file as ééé. When I try to delete it, I do: curl -X DELETE http://localhost/solr/mycore/schema/analysis/synonyms/english/ééé; error message: %C3%A9%C3%A9%C3%A9%C2%B5 not found in /schema/analysis/synonyms/english A wild guess from me is that %C3%A9 isn't decoded back to ééé. And that's why he can't find the keyword? -- 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-2374) Create UpdateFileRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997414#comment-12997414 ] Timo Schmidt commented on SOLR-2374: Ok cool, this is only a first proposal, in my opinion it would be good to refactor the resourceLoader to have a resourceManager with the methods hasResource(), readResource() and writeResource(), which is implemented diffrent for zooKeeper and local files. As soon as i have some time, i'll try to refactor that. Create UpdateFileRequestHandler --- Key: SOLR-2374 URL: https://issues.apache.org/jira/browse/SOLR-2374 Project: Solr Issue Type: New Feature Components: update Affects Versions: 1.4.1 Reporter: Timo Schmidt Labels: config, file, patch, upload Fix For: Next Attachments: UpdateFileRequestHandler.patch, patchV2.diff Original Estimate: 4h Remaining Estimate: 4h It would be nice to be able to update files like synonyms.txt and stopwords.txt with a seperrat request handler. Since i am very new to solr development i've prepared a patch with a new UpdateFileRequest handler. Maybe it would be good to refactor the existing fileRequestHandler. Currently it is implemented that you need to whitelist all files which should be editable. I think this is better for security reasons. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2374) Create UpdateFileRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997224#comment-12997224 ] Timo Schmidt commented on SOLR-2374: Hello together, today i had a look at the code and currently i have one proposal: Currently there is SolrResourceLoader and ZKSolrResourceLoader, which handle the resource loading for normal solr and zookeeper solr (openResource). What do you thing of refactoring the resourceLoader to a resourceManager, with the possibility to open resources for reading and writing. But afaik openResource is also used to open jar files and i thing it should not be possible to write these files for security reasons. What do you think? Create UpdateFileRequestHandler --- Key: SOLR-2374 URL: https://issues.apache.org/jira/browse/SOLR-2374 Project: Solr Issue Type: New Feature Components: update Affects Versions: 1.4.1 Reporter: Timo Schmidt Labels: config, file, patch, upload Fix For: Next Attachments: UpdateFileRequestHandler.patch Original Estimate: 4h Remaining Estimate: 4h It would be nice to be able to update files like synonyms.txt and stopwords.txt with a seperrat request handler. Since i am very new to solr development i've prepared a patch with a new UpdateFileRequest handler. Maybe it would be good to refactor the existing fileRequestHandler. Currently it is implemented that you need to whitelist all files which should be editable. I think this is better for security reasons. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Issue Comment Edited: (SOLR-2374) Create UpdateFileRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997224#comment-12997224 ] Timo Schmidt edited comment on SOLR-2374 at 2/20/11 9:30 PM: - Hello together, today i had a look at the code and currently i have one proposal: Currently there is SolrResourceLoader and ZKSolrResourceLoader, which handle the resource loading for normal solr and zookeeper solr (openResource). What do you thing of refactoring the resourceLoader to a resourceManager, with the possibility to open resources for reading and writing. But afaik openResource is also used to open jar files and i think it should not be possible to write these files for security reasons. What do you think? was (Author: timo.schmidt): Hello together, today i had a look at the code and currently i have one proposal: Currently there is SolrResourceLoader and ZKSolrResourceLoader, which handle the resource loading for normal solr and zookeeper solr (openResource). What do you thing of refactoring the resourceLoader to a resourceManager, with the possibility to open resources for reading and writing. But afaik openResource is also used to open jar files and i thing it should not be possible to write these files for security reasons. What do you think? Create UpdateFileRequestHandler --- Key: SOLR-2374 URL: https://issues.apache.org/jira/browse/SOLR-2374 Project: Solr Issue Type: New Feature Components: update Affects Versions: 1.4.1 Reporter: Timo Schmidt Labels: config, file, patch, upload Fix For: Next Attachments: UpdateFileRequestHandler.patch Original Estimate: 4h Remaining Estimate: 4h It would be nice to be able to update files like synonyms.txt and stopwords.txt with a seperrat request handler. Since i am very new to solr development i've prepared a patch with a new UpdateFileRequest handler. Maybe it would be good to refactor the existing fileRequestHandler. Currently it is implemented that you need to whitelist all files which should be editable. I think this is better for security reasons. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2374) Create UpdateFileRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timo Schmidt updated SOLR-2374: --- Attachment: patchV2.diff Just to show the idea. Create UpdateFileRequestHandler --- Key: SOLR-2374 URL: https://issues.apache.org/jira/browse/SOLR-2374 Project: Solr Issue Type: New Feature Components: update Affects Versions: 1.4.1 Reporter: Timo Schmidt Labels: config, file, patch, upload Fix For: Next Attachments: UpdateFileRequestHandler.patch, patchV2.diff Original Estimate: 4h Remaining Estimate: 4h It would be nice to be able to update files like synonyms.txt and stopwords.txt with a seperrat request handler. Since i am very new to solr development i've prepared a patch with a new UpdateFileRequest handler. Maybe it would be good to refactor the existing fileRequestHandler. Currently it is implemented that you need to whitelist all files which should be editable. I think this is better for security reasons. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Issue Comment Edited: (SOLR-2374) Create UpdateFileRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997239#comment-12997239 ] Timo Schmidt edited comment on SOLR-2374 at 2/20/11 11:36 PM: -- New patch attached, just to show the idea. was (Author: timo.schmidt): Just to show the idea. Create UpdateFileRequestHandler --- Key: SOLR-2374 URL: https://issues.apache.org/jira/browse/SOLR-2374 Project: Solr Issue Type: New Feature Components: update Affects Versions: 1.4.1 Reporter: Timo Schmidt Labels: config, file, patch, upload Fix For: Next Attachments: UpdateFileRequestHandler.patch, patchV2.diff Original Estimate: 4h Remaining Estimate: 4h It would be nice to be able to update files like synonyms.txt and stopwords.txt with a seperrat request handler. Since i am very new to solr development i've prepared a patch with a new UpdateFileRequest handler. Maybe it would be good to refactor the existing fileRequestHandler. Currently it is implemented that you need to whitelist all files which should be editable. I think this is better for security reasons. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Created: (SOLR-2374) Create UpdateFileRequestHandler
Create UpdateFileRequestHandler --- Key: SOLR-2374 URL: https://issues.apache.org/jira/browse/SOLR-2374 Project: Solr Issue Type: New Feature Components: update Affects Versions: 1.4.1 Reporter: Timo Schmidt Fix For: 1.4.2 It would be nice to be able to update files like synonyms.txt and stopwords.txt with a seperrat request handler. Since i am very new to solr development i've prepared a patch with a new UpdateFileRequest handler. Maybe it would be good to refactor the existing fileRequestHandler. Currently it is implemented that you need to whitelist all files which should be editable. I think this is better for security reasons. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2374) Create UpdateFileRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timo Schmidt updated SOLR-2374: --- Attachment: UpdateFileRequestHandler.patch Patch against the current trunk Create UpdateFileRequestHandler --- Key: SOLR-2374 URL: https://issues.apache.org/jira/browse/SOLR-2374 Project: Solr Issue Type: New Feature Components: update Affects Versions: 1.4.1 Reporter: Timo Schmidt Labels: config, file, patch, upload Fix For: 1.4.2 Attachments: UpdateFileRequestHandler.patch Original Estimate: 4h Remaining Estimate: 4h It would be nice to be able to update files like synonyms.txt and stopwords.txt with a seperrat request handler. Since i am very new to solr development i've prepared a patch with a new UpdateFileRequest handler. Maybe it would be good to refactor the existing fileRequestHandler. Currently it is implemented that you need to whitelist all files which should be editable. I think this is better for security reasons. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2374) Create UpdateFileRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996509#comment-12996509 ] Timo Schmidt commented on SOLR-2374: Best case in my opinion would be to have the fileRequestHandler as reader and writer and it's transperent to ZooKeeper. Create UpdateFileRequestHandler --- Key: SOLR-2374 URL: https://issues.apache.org/jira/browse/SOLR-2374 Project: Solr Issue Type: New Feature Components: update Affects Versions: 1.4.1 Reporter: Timo Schmidt Labels: config, file, patch, upload Fix For: 1.4.2 Attachments: UpdateFileRequestHandler.patch Original Estimate: 4h Remaining Estimate: 4h It would be nice to be able to update files like synonyms.txt and stopwords.txt with a seperrat request handler. Since i am very new to solr development i've prepared a patch with a new UpdateFileRequest handler. Maybe it would be good to refactor the existing fileRequestHandler. Currently it is implemented that you need to whitelist all files which should be editable. I think this is better for security reasons. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
