[jira] [Updated] (SOLR-7864) timeAllowed causing ClassCastException
[
https://issues.apache.org/jira/browse/SOLR-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isabelle Giguere updated SOLR-7864:
---
Attachment: SOLR-7864_tag_7.5.0.patch
> timeAllowed causing ClassCastException
> --
>
> Key: SOLR-7864
> URL: https://issues.apache.org/jira/browse/SOLR-7864
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.2
>Reporter: Markus Jelsma
>Priority: Major
> Attachments: SOLR-7864.patch, SOLR-7864.patch, SOLR-7864_extra.patch,
> SOLR-7864_tag_7.5.0.patch
>
>
> If timeAllowed kicks in, following exception is thrown and user gets HTTP 500.
> {code}
> 65219 [qtp2096057945-19] ERROR org.apache.solr.servlet.SolrDispatchFilter [
> search] – null:java.lang.ClassCastException:
> org.apache.solr.response.ResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:275)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:497)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7864) timeAllowed causing ClassCastException
[
https://issues.apache.org/jira/browse/SOLR-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isabelle Giguere updated SOLR-7864:
---
Attachment: (was: SOLR-7864_tag_7.5.0.patch)
> timeAllowed causing ClassCastException
> --
>
> Key: SOLR-7864
> URL: https://issues.apache.org/jira/browse/SOLR-7864
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.2
>Reporter: Markus Jelsma
>Priority: Major
> Attachments: SOLR-7864.patch, SOLR-7864.patch, SOLR-7864_extra.patch,
> SOLR-7864_tag_7.5.0.patch
>
>
> If timeAllowed kicks in, following exception is thrown and user gets HTTP 500.
> {code}
> 65219 [qtp2096057945-19] ERROR org.apache.solr.servlet.SolrDispatchFilter [
> search] – null:java.lang.ClassCastException:
> org.apache.solr.response.ResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:275)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:497)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16659065#comment-16659065
]
Isabelle Giguere commented on SOLR-7642:
Attached proposition (not tested ;) ), blending both [~smolloy] and [~janhoy]
's ideas.
It might be overkill ... what does anyone think ?
First, creating the chroot must be allowed (if createZkRoot=true), then, the ZK
root must match the authorized root (set by solr.zkChroot).
The name 'createZkRoot' could be changed to solr.createZkRoot, for uniformity.
> Should launching Solr in cloud mode using a ZooKeeper chroot create the
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
> Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch,
> SOLR-7642_tag_7.5.0.patch, SOLR-7642_tag_7.5.0_proposition.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper
> connection string that includes a chroot leads to the following
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
> is that some violation of using a chroot?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isabelle Giguere updated SOLR-7642:
---
Attachment: SOLR-7642_tag_7.5.0_proposition.patch
> Should launching Solr in cloud mode using a ZooKeeper chroot create the
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
> Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch,
> SOLR-7642_tag_7.5.0.patch, SOLR-7642_tag_7.5.0_proposition.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper
> connection string that includes a chroot leads to the following
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
> is that some violation of using a chroot?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16657458#comment-16657458
]
Isabelle Giguere commented on SOLR-7642:
My 2 cents is that creating the chroot only if it is /solr doesn't solve the
original issue. To impose /solr is not equivalent to allowing the creation of
the chroot. It's just less messy than having everything at the root '/'.
How about a specific property in solr.in.sh / solr.in.cmd ? Instead of
including the chroot in ZK_HOST, it could bet set separately, so it would have
to be a conscious decision.
And about typos...
Using zkCLI, the user creates the chroot (possibly making a typo in command
line) then, has to write the same (typo) chroot in ZK_HOST in solr.in.sh to
avoid 2 ZK paths created.
I would rather just use zkCLI to clean-up what was added by mistake, than to
have to systematically use it once to create the chroot, then repeat the same
chroot in solr.in.sh
I think if the chroot is specified only once, that's less likely to create
confusion.
> Should launching Solr in cloud mode using a ZooKeeper chroot create the
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
> Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch,
> SOLR-7642_tag_7.5.0.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper
> connection string that includes a chroot leads to the following
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
> is that some violation of using a chroot?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8921) Potential NPE in pivot facet
[ https://issues.apache.org/jira/browse/SOLR-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16657331#comment-16657331 ] Isabelle Giguere edited comment on SOLR-8921 at 10/19/18 7:49 PM: -- I'm attaching unit tests, with 2 collections, and a few fields in the schema. But, this issue has nothing do do with the number of collections, and not much to do with the field types. An NPE can happen if the string that is used as facet pivot value is a stopword, or an empty string. PivotFacetProcessor.getDocSet(DocSet base, SchemaField field, String pivotValue) // if pivotValue = "a", or if pivotValue = "in" (stopword) ft.getFieldQuery(null, field, pivotValue) -> returns null searcher.getDocSet(query, base); -> throws NPE // if pivotValue = "" (empty str) ft.getFieldQuery(null, field, pivotValue) -> returned query= name: searcher.getDocSet(query, base); -> returns DocSet size -1 -> NPE could be thrown from PivotFacetProcessor.getSubsetSize(DocSet base, SchemaField field, String pivotValue) (? - to validate) *** Maybe it is more likely to happen on multiple collections if the collections are meant for different languages, and a non-stopword in one language is a stopword in another language ? was (Author: igiguere): I'm attaching unit tests, with 2 collections, and a few fields in the schema. But, this issue has nothing do do with the number of collections, and not much to do with the field types. An NPE can happen if the string that is used as facet pivot value is a stopword, or an empty string. PivotFacetProcessor.getDocSet(DocSet base, SchemaField field, String pivotValue) // if pivotValue = "a", or if pivotValue = "in" (stopword) ft.getFieldQuery(null, field, pivotValue) -> returns null searcher.getDocSet(query, base); -> throws NPE // if pivotValue = "" (empty str) ft.getFieldQuery(null, field, pivotValue) -> returned query= name: searcher.getDocSet(query, base); -> returns DocSet size -1 -> NPE could be thrown from PivotFacetProcessor.getSubsetSize(DocSet base, SchemaField field, String pivotValue) (? - to validate) > Potential NPE in pivot facet > > > Key: SOLR-8921 > URL: https://issues.apache.org/jira/browse/SOLR-8921 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8921.patch, SOLR-8921.patch, > SOLR-8921_tag_7.5.0.patch, SOLR-8921_unit-tests_tag_7.5.0.patch > > > For some queries distributed over multiple collections, I've hit a NPE when > SolrIndexSearcher tries to fetch results from cache. Basically, query > generated to compute pivot on document sub set is null, causing the NPE on > lookup. > 2016-03-28 11:34:58.361 ERROR (qtp268141378-751) [c:otif_fr s:shard1 > r:core_node1 x:otif_fr_shard1_replica1] o.a.s.h.RequestHandlerBase > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) > at > org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:92) > at org.apache.solr.search.LFUCache.get(LFUCache.java:153) > at > org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:940) > at > org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2098) > at > org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:356) > at > org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:219) > at > org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:167) > at > org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:263) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHa
[jira] [Commented] (SOLR-8921) Potential NPE in pivot facet
[ https://issues.apache.org/jira/browse/SOLR-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16657331#comment-16657331 ] Isabelle Giguere commented on SOLR-8921: I'm attaching unit tests, with 2 collections, and a few fields in the schema. But, this issue has nothing do do with the number of collections, and not much to do with the field types. An NPE can happen if the string that is used as facet pivot value is a stopword, or an empty string. PivotFacetProcessor.getDocSet(DocSet base, SchemaField field, String pivotValue) // if pivotValue = "a", or if pivotValue = "in" (stopword) ft.getFieldQuery(null, field, pivotValue) -> returns null searcher.getDocSet(query, base); -> throws NPE // if pivotValue = "" (empty str) ft.getFieldQuery(null, field, pivotValue) -> returned query= name: searcher.getDocSet(query, base); -> returns DocSet size -1 -> NPE could be thrown from PivotFacetProcessor.getSubsetSize(DocSet base, SchemaField field, String pivotValue) (? - to validate) > Potential NPE in pivot facet > > > Key: SOLR-8921 > URL: https://issues.apache.org/jira/browse/SOLR-8921 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8921.patch, SOLR-8921.patch, > SOLR-8921_tag_7.5.0.patch, SOLR-8921_unit-tests_tag_7.5.0.patch > > > For some queries distributed over multiple collections, I've hit a NPE when > SolrIndexSearcher tries to fetch results from cache. Basically, query > generated to compute pivot on document sub set is null, causing the NPE on > lookup. > 2016-03-28 11:34:58.361 ERROR (qtp268141378-751) [c:otif_fr s:shard1 > r:core_node1 x:otif_fr_shard1_replica1] o.a.s.h.RequestHandlerBase > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) > at > org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:92) > at org.apache.solr.search.LFUCache.get(LFUCache.java:153) > at > org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:940) > at > org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2098) > at > org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:356) > at > org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:219) > at > org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:167) > at > org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:263) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at org.eclipse.jetty.server.Server.handle(Server.java:499) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > at > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.ja
[jira] [Updated] (SOLR-8921) Potential NPE in pivot facet
[ https://issues.apache.org/jira/browse/SOLR-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabelle Giguere updated SOLR-8921: --- Attachment: SOLR-8921_unit-tests_tag_7.5.0.patch > Potential NPE in pivot facet > > > Key: SOLR-8921 > URL: https://issues.apache.org/jira/browse/SOLR-8921 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8921.patch, SOLR-8921.patch, > SOLR-8921_tag_7.5.0.patch, SOLR-8921_unit-tests_tag_7.5.0.patch > > > For some queries distributed over multiple collections, I've hit a NPE when > SolrIndexSearcher tries to fetch results from cache. Basically, query > generated to compute pivot on document sub set is null, causing the NPE on > lookup. > 2016-03-28 11:34:58.361 ERROR (qtp268141378-751) [c:otif_fr s:shard1 > r:core_node1 x:otif_fr_shard1_replica1] o.a.s.h.RequestHandlerBase > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) > at > org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:92) > at org.apache.solr.search.LFUCache.get(LFUCache.java:153) > at > org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:940) > at > org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2098) > at > org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:356) > at > org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:219) > at > org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:167) > at > org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:263) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at org.eclipse.jetty.server.Server.handle(Server.java:499) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > at > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8921) Potential NPE in pivot facet
[ https://issues.apache.org/jira/browse/SOLR-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646667#comment-16646667 ] Isabelle Giguere edited comment on SOLR-8921 at 10/19/18 4:05 PM: -- Solr 7.5.0 : Reproduced with a query on a text field, with an alias, even if each collections in the alias respond without error individually 'fileName' : text field, split on '.', single valued 'author' : text field, full analysis, multivalued 'fileType' : text field, lower cased only, single valued - collection=de_alias&facet.field=author&facet.pivot=fileName = NPE - collection=lang_de&facet.field=author&facet.pivot=fileName = response OK - collection=emptyText&facet.field=author&facet.pivot=fileName = response OK - collection=de_alias&facet.field=author&facet.pivot=fileType = response OK I'll try to find time to devise a unit test to illustrate. Alternatively to this patch on PivotFacetProcessor, org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(Query q) could return DocSet.EMPTY if input Query is null, but that would have repercussions everywhere. was (Author: igiguere): Solr 7.5.0 : Reproduced with a query on a text field, with an alias, even if each collections in the alias respond without error individually 'fileName' : text field, single valued 'author' : text field, multivalued 'fileType' : string field, single valued - collection=de_alias&facet.field=author&facet.pivot=fileName = NPE - collection=lang_de&facet.field=author&facet.pivot=fileName = response OK - collection=emptyText&facet.field=author&facet.pivot=fileName = response OK - collection=de_alias&facet.field=author&facet.pivot=fileType = response OK I'll try to find time to devise a unit test to illustrate. Alternatively to this patch on PivotFacetProcessor, org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(Query q) could return DocSet.EMPTY if input Query is null, but that would have repercussions everywhere. > Potential NPE in pivot facet > > > Key: SOLR-8921 > URL: https://issues.apache.org/jira/browse/SOLR-8921 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8921.patch, SOLR-8921.patch, > SOLR-8921_tag_7.5.0.patch > > > For some queries distributed over multiple collections, I've hit a NPE when > SolrIndexSearcher tries to fetch results from cache. Basically, query > generated to compute pivot on document sub set is null, causing the NPE on > lookup. > 2016-03-28 11:34:58.361 ERROR (qtp268141378-751) [c:otif_fr s:shard1 > r:core_node1 x:otif_fr_shard1_replica1] o.a.s.h.RequestHandlerBase > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) > at > org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:92) > at org.apache.solr.search.LFUCache.get(LFUCache.java:153) > at > org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:940) > at > org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2098) > at > org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:356) > at > org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:219) > at > org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:167) > at > org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:263) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515
[jira] [Comment Edited] (SOLR-8921) Potential NPE in pivot facet
[ https://issues.apache.org/jira/browse/SOLR-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646667#comment-16646667 ] Isabelle Giguere edited comment on SOLR-8921 at 10/19/18 2:58 PM: -- Solr 7.5.0 : Reproduced with a query on a text field, with an alias, even if each collections in the alias respond without error individually 'fileName' : text field, single valued 'author' : text field, multivalued 'fileType' : string field, single valued - collection=de_alias&facet.field=author&facet.pivot=fileName = NPE - collection=lang_de&facet.field=author&facet.pivot=fileName = response OK - collection=emptyText&facet.field=author&facet.pivot=fileName = response OK - collection=de_alias&facet.field=author&facet.pivot=fileType = response OK I'll try to find time to devise a unit test to illustrate. Alternatively to this patch on PivotFacetProcessor, org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(Query q) could return DocSet.EMPTY if input Query is null, but that would have repercussions everywhere. was (Author: igiguere): Solr 7.5.0 : Reproduced with a query on a text field, with an alias, even if each collections in the alias respond without error individually 'fileName' and 'author' are text field, 'fileType' is a string field - collection=de_alias&facet.field=author&facet.pivot=fileName = NPE - collection=lang_de&facet.field=author&facet.pivot=fileName = response OK - collection=emptyText&facet.field=author&facet.pivot=fileName = response OK - collection=de_alias&facet.field=author&facet.pivot=fileType = response OK I'll try to find time to devise a unit test to illustrate. Alternatively to this patch on PivotFacetProcessor, org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(Query q) could return DocSet.EMPTY if input Query is null, but that would have repercussions everywhere. > Potential NPE in pivot facet > > > Key: SOLR-8921 > URL: https://issues.apache.org/jira/browse/SOLR-8921 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8921.patch, SOLR-8921.patch, > SOLR-8921_tag_7.5.0.patch > > > For some queries distributed over multiple collections, I've hit a NPE when > SolrIndexSearcher tries to fetch results from cache. Basically, query > generated to compute pivot on document sub set is null, causing the NPE on > lookup. > 2016-03-28 11:34:58.361 ERROR (qtp268141378-751) [c:otif_fr s:shard1 > r:core_node1 x:otif_fr_shard1_replica1] o.a.s.h.RequestHandlerBase > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) > at > org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:92) > at org.apache.solr.search.LFUCache.get(LFUCache.java:153) > at > org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:940) > at > org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2098) > at > org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:356) > at > org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:219) > at > org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:167) > at > org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:263) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:
[jira] [Comment Edited] (SOLR-8921) Potential NPE in pivot facet
[ https://issues.apache.org/jira/browse/SOLR-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646667#comment-16646667 ] Isabelle Giguere edited comment on SOLR-8921 at 10/19/18 2:25 PM: -- Solr 7.5.0 : Reproduced with a query on a text field, with an alias, even if each collections in the alias respond without error individually 'fileName' and 'author' are text field, 'fileType' is a string field - collection=de_alias&facet.field=author&facet.pivot=fileName = NPE - collection=lang_de&facet.field=author&facet.pivot=fileName = response OK - collection=emptyText&facet.field=author&facet.pivot=fileName = response OK - collection=de_alias&facet.field=author&facet.pivot=fileType = response OK I'll try to find time to devise a unit test to illustrate. Alternatively to this patch on PivotFacetProcessor, org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(Query q) could return DocSet.EMPTY if input Query is null, but that would have repercussions everywhere. was (Author: igiguere): Solr 7.5.0 : Reproduced with a query on an alias and text field, even if each collections in the alias respond without error individually 'name' and 'author' are text field, 'fileType' is a string field - collection=de_alias&facet.field=author&facet.pivot=name = NPE - collection=lang_de&facet.field=author&facet.pivot=name = respone OK - collection=emptyText&facet.field=author&facet.pivot=name = respone OK - collection=de&facet.field=author&facet.pivot=fileType = respone OK I'll try to find time to devise a unit test to illustrate. Alternatively to this patch on PivotFacetProcessor, org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(Query q) could return DocSet.EMPTY if input Query is null, but that would have repercussions everywhere. > Potential NPE in pivot facet > > > Key: SOLR-8921 > URL: https://issues.apache.org/jira/browse/SOLR-8921 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8921.patch, SOLR-8921.patch, > SOLR-8921_tag_7.5.0.patch > > > For some queries distributed over multiple collections, I've hit a NPE when > SolrIndexSearcher tries to fetch results from cache. Basically, query > generated to compute pivot on document sub set is null, causing the NPE on > lookup. > 2016-03-28 11:34:58.361 ERROR (qtp268141378-751) [c:otif_fr s:shard1 > r:core_node1 x:otif_fr_shard1_replica1] o.a.s.h.RequestHandlerBase > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) > at > org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:92) > at org.apache.solr.search.LFUCache.get(LFUCache.java:153) > at > org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:940) > at > org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2098) > at > org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:356) > at > org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:219) > at > org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:167) > at > org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:263) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(C
[jira] [Comment Edited] (SOLR-7913) Add stream.body support to MLT QParser
[ https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646715#comment-16646715 ] Isabelle Giguere edited comment on SOLR-7913 at 10/11/18 4:22 PM: -- Solr 7.5.0: Since Solr 7.1, requestParsers param enableStreamBody allows control over stream.body support, but stream.body still cannot be used with the MLT Qparser. Current behavior insists on looking for a doc id. SOLR-7913_tag_7.5.0.patch : Clean patch to allow stream.body im MLT QParser (no trace of SOLR-8604 as previously) Patch based on revision 61870, tag 7.5.0, latest release Notes: New class org.apache.solr.client.solrj.request.ContentStreamQueryRequest should override SolrRequest.getContentWriter(String) instead of SolrRequest.getContentStreams() Changes in org.apache.solr.request.json.RequestUtil allow stream.body on an MLT Qparser request, but test TestRemoteStreaming.testNoUrlAccess fails (meaning the test query doesn't fail), so is ignored for now. There should be a better fix, that would consider MLT QParser, Json requests, and still pass test TestRemoteStreaming.testNoUrlAccess - Set a contentType on MLT QParser requests with stream.body, and check for that contentType along with "/json" in RequestUtil ? - Require param 'json' on all Json requests ? Meaning the query at line 178 in TestJsonRequest.doJsonRequest(Client, boolean) would not be allowed There could be a more streamlined solution, closer to how requestParsers param enableStreamBody is supported elsewhere in the code ? was (Author: igiguere): Solr 7.5.0: Since Solr 7.1, requestParsers param enableStreamBody allows control over stream.body support, but stream.body still cannot be used with the MLT Qparser. Current behavior insists on looking for a doc id. SOLR-7913_tag_7.5.0.patch : Clean patch to allow stream.body im MLT QParser (no trace of SOLR-8604 as previously) Patch based on revision 61870, tag 7.5.0, latest release Notes: New class org.apache.solr.client.solrj.request.ContentStreamQueryRequest should override SolrRequest.getContentWriter(String) instead of SolrRequest.getContentStreams() Changes in org.apache.solr.request.json.RequestUtil allow stream.body on an MLT Qparser request, but test TestRemoteStreaming.testNoUrlAccess fails (meaning the test query doesn't fail), so is ignored for now. There should be a better fix, that would consider MLT QParser, Json requests, and still pass test TestRemoteStreaming.testNoUrlAccess - Set a contentType on MLT QParser requests with stream.body, and check for that contentType along with "/json" in RequestUtil ? - Require param 'json' on all Json requests ? Meaning the query at line 178 in TestJsonRequest.doJsonRequest(Client, boolean) would not be allowed There could be a more streamlined solution, closer to how requestParsers param enableStreamBody is supported elsewhere in the code. > Add stream.body support to MLT QParser > -- > > Key: SOLR-7913 > URL: https://issues.apache.org/jira/browse/SOLR-7913 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta >Priority: Major > Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, > SOLR-7913_fixTests.patch, SOLR-7913_tag_7.5.0.patch > > > Continuing from > https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011. > It'd be good to have stream.body be supported by the mlt qparser. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7913) Add stream.body support to MLT QParser
[ https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646715#comment-16646715 ] Isabelle Giguere commented on SOLR-7913: Solr 7.5.0: Since Solr 7.1, requestParsers param enableStreamBody allows control over stream.body support, but stream.body still cannot be used with the MLT Qparser. Current behavior insists on looking for a doc id. SOLR-7913_tag_7.5.0.patch : Clean patch to allow stream.body im MLT QParser (no trace of SOLR-8604 as previously) Patch based on revision 61870, tag 7.5.0, latest release Notes: New class org.apache.solr.client.solrj.request.ContentStreamQueryRequest should override SolrRequest.getContentWriter(String) instead of SolrRequest.getContentStreams() Changes in org.apache.solr.request.json.RequestUtil allow stream.body on an MLT Qparser request, but test TestRemoteStreaming.testNoUrlAccess fails (meaning the test query doesn't fail), so is ignored for now. There should be a better fix, that would consider MLT QParser, Json requests, and still pass test TestRemoteStreaming.testNoUrlAccess - Set a contentType on MLT QParser requests with stream.body, and check for that contentType along with "/json" in RequestUtil ? - Require param 'json' on all Json requests ? Meaning the query at line 178 in TestJsonRequest.doJsonRequest(Client, boolean) would not be allowed There could be a more streamlined solution, closer to how requestParsers param enableStreamBody is supported elsewhere in the code. > Add stream.body support to MLT QParser > -- > > Key: SOLR-7913 > URL: https://issues.apache.org/jira/browse/SOLR-7913 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta >Priority: Major > Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, > SOLR-7913_fixTests.patch, SOLR-7913_tag_7.5.0.patch > > > Continuing from > https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011. > It'd be good to have stream.body be supported by the mlt qparser. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7913) Add stream.body support to MLT QParser
[ https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabelle Giguere updated SOLR-7913: --- Attachment: SOLR-7913_tag_7.5.0.patch > Add stream.body support to MLT QParser > -- > > Key: SOLR-7913 > URL: https://issues.apache.org/jira/browse/SOLR-7913 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta >Priority: Major > Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, > SOLR-7913_fixTests.patch, SOLR-7913_tag_7.5.0.patch > > > Continuing from > https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011. > It'd be good to have stream.body be supported by the mlt qparser. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8921) Potential NPE in pivot facet
[ https://issues.apache.org/jira/browse/SOLR-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646667#comment-16646667 ] Isabelle Giguere commented on SOLR-8921: Solr 7.5.0 : Reproduced with a query on an alias and text field, even if each collections in the alias respond without error individually 'name' and 'author' are text field, 'fileType' is a string field - collection=de_alias&facet.field=author&facet.pivot=name = NPE - collection=lang_de&facet.field=author&facet.pivot=name = respone OK - collection=emptyText&facet.field=author&facet.pivot=name = respone OK - collection=de&facet.field=author&facet.pivot=fileType = respone OK I'll try to find time to devise a unit test to illustrate. Alternatively to this patch on PivotFacetProcessor, org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(Query q) could return DocSet.EMPTY if input Query is null, but that would have repercussions everywhere. > Potential NPE in pivot facet > > > Key: SOLR-8921 > URL: https://issues.apache.org/jira/browse/SOLR-8921 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8921.patch, SOLR-8921.patch, > SOLR-8921_tag_7.5.0.patch > > > For some queries distributed over multiple collections, I've hit a NPE when > SolrIndexSearcher tries to fetch results from cache. Basically, query > generated to compute pivot on document sub set is null, causing the NPE on > lookup. > 2016-03-28 11:34:58.361 ERROR (qtp268141378-751) [c:otif_fr s:shard1 > r:core_node1 x:otif_fr_shard1_replica1] o.a.s.h.RequestHandlerBase > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) > at > org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:92) > at org.apache.solr.search.LFUCache.get(LFUCache.java:153) > at > org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:940) > at > org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2098) > at > org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:356) > at > org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:219) > at > org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:167) > at > org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:263) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at org.eclipse.jetty.server.Server.handle(Server.java:499) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > at > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) > at > org.eclip
[jira] [Updated] (SOLR-8921) Potential NPE in pivot facet
[ https://issues.apache.org/jira/browse/SOLR-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabelle Giguere updated SOLR-8921: --- Attachment: SOLR-8921_tag_7.5.0.patch > Potential NPE in pivot facet > > > Key: SOLR-8921 > URL: https://issues.apache.org/jira/browse/SOLR-8921 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8921.patch, SOLR-8921.patch, > SOLR-8921_tag_7.5.0.patch > > > For some queries distributed over multiple collections, I've hit a NPE when > SolrIndexSearcher tries to fetch results from cache. Basically, query > generated to compute pivot on document sub set is null, causing the NPE on > lookup. > 2016-03-28 11:34:58.361 ERROR (qtp268141378-751) [c:otif_fr s:shard1 > r:core_node1 x:otif_fr_shard1_replica1] o.a.s.h.RequestHandlerBase > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) > at > org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:92) > at org.apache.solr.search.LFUCache.get(LFUCache.java:153) > at > org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:940) > at > org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2098) > at > org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:356) > at > org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:219) > at > org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:167) > at > org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:263) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at org.eclipse.jetty.server.Server.handle(Server.java:499) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > at > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8921) Potential NPE in pivot facet
[ https://issues.apache.org/jira/browse/SOLR-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646668#comment-16646668 ] Isabelle Giguere commented on SOLR-8921: SOLR-8921_tag_7.5.0.patch : same patch as before, on PivotFacetProcessor. Based on revision 61870, tag 7.5.0, latest release. > Potential NPE in pivot facet > > > Key: SOLR-8921 > URL: https://issues.apache.org/jira/browse/SOLR-8921 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8921.patch, SOLR-8921.patch, > SOLR-8921_tag_7.5.0.patch > > > For some queries distributed over multiple collections, I've hit a NPE when > SolrIndexSearcher tries to fetch results from cache. Basically, query > generated to compute pivot on document sub set is null, causing the NPE on > lookup. > 2016-03-28 11:34:58.361 ERROR (qtp268141378-751) [c:otif_fr s:shard1 > r:core_node1 x:otif_fr_shard1_replica1] o.a.s.h.RequestHandlerBase > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) > at > org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:92) > at org.apache.solr.search.LFUCache.get(LFUCache.java:153) > at > org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:940) > at > org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2098) > at > org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:356) > at > org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:219) > at > org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:167) > at > org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:263) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at org.eclipse.jetty.server.Server.handle(Server.java:499) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > at > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8394) Luke handler doesn't support FilterLeafReader
[ https://issues.apache.org/jira/browse/SOLR-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646656#comment-16646656 ] Isabelle Giguere commented on SOLR-8394: SOLR-8394_tag_7.5.0.patch : Same patch, on revision 61870, tag 7.5.0, latest release Simple test: http://localhost:8983/solr/all/admin/luke?wt=xml - without the patch : -1 -- -1 is the default return value ! - fixed by the patch : 299034 > Luke handler doesn't support FilterLeafReader > - > > Key: SOLR-8394 > URL: https://issues.apache.org/jira/browse/SOLR-8394 > Project: Solr > Issue Type: Improvement >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8394.patch, SOLR-8394.patch, > SOLR-8394_tag_7.5.0.patch > > > When fetching index information, luke handler only looks at ramBytesUsed for > SegmentReader leaves. If these readers are wrapped in FilterLeafReader, no > RAM usage is returned. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8394) Luke handler doesn't support FilterLeafReader
[ https://issues.apache.org/jira/browse/SOLR-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabelle Giguere updated SOLR-8394: --- Attachment: SOLR-8394_tag_7.5.0.patch > Luke handler doesn't support FilterLeafReader > - > > Key: SOLR-8394 > URL: https://issues.apache.org/jira/browse/SOLR-8394 > Project: Solr > Issue Type: Improvement >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8394.patch, SOLR-8394.patch, > SOLR-8394_tag_7.5.0.patch > > > When fetching index information, luke handler only looks at ramBytesUsed for > SegmentReader leaves. If these readers are wrapped in FilterLeafReader, no > RAM usage is returned. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8393) Component for Solr resource usage planning
[ https://issues.apache.org/jira/browse/SOLR-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabelle Giguere updated SOLR-8393: --- Attachment: SOLR-8393_tag_7.5.0.patch > Component for Solr resource usage planning > -- > > Key: SOLR-8393 > URL: https://issues.apache.org/jira/browse/SOLR-8393 > Project: Solr > Issue Type: Improvement >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, > SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, > SOLR-8393_tag_7.5.0.patch > > > One question that keeps coming back is how much disk and RAM do I need to run > Solr. The most common response is that it highly depends on your data. While > true, it makes for frustrated users trying to plan their deployments. > The idea I'm bringing is to create a new component that will attempt to > extrapolate resources needed in the future by looking at resources currently > used. By adding a parameter for the target number of documents, current > resources are adapted by a ratio relative to current number of documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8393) Component for Solr resource usage planning
[ https://issues.apache.org/jira/browse/SOLR-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646648#comment-16646648 ] Isabelle Giguere commented on SOLR-8393: SOLR-8393_tag_7.5.0.patch : Same patch, on revision 61870, tag 7.5.0, latest release > Component for Solr resource usage planning > -- > > Key: SOLR-8393 > URL: https://issues.apache.org/jira/browse/SOLR-8393 > Project: Solr > Issue Type: Improvement >Reporter: Steve Molloy >Priority: Major > Attachments: SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, > SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, > SOLR-8393_tag_7.5.0.patch > > > One question that keeps coming back is how much disk and RAM do I need to run > Solr. The most common response is that it highly depends on your data. While > true, it makes for frustrated users trying to plan their deployments. > The idea I'm bringing is to create a new component that will attempt to > extrapolate resources needed in the future by looking at resources currently > used. By adding a parameter for the target number of documents, current > resources are adapted by a ratio relative to current number of documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7864) timeAllowed causing ClassCastException
[
https://issues.apache.org/jira/browse/SOLR-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646644#comment-16646644
]
Isabelle Giguere commented on SOLR-7864:
The issue still occurs on 7.5.0 !
SOLR-7864_tag_7.5.0.patch : Patch on revision 61870, tag 7.5.0, latest release
> timeAllowed causing ClassCastException
> --
>
> Key: SOLR-7864
> URL: https://issues.apache.org/jira/browse/SOLR-7864
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.2
>Reporter: Markus Jelsma
>Priority: Major
> Attachments: SOLR-7864.patch, SOLR-7864.patch, SOLR-7864_extra.patch,
> SOLR-7864_tag_7.5.0.patch
>
>
> If timeAllowed kicks in, following exception is thrown and user gets HTTP 500.
> {code}
> 65219 [qtp2096057945-19] ERROR org.apache.solr.servlet.SolrDispatchFilter [
> search] – null:java.lang.ClassCastException:
> org.apache.solr.response.ResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:275)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:497)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7864) timeAllowed causing ClassCastException
[
https://issues.apache.org/jira/browse/SOLR-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isabelle Giguere updated SOLR-7864:
---
Attachment: SOLR-7864_tag_7.5.0.patch
> timeAllowed causing ClassCastException
> --
>
> Key: SOLR-7864
> URL: https://issues.apache.org/jira/browse/SOLR-7864
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.2
>Reporter: Markus Jelsma
>Priority: Major
> Attachments: SOLR-7864.patch, SOLR-7864.patch, SOLR-7864_extra.patch,
> SOLR-7864_tag_7.5.0.patch
>
>
> If timeAllowed kicks in, following exception is thrown and user gets HTTP 500.
> {code}
> 65219 [qtp2096057945-19] ERROR org.apache.solr.servlet.SolrDispatchFilter [
> search] – null:java.lang.ClassCastException:
> org.apache.solr.response.ResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:275)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:497)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646641#comment-16646641
]
Isabelle Giguere commented on SOLR-7642:
SOLR-7642_tag_7.5.0.patch : Same patch, on revision 61870, tag 7.5.0, latest
release
> Should launching Solr in cloud mode using a ZooKeeper chroot create the
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
> Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch,
> SOLR-7642_tag_7.5.0.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper
> connection string that includes a chroot leads to the following
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
> is that some violation of using a chroot?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isabelle Giguere updated SOLR-7642:
---
Attachment: SOLR-7642_tag_7.5.0.patch
> Should launching Solr in cloud mode using a ZooKeeper chroot create the
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
> Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch,
> SOLR-7642_tag_7.5.0.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper
> connection string that includes a chroot leads to the following
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
> is that some violation of using a chroot?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11198) downconfig downloads empty file as folder
[ https://issues.apache.org/jira/browse/SOLR-11198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16133608#comment-16133608 ] Isabelle Giguere commented on SOLR-11198: - Compiled and tested on Windows to confirm the patch works (obviously, if you look at it ;) ) > downconfig downloads empty file as folder > - > > Key: SOLR-11198 > URL: https://issues.apache.org/jira/browse/SOLR-11198 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 > Environment: Windows 7 >Reporter: Isabelle Giguere >Assignee: Erick Erickson >Priority: Minor > Fix For: 6.7, master (8.0), 7.1 > > Attachments: SOLR-11198.patch, SOLR-11198.patch > > > With Solr 6.6.0, when downloading a config from Zookeeper (3.4.10), if a file > is empty, it is downloaded as a folder (on Windows, at least). > A Zookeeper browser (Eclipse: Zookeeper Explorer) shows the file as a file, > however, in ZK. > Noticed because we keep an empty synonyms.txt file in the Solr config > provided with our product, in case a client would want to use it. > The workaround is simple, since the file allows comments: just add a comment, > so it is not empty. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11210) Confusing name for aliases in ZK
[
https://issues.apache.org/jira/browse/SOLR-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isabelle Giguere updated SOLR-11210:
Description:
There's a confusing discrepancy between the aliases information stored in
Zookeeper and the information returned by LISTALIASES.
http://localhost:8983/solr/admin/collections?action=CREATEALIAS&name=alias1&collections=collection0,collection1
http://localhost:8983/solr/admin/collections?action=LISTALIASES&wt=json
{"responseHeader":{"status":0,"QTime":0},"aliases":{"alias1":"collection0,collection1"}}
zkCLI -zkHost localhost:2181/solr -cmd getfile /aliases.json
/aliases_ZK_output.json
{"collection":{
"alias1":"collection0,collection1"}}
The information stored in ZK looks like a NamedList named "collection", which
doesn't make any sense. It should be named "aliases".
org.apache.solr.handler.admin.CollectionsHandler.CollectionOperation.LISTALIASES_OP
adds the value of the ZK response to a NamedList called "aliases", so it
doesn't show outside ZK.
was:
There's a confusing discrepancy between the aliases information stored in
Zookeeper and the information returned by LISTALIASES.
http://localhost:8983/solr/admin/collections?action=CREATEALIAS&name=alias1&collections=collection0,collection1
http://localhost:8983/solr/admin/collections?action=LISTALIASES&wt=json
{"responseHeader":{"status":0,"QTime":0},"aliases":{"all":"alias1":"collection0,collection1"}}
zkCLI -zkHost localhost:2181/solr -cmd getfile /aliases.json
/aliases_ZK_output.json
{"collection":{
"alias1":"collection0,collection1"}}
The information stored in ZK looks like a NamedList named "collection", which
doesn't make any sense. It should be named "aliases".
org.apache.solr.handler.admin.CollectionsHandler.CollectionOperation.LISTALIASES_OP
adds the value of the ZK response to a NamedList called "aliases", so it
doesn't show outside ZK.
> Confusing name for aliases in ZK
>
>
> Key: SOLR-11210
> URL: https://issues.apache.org/jira/browse/SOLR-11210
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6
>Reporter: Isabelle Giguere
>Priority: Minor
>
> There's a confusing discrepancy between the aliases information stored in
> Zookeeper and the information returned by LISTALIASES.
> http://localhost:8983/solr/admin/collections?action=CREATEALIAS&name=alias1&collections=collection0,collection1
> http://localhost:8983/solr/admin/collections?action=LISTALIASES&wt=json
> {"responseHeader":{"status":0,"QTime":0},"aliases":{"alias1":"collection0,collection1"}}
> zkCLI -zkHost localhost:2181/solr -cmd getfile /aliases.json
> /aliases_ZK_output.json
> {"collection":{
> "alias1":"collection0,collection1"}}
> The information stored in ZK looks like a NamedList named "collection", which
> doesn't make any sense. It should be named "aliases".
> org.apache.solr.handler.admin.CollectionsHandler.CollectionOperation.LISTALIASES_OP
> adds the value of the ZK response to a NamedList called "aliases", so it
> doesn't show outside ZK.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11210) Confusing name for aliases in ZK
Isabelle Giguere created SOLR-11210:
---
Summary: Confusing name for aliases in ZK
Key: SOLR-11210
URL: https://issues.apache.org/jira/browse/SOLR-11210
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6
Reporter: Isabelle Giguere
Priority: Minor
There's a confusing discrepancy between the aliases information stored in
Zookeeper and the information returned by LISTALIASES.
http://localhost:8983/solr/admin/collections?action=CREATEALIAS&name=alias1&collections=collection0,collection1
http://localhost:8983/solr/admin/collections?action=LISTALIASES&wt=json
{"responseHeader":{"status":0,"QTime":0},"aliases":{"all":"alias1":"collection0,collection1"}}
zkCLI -zkHost localhost:2181/solr -cmd getfile /aliases.json
/aliases_ZK_output.json
{"collection":{
"alias1":"collection0,collection1"}}
The information stored in ZK looks like a NamedList named "collection", which
doesn't make any sense. It should be named "aliases".
org.apache.solr.handler.admin.CollectionsHandler.CollectionOperation.LISTALIASES_OP
adds the value of the ZK response to a NamedList called "aliases", so it
doesn't show outside ZK.
--
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-11198) downconfig downloads empty file as folder
[ https://issues.apache.org/jira/browse/SOLR-11198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115023#comment-16115023 ] Isabelle Giguere edited comment on SOLR-11198 at 8/4/17 10:41 PM: -- My command (on Windows) > java -cp "C:\Path\to\lib\*" org.apache.solr.cloud.ZkCLI -cmd downconfig > -zkhost localhost:2181/ot/solr -confname otif_en -confdir > "C:\Path\to\output\otif_en" Note that I cannot reproduce the issue using Zookeeper 3.4.6 and Solr 5.4.1, with exactly the same command. We just upgraded to Zookeeper 3.4.10 and Solr 6.6.0 I'll try Zookeeper 3.4.6 with Solr 6.6.0, and Zookeeper 3.4.10 with Solr 5.4.1, if it can help narrow things down. Update : No matter what version of Zookeeper, -cmd downconfig : - Solr 6.6.0 outputs the empty synonyms.txt file as a folder. - Solr 5.4.1 outputs the empty synonyms.txt file as a file. was (Author: igiguere): My command (on Windows) > java -cp "C:\Path\to\lib\*" org.apache.solr.cloud.ZkCLI -cmd downconfig > -zkhost localhost:2181/ot/solr -confname otif_en -confdir > "C:\Path\to\output\otif_en" Note that I cannot reproduce the issue using Zookeeper 3.4.6 and Solr 5.4.1, with exactly the same command. We just upgraded to Zookeeper 3.4.10 and Solr 6.6.0 I'll try Zookeeper 3.4.6 with Solr 6.6.0, and Zookeeper 3.4.10 with Solr 5.4.1, if it can help narrow things down. > downconfig downloads empty file as folder > - > > Key: SOLR-11198 > URL: https://issues.apache.org/jira/browse/SOLR-11198 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 > Environment: Windows 7 >Reporter: Isabelle Giguere >Priority: Minor > > With Solr 6.6.0, when downloading a config from Zookeeper (3.4.10), if a file > is empty, it is downloaded as a folder (on Windows, at least). > A Zookeeper browser (Eclipse: Zookeeper Explorer) shows the file as a file, > however, in ZK. > Noticed because we keep an empty synonyms.txt file in the Solr config > provided with our product, in case a client would want to use it. > The workaround is simple, since the file allows comments: just add a comment, > so it is not empty. -- 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-11198) downconfig downloads empty file as folder
[ https://issues.apache.org/jira/browse/SOLR-11198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115023#comment-16115023 ] Isabelle Giguere commented on SOLR-11198: - My command (on Windows) > java -cp "C:\Path\to\lib\*" org.apache.solr.cloud.ZkCLI -cmd downconfig > -zkhost localhost:2181/ot/solr -confname otif_en -confdir > "C:\Path\to\output\otif_en" Note that I cannot reproduce the issue using Zookeeper 3.4.6 and Solr 5.4.1, with exactly the same command. We just upgraded to Zookeeper 3.4.10 and Solr 6.6.0 I'll try Zookeeper 3.4.6 with Solr 6.6.0, and Zookeeper 3.4.10 with Solr 5.4.1, if it can help narrow things down. > downconfig downloads empty file as folder > - > > Key: SOLR-11198 > URL: https://issues.apache.org/jira/browse/SOLR-11198 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 > Environment: Windows 7 >Reporter: Isabelle Giguere >Priority: Minor > > With Solr 6.6.0, when downloading a config from Zookeeper (3.4.10), if a file > is empty, it is downloaded as a folder (on Windows, at least). > A Zookeeper browser (Eclipse: Zookeeper Explorer) shows the file as a file, > however, in ZK. > Noticed because we keep an empty synonyms.txt file in the Solr config > provided with our product, in case a client would want to use it. > The workaround is simple, since the file allows comments: just add a comment, > so it is not empty. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11198) downconfig downloads empty file as folder
Isabelle Giguere created SOLR-11198: --- Summary: downconfig downloads empty file as folder Key: SOLR-11198 URL: https://issues.apache.org/jira/browse/SOLR-11198 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 6.6 Environment: Windows 7 Reporter: Isabelle Giguere Priority: Minor With Solr 6.6.0, when downloading a config from Zookeeper (3.4.10), if a file is empty, it is downloaded as a folder (on Windows, at least). A Zookeeper browser (Eclipse: Zookeeper Explorer) shows the file as a file, however, in ZK. Noticed because we keep an empty synonyms.txt file in the Solr config provided with our product, in case a client would want to use it. The workaround is simple, since the file allows comments: just add a comment, so it is not empty. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7913) Add stream.body support to MLT QParser
[ https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabelle Giguere updated SOLR-7913: --- Attachment: SOLR-7913_fixTests.patch Oops! My patch on Solr 6.6.0 makes these 3 tests fail : org.apache.solr.search.TestSmileRequest.testDistribJsonRequest org.apache.solr.search.json.TestJsonRequest.testLocalJsonRequest org.apache.solr.search.json.TestJsonRequest.testDistribJsonRequest Adding SOLR-7913_fixTests.patch, to be applied on top of SOLR-7913.patch (2017-07-20). It contains a ridiculous, horrifying hack. But the advantage is that the 3 search tests listed above pass, and it also allows to re-enable org.apache.solr.request.TestRemoteStreaming.testNoUrlAccess(). A boolean to filter only MLT with stream.body has a lot less impact everywhere else. I ran all solr tests, this time ;) > Add stream.body support to MLT QParser > -- > > Key: SOLR-7913 > URL: https://issues.apache.org/jira/browse/SOLR-7913 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta > Attachments: SOLR-7913_fixTests.patch, SOLR-7913.patch, > SOLR-7913.patch, SOLR-7913.patch > > > Continuing from > https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011. > It'd be good to have stream.body be supported by the mlt qparser. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7864) timeAllowed causing ClassCastException
[
https://issues.apache.org/jira/browse/SOLR-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isabelle Giguere updated SOLR-7864:
---
Attachment: SOLR-7864_extra.patch
Attaching an extra fix, for Solr 6.6.0, rediscovered in our code base ;)
Apply SOLR-7864 on July 7th, 2017, first, then the extra.
> timeAllowed causing ClassCastException
> --
>
> Key: SOLR-7864
> URL: https://issues.apache.org/jira/browse/SOLR-7864
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.2
>Reporter: Markus Jelsma
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-7864_extra.patch, SOLR-7864.patch, SOLR-7864.patch
>
>
> If timeAllowed kicks in, following exception is thrown and user gets HTTP 500.
> {code}
> 65219 [qtp2096057945-19] ERROR org.apache.solr.servlet.SolrDispatchFilter [
> search] – null:java.lang.ClassCastException:
> org.apache.solr.response.ResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:275)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:497)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
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-7913) Add stream.body support to MLT QParser
[ https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16095452#comment-16095452 ] Isabelle Giguere commented on SOLR-7913: One more note about the patch for Solr 6.6.0, that I just attached: CloudMLTQParser contains the changes done in the patch for SOLR-8604. If, for some strange reason, you don't want support for the "collection" parameter in MLT queries, just ignore in patch SOLR-7913 the changes to method CloudMLTQParser.getDocument(String,String), so that you keep the previous version, with just one parameter. If you do want support for the "collection" parameter in MLT queries, then you need to apply SOLR-8604 too. It's easier to weed out SOLR-8604 from SOLR-7913 than the reverse ! [~upayavira] : this patch is not as messy as the previous, I did not incorporate the useless layout changes. > Add stream.body support to MLT QParser > -- > > Key: SOLR-7913 > URL: https://issues.apache.org/jira/browse/SOLR-7913 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta > Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch > > > Continuing from > https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011. > It'd be good to have stream.body be supported by the mlt qparser. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7913) Add stream.body support to MLT QParser
[ https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabelle Giguere updated SOLR-7913: --- Attachment: SOLR-7913.patch Patch SOLR-7913, updated to Solr 6.6.0. Adding unit tests. First 2 unit tests in CloudMLTQParserTest look scary, because the results are so different, between the MLT query with id, and the "equivalent" query with stream.body. I tested locally, to compare results with Solr 5.4.1 + patch (in our product, currently) and Solr 6.6.0 + patch, and there is no important difference, when comparing results of MLT with stream.body between Solr versions. That's the important thing for us... Your opinion may differ. I'm actually more puzzled that SimpleMLTQParser retrieves exactly the same results with id, and with stream.body! How does it know what document to remove? One note about that weird "TODO" in RequestUtils : why not let the handler propagate the content-type it expects, if any, instead of trying to guess in the utility method? I'm not sure exactly where/how to do that, and how much impact it would have. > Add stream.body support to MLT QParser > -- > > Key: SOLR-7913 > URL: https://issues.apache.org/jira/browse/SOLR-7913 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta > Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch > > > Continuing from > https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011. > It'd be good to have stream.body be supported by the mlt qparser. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8604) RealTimeGet and MLT qParser support for collection parameter
[ https://issues.apache.org/jira/browse/SOLR-8604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabelle Giguere updated SOLR-8604: --- Attachment: SOLR-8604.patch Cleaned up and updated to Solr 6.6.0. Adding unit tests. The original patch for Solr 5 contained also some partial support for SOLR-7913, which made it difficult to integrate and test individually. This patch for Solr 6.6 contains only support for the "collection" query parameter in RealTimeGetComponent and CloudMLTQParser. Also tested locally on a sample Solr with 2 collections: alias is supported, but not in unit tests. > RealTimeGet and MLT qParser support for collection parameter > > > Key: SOLR-8604 > URL: https://issues.apache.org/jira/browse/SOLR-8604 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.3.1 >Reporter: Steve Molloy > Attachments: SOLR-8604.patch, SOLR-8604.patch > > > The MLT query parser performs a realtime get to fetch document by id if it is > specified. As realtime get works only within a specific collection, so does > MLT. If collection parameter is supplied, it should be used both in MLT > qparser and realtime get to fetch the document in any collection, and to use > it for similarity in the case of MLT. -- 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-8393) Component for Solr resource usage planning
[
https://issues.apache.org/jira/browse/SOLR-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090786#comment-16090786
]
Isabelle Giguere edited comment on SOLR-8393 at 7/17/17 11:24 PM:
--
Updated and improved patch, for Solr 6.6.0
Adding unit tests for the SizeComponent.
Adding a new parameter, 'sizeUnit', to address [~elyograg] 's comment.
If parameter 'sizeUnit' is present, values will be output as 'double',
according to the chosen size unit.
Value of 'estimated-num-docs' remains a 'long'.
Default behavior, if 'sizeUnit' is not present is the human-readable format,
for back-compatibility.
Valid values for 'sizeUnit' are : GB, MB, KB, bytes
Example:
{noformat}
q=*:*&size=true&sizeUnit=GB&rows=0&wt=xml
{noformat}
{noformat}
0
0
*:*
true
GB
0
xml
2.2901222109794617E-6
0.03125092852860689
0.03147673141211271
6
3.809109330177307E-7
9.894371032714844E-6
2.13623046875E-4
2.2854655981063843E-6
0.03125092852860689
{noformat}
GB is a bit much for a unit test sample size, but you get the idea ;)
was (Author: igiguere):
Updated and improved patch, for Solr 6.6.0
Adding unit tests for the SizeComponent.
Adding a new parameter, 'sizeUnit', to address [~elyograg] 's comment.
If parameter 'sizeUnit' is present, values will be output as 'double',
according to the chosen size unit.
Value of 'estimated-num-docs' remains a 'long'.
Default behavior, if 'sizeUnit' is not present is the human-readable format,
for back-compatibility.
Example:
{noformat}
q=*:*&size=true&sizeUnit=GB&rows=0&wt=xml
{noformat}
{noformat}
0
0
*:*
true
GB
0
xml
2.2901222109794617E-6
0.03125092852860689
0.03147673141211271
6
3.809109330177307E-7
9.894371032714844E-6
2.13623046875E-4
2.2854655981063843E-6
0.03125092852860689
{noformat}
GB is a bit much for a unit test sample size, but you get the idea ;)
> Component for Solr resource usage planning
> --
>
> Key: SOLR-8393
> URL: https://issues.apache.org/jira/browse/SOLR-8393
> Project: Solr
> Issue Type: Improvement
>Reporter: Steve Molloy
> Attachments: SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch,
> SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch
>
>
> One question that keeps coming back is how much disk and RAM do I need to run
> Solr. The most common response is that it highly depends on your data. While
> true, it makes for frustrated users trying to plan their deployments.
> The idea I'm bringing is to create a new component that will attempt to
> extrapolate resources needed in the future by looking at resources currently
> used. By adding a parameter for the target number of documents, current
> resources are adapted by a ratio relative to current number of documents.
--
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-8393) Component for Solr resource usage planning
[
https://issues.apache.org/jira/browse/SOLR-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090786#comment-16090786
]
Isabelle Giguere edited comment on SOLR-8393 at 7/17/17 11:23 PM:
--
Updated and improved patch, for Solr 6.6.0
Adding unit tests for the SizeComponent.
Adding a new parameter, 'sizeUnit', to address [~elyograg] 's comment.
If parameter 'sizeUnit' is present, values will be output as 'double',
according to the chosen size unit.
Value of 'estimated-num-docs' remains a 'long'.
Default behavior, if 'sizeUnit' is not present is the human-readable format,
for back-compatibility.
Example:
{noformat}
q=*:*&size=true&sizeUnit=GB&rows=0&wt=xml
{noformat}
{noformat}
0
0
*:*
true
GB
0
xml
2.2901222109794617E-6
0.03125092852860689
0.03147673141211271
6
3.809109330177307E-7
9.894371032714844E-6
2.13623046875E-4
2.2854655981063843E-6
0.03125092852860689
{noformat}
GB is a bit much for a unit test sample size, but you get the idea ;)
was (Author: igiguere):
Updated and improved patch, for Solr 6.6.0
Adding unit tests for the SizeComponent.
Adding a new parameter, 'sizeUnit', to address [~elyograg] 's comment.
If parameter 'sizeUnit' is present, values will be output as 'double',
according to the chosen size unit.
Value of 'estimated-num-docs' remains a 'long'.
Default behavior, if 'sizeUnit' is present is the human-readable format, for
back-compatibility.
Example:
{noformat}
q=*:*&size=true&sizeUnit=GB&rows=0&wt=xml
{noformat}
{noformat}
0
0
*:*
true
GB
0
xml
2.2901222109794617E-6
0.03125092852860689
0.03147673141211271
6
3.809109330177307E-7
9.894371032714844E-6
2.13623046875E-4
2.2854655981063843E-6
0.03125092852860689
{noformat}
GB is a bit much for a unit test sample size, but you get the idea ;)
> Component for Solr resource usage planning
> --
>
> Key: SOLR-8393
> URL: https://issues.apache.org/jira/browse/SOLR-8393
> Project: Solr
> Issue Type: Improvement
>Reporter: Steve Molloy
> Attachments: SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch,
> SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch
>
>
> One question that keeps coming back is how much disk and RAM do I need to run
> Solr. The most common response is that it highly depends on your data. While
> true, it makes for frustrated users trying to plan their deployments.
> The idea I'm bringing is to create a new component that will attempt to
> extrapolate resources needed in the future by looking at resources currently
> used. By adding a parameter for the target number of documents, current
> resources are adapted by a ratio relative to current number of documents.
--
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-8393) Component for Solr resource usage planning
[
https://issues.apache.org/jira/browse/SOLR-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090786#comment-16090786
]
Isabelle Giguere edited comment on SOLR-8393 at 7/17/17 11:22 PM:
--
Updated and improved patch, for Solr 6.6.0
Adding unit tests for the SizeComponent.
Adding a new parameter, 'sizeUnit', to address [~elyograg] 's comment.
If parameter 'sizeUnit' is present, values will be output as 'double',
according to the chosen size unit.
Value of 'estimated-num-docs' remains a 'long'.
Default behavior, if 'sizeUnit' is present is the human-readable format, for
back-compatibility.
Example:
{noformat}
q=*:*&size=true&sizeUnit=GB&rows=0&wt=xml
{noformat}
{noformat}
0
0
*:*
true
GB
0
xml
2.2901222109794617E-6
0.03125092852860689
0.03147673141211271
6
3.809109330177307E-7
9.894371032714844E-6
2.13623046875E-4
2.2854655981063843E-6
0.03125092852860689
{noformat}
GB is a bit much for a unit test sample size, but you get the idea ;)
was (Author: igiguere):
Updated and improved patch, for Solr 6.6.0
Adding unit tests for the SizeComponent.
Adding a new parameter, 'sizeUnit', to address @Shawn Heisey 's comment.
If parameter 'sizeUnit' is present, values will be output as 'double',
according to the chosen size unit.
Value of 'estimated-num-docs' remains a 'long'.
Default behavior, if 'sizeUnit' is present is the human-readable format, for
back-compatibility.
Example:
{noformat}
q=*:*&size=true&sizeUnit=GB&rows=0&wt=xml
{noformat}
{noformat}
0
0
*:*
true
GB
0
xml
2.2901222109794617E-6
0.03125092852860689
0.03147673141211271
6
3.809109330177307E-7
9.894371032714844E-6
2.13623046875E-4
2.2854655981063843E-6
0.03125092852860689
{noformat}
GB is a bit much for a unit test sample size, but you get the idea ;)
> Component for Solr resource usage planning
> --
>
> Key: SOLR-8393
> URL: https://issues.apache.org/jira/browse/SOLR-8393
> Project: Solr
> Issue Type: Improvement
>Reporter: Steve Molloy
> Attachments: SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch,
> SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch
>
>
> One question that keeps coming back is how much disk and RAM do I need to run
> Solr. The most common response is that it highly depends on your data. While
> true, it makes for frustrated users trying to plan their deployments.
> The idea I'm bringing is to create a new component that will attempt to
> extrapolate resources needed in the future by looking at resources currently
> used. By adding a parameter for the target number of documents, current
> resources are adapted by a ratio relative to current number of documents.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8393) Component for Solr resource usage planning
[
https://issues.apache.org/jira/browse/SOLR-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isabelle Giguere updated SOLR-8393:
---
Attachment: SOLR-8393.patch
Updated and improved patch, for Solr 6.6.0
Adding unit tests for the SizeComponent.
Adding a new parameter, 'sizeUnit', to address @Shawn Heisey 's comment.
If parameter 'sizeUnit' is present, values will be output as 'double',
according to the chosen size unit.
Value of 'estimated-num-docs' remains a 'long'.
Default behavior, if 'sizeUnit' is present is the human-readable format, for
back-compatibility.
Example:
{noformat}
q=*:*&size=true&sizeUnit=GB&rows=0&wt=xml
{noformat}
{noformat}
0
0
*:*
true
GB
0
xml
2.2901222109794617E-6
0.03125092852860689
0.03147673141211271
6
3.809109330177307E-7
9.894371032714844E-6
2.13623046875E-4
2.2854655981063843E-6
0.03125092852860689
{noformat}
GB is a bit much for a unit test sample size, but you get the idea ;)
> Component for Solr resource usage planning
> --
>
> Key: SOLR-8393
> URL: https://issues.apache.org/jira/browse/SOLR-8393
> Project: Solr
> Issue Type: Improvement
>Reporter: Steve Molloy
> Attachments: SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch,
> SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch
>
>
> One question that keeps coming back is how much disk and RAM do I need to run
> Solr. The most common response is that it highly depends on your data. While
> true, it makes for frustrated users trying to plan their deployments.
> The idea I'm bringing is to create a new component that will attempt to
> extrapolate resources needed in the future by looking at resources currently
> used. By adding a parameter for the target number of documents, current
> resources are adapted by a ratio relative to current number of documents.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7864) timeAllowed causing ClassCastException
[
https://issues.apache.org/jira/browse/SOLR-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isabelle Giguere updated SOLR-7864:
---
Attachment: SOLR-7864.patch
Attaching the same patch, for Solr 6.6.0
> timeAllowed causing ClassCastException
> --
>
> Key: SOLR-7864
> URL: https://issues.apache.org/jira/browse/SOLR-7864
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.2
>Reporter: Markus Jelsma
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-7864.patch, SOLR-7864.patch
>
>
> If timeAllowed kicks in, following exception is thrown and user gets HTTP 500.
> {code}
> 65219 [qtp2096057945-19] ERROR org.apache.solr.servlet.SolrDispatchFilter [
> search] – null:java.lang.ClassCastException:
> org.apache.solr.response.ResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:275)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:497)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8394) Luke handler doesn't support FilterLeafReader
[ https://issues.apache.org/jira/browse/SOLR-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabelle Giguere updated SOLR-8394: --- Attachment: SOLR-8394.patch Same patch, adapted to Solr 6.6.0 > Luke handler doesn't support FilterLeafReader > - > > Key: SOLR-8394 > URL: https://issues.apache.org/jira/browse/SOLR-8394 > Project: Solr > Issue Type: Improvement >Reporter: Steve Molloy > Attachments: SOLR-8394.patch, SOLR-8394.patch > > > When fetching index information, luke handler only looks at ramBytesUsed for > SegmentReader leaves. If these readers are wrapped in FilterLeafReader, no > RAM usage is returned. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8921) Potential NPE in pivot facet
[ https://issues.apache.org/jira/browse/SOLR-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabelle Giguere updated SOLR-8921: --- Attachment: SOLR-8921.patch Identical patch based on Solr 6.6.0. No change in code, the old patch could still be used. I which I could have added a unit test... see previous comment. > Potential NPE in pivot facet > > > Key: SOLR-8921 > URL: https://issues.apache.org/jira/browse/SOLR-8921 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: Steve Molloy > Attachments: SOLR-8921.patch, SOLR-8921.patch > > > For some queries distributed over multiple collections, I've hit a NPE when > SolrIndexSearcher tries to fetch results from cache. Basically, query > generated to compute pivot on document sub set is null, causing the NPE on > lookup. > 2016-03-28 11:34:58.361 ERROR (qtp268141378-751) [c:otif_fr s:shard1 > r:core_node1 x:otif_fr_shard1_replica1] o.a.s.h.RequestHandlerBase > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) > at > org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:92) > at org.apache.solr.search.LFUCache.get(LFUCache.java:153) > at > org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:940) > at > org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2098) > at > org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:356) > at > org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:219) > at > org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:167) > at > org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:263) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at org.eclipse.jetty.server.Server.handle(Server.java:499) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > at > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) > at java.lang.Thread.run(Thread.java:745) -- 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-8921) Potential NPE in pivot facet
[
https://issues.apache.org/jira/browse/SOLR-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16088224#comment-16088224
]
Isabelle Giguere commented on SOLR-8921:
A null query could be created by passing an empty string as the 3rd argument of
org.apache.solr.schema.FieldType.getFieldQuery(QParser parser, SchemaField
field, String externalVal)
As in
org.apache.solr.handler.component.PivotFacetProcessor#getSubset(DocSet,
SchemaField, String)
and
org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(DocSet,
SchemaField, String)
Ex:
final SolrIndexSearcher searcher = req.getSearcher();
final SchemaField sfield = searcher.getSchema().getField("place_t");
final Query query = sfield.getType().getFieldQuery(null, sfield, "");
assertNull("Query should be null", query);
I have not been able to devise a unit test that would produce an empty string
at this location. And since Steve forgot to include his query parameters, it
could be a very long haul trying to guess, with the number of available
parameters for facet pivots.
I'm applying the "fix" as-is.
> Potential NPE in pivot facet
>
>
> Key: SOLR-8921
> URL: https://issues.apache.org/jira/browse/SOLR-8921
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.4.1
>Reporter: Steve Molloy
> Attachments: SOLR-8921.patch
>
>
> For some queries distributed over multiple collections, I've hit a NPE when
> SolrIndexSearcher tries to fetch results from cache. Basically, query
> generated to compute pivot on document sub set is null, causing the NPE on
> lookup.
> 2016-03-28 11:34:58.361 ERROR (qtp268141378-751) [c:otif_fr s:shard1
> r:core_node1 x:otif_fr_shard1_replica1] o.a.s.h.RequestHandlerBase
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at
> org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:92)
> at org.apache.solr.search.LFUCache.get(LFUCache.java:153)
> at
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:940)
> at
> org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2098)
> at
> org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:356)
> at
> org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:219)
> at
> org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:167)
> at
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:263)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at
> o
[jira] [Updated] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isabelle Giguere updated SOLR-7642:
---
Attachment: SOLR-7642.patch
[~smolloy] 's patch, updated to Solr 6.6.0
> Should launching Solr in cloud mode using a ZooKeeper chroot create the
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
> Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper
> connection string that includes a chroot leads to the following
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
> is that some violation of using a chroot?
--
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-10895) Upgrade to Tika 1.14
[ https://issues.apache.org/jira/browse/SOLR-10895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050872#comment-16050872 ] Isabelle Giguere commented on SOLR-10895: - Sorry for the duplicate, and thanks for the links. I didn't see it in my search results. > Upgrade to Tika 1.14 > > > Key: SOLR-10895 > URL: https://issues.apache.org/jira/browse/SOLR-10895 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 5.4.1, 6.6 >Reporter: Isabelle Giguere > > "Apache Tika before 1.14 allows Java code execution for serialized objects > embedded in MATLAB files. The issue exists because Tika invokes JMatIO to do > native deserialization." > a few links: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6809 > https://nvd.nist.gov/vuln/detail/CVE-2016-6809 > ** > This was originally reported by my employer's Security Analysis team. > We are still on Solr 5.4.1. It would be good to know that this security > issue could be fixed with an eventual Solr upgrade. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10895) Upgrade to Tika 1.14
Isabelle Giguere created SOLR-10895: --- Summary: Upgrade to Tika 1.14 Key: SOLR-10895 URL: https://issues.apache.org/jira/browse/SOLR-10895 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 6.6, 5.4.1 Reporter: Isabelle Giguere "Apache Tika before 1.14 allows Java code execution for serialized objects embedded in MATLAB files. The issue exists because Tika invokes JMatIO to do native deserialization." a few links: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6809 https://nvd.nist.gov/vuln/detail/CVE-2016-6809 ** This was originally reported by my employer's Security Analysis team. We are still on Solr 5.4.1. It would be good to know that this security issue could be fixed with an eventual Solr upgrade. -- 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
