[jira] [Resolved] (SOLR-13714) Incorrect shardHandlerFactory config element documented in refguide for "distributed requests"
[
https://issues.apache.org/jira/browse/SOLR-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett resolved SOLR-13714.
--
Fix Version/s: 8.2
Assignee: Cassandra Targett
Resolution: Fixed
> Incorrect shardHandlerFactory config element documented in refguide for
> "distributed requests"
> --
>
> Key: SOLR-13714
> URL: https://issues.apache.org/jira/browse/SOLR-13714
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 7.7.2, 8.1.1
>Reporter: Michael Gibney
>Assignee: Cassandra Targett
>Priority: Trivial
> Fix For: 8.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Reference guide documentation is inconsistent with respect to configuration
> of {{shardHandlerFactory}} in {{solrconfig.xml}}.
> The correct config element name is "{{shardHandlerFactory}}", as reflected in
> code [in
> SolrXmlConfig.java|https://github.com/apache/lucene-solr/blob/301ea0e/solr/core/src/java/org/apache/solr/core/SolrXmlConfig.java#L460]
> and [in
> SearchHandler.java|https://github.com/apache/lucene-solr/blob/43fc05c/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L97].
> The element name is documented correctly in the [refGuide page for "Format of
> solr.xml"|https://lucene.apache.org/solr/guide/8_1/format-of-solr-xml.html#the-shardhandlerfactory-element],
> but it is documented incorrectly (as "{{shardHandler}}", not
> "{{shardHandlerFactory}}" in the [refGuide page for "Distributed
> Requests"|https://lucene.apache.org/solr/guide/8_1/distributed-requests.html#configuring-the-shardhandlerfactory].
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909061#comment-16909061 ] Cassandra Targett commented on SOLR-13452: -- For the docs, there is a plugin for Gradle from the Asciidoctor community (https://github.com/asciidoctor/asciidoctor-gradle-plugin), which is (IMO) better and more frequently maintained than the one currently we use for Ant. That would take care of the PDF. Since we use Jekyll for the HTML version, though, that's going to work a little differently and I'll start taking a look at what we might need to do there. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13523) Atomic Update results in NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-13523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16897597#comment-16897597
]
Cassandra Targett commented on SOLR-13523:
--
Since 8.1.2 was never released, should this (and probably others) be updated so
the fixVersion is 8.2 instead?
> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 8.1
> Environment: * Operating system: Win10 v1803 build 17143.766
> * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
> * solr-spec: 8.1.1
> * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:20:01
> * lucene-spec: 8.1.1
> * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.1.2
>
> Attachments: SOLR-13523.patch, SOLR-13523.patch, SOLR-13523.patch,
> SOLR-13523.patch, SOLR-13523_WIP_bug_hunt.patch, XUBrk.png, Xn1RW.png,
> reproduce.sh
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Partially update a document via an atomic update, when I do so, the web sever
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{
> "trace":"java.lang.NullPointerException\r\n\tat
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:223)\r\n\tat
>
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:475)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:75)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:92)\r\n\tat
>
> org.apache.solr.handler.loader.JsonLoader$SingleThre
[jira] [Closed] (SOLR-9162) Connection pool shut down
[
https://issues.apache.org/jira/browse/SOLR-9162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett closed SOLR-9162.
---
> Connection pool shut down
> -
>
> Key: SOLR-9162
> URL: https://issues.apache.org/jira/browse/SOLR-9162
> Project: Solr
> Issue Type: Bug
>Reporter: lingya
>Priority: Major
>
> We get an "Connection pool shut down"" error when upgrading to solr 6.0 ,
> via solr JDBC
> And here's the exception:
> 2016-05-26 10:41:30.903 b.s.m.n.Server [INFO] Getting metrics for server on
> port 6700
> 2016-05-26 10:42:13.962 o.a.s.c.S.Request [INFO]
> [systemTables_shard2_replica1] webapp=/solr path=/sql
> params={includeMetadata=true&wt=json&version=2.2&stmt=select+table_name,id+from+systemTables+order+by+id++limit+100&aggregationMode=facet}
> status=0 QTime=1
> 2016-05-26 10:42:13.983 o.a.s.c.s.i.s.ExceptionStream [ERROR]
> java.io.IOException: java.util.concurrent.ExecutionException:
> java.io.IOException: java.lang.IllegalStateException: Connection pool shut
> down
> at
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.openStreams(CloudSolrStream.java:361)
> at
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.open(CloudSolrStream.java:243)
> at
> org.apache.solr.handler.SQLHandler$LimitStream.open(SQLHandler.java:1265)
> at
> org.apache.solr.client.solrj.io.stream.SelectStream.open(SelectStream.java:153)
> at
> org.apache.solr.handler.SQLHandler$MetadataStream.open(SQLHandler.java:1511)
> at
> org.apache.solr.client.solrj.io.stream.ExceptionStream.open(ExceptionStream.java:47)
> at
> org.apache.solr.handler.StreamHandler$TimerStream.open(StreamHandler.java:362)
> at
> org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:301)
> at
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167)
> at
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183)
> at
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299)
> at
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95)
> at
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:60)
> at
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:725)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:469)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
> at
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:399)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>
[jira] [Resolved] (SOLR-9162) Connection pool shut down
[
https://issues.apache.org/jira/browse/SOLR-9162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett resolved SOLR-9162.
-
Resolution: Invalid
Closing as this should have gone to solr-user list first.
> Connection pool shut down
> -
>
> Key: SOLR-9162
> URL: https://issues.apache.org/jira/browse/SOLR-9162
> Project: Solr
> Issue Type: Bug
>Reporter: lingya
>Priority: Major
>
> We get an "Connection pool shut down"" error when upgrading to solr 6.0 ,
> via solr JDBC
> And here's the exception:
> 2016-05-26 10:41:30.903 b.s.m.n.Server [INFO] Getting metrics for server on
> port 6700
> 2016-05-26 10:42:13.962 o.a.s.c.S.Request [INFO]
> [systemTables_shard2_replica1] webapp=/solr path=/sql
> params={includeMetadata=true&wt=json&version=2.2&stmt=select+table_name,id+from+systemTables+order+by+id++limit+100&aggregationMode=facet}
> status=0 QTime=1
> 2016-05-26 10:42:13.983 o.a.s.c.s.i.s.ExceptionStream [ERROR]
> java.io.IOException: java.util.concurrent.ExecutionException:
> java.io.IOException: java.lang.IllegalStateException: Connection pool shut
> down
> at
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.openStreams(CloudSolrStream.java:361)
> at
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.open(CloudSolrStream.java:243)
> at
> org.apache.solr.handler.SQLHandler$LimitStream.open(SQLHandler.java:1265)
> at
> org.apache.solr.client.solrj.io.stream.SelectStream.open(SelectStream.java:153)
> at
> org.apache.solr.handler.SQLHandler$MetadataStream.open(SQLHandler.java:1511)
> at
> org.apache.solr.client.solrj.io.stream.ExceptionStream.open(ExceptionStream.java:47)
> at
> org.apache.solr.handler.StreamHandler$TimerStream.open(StreamHandler.java:362)
> at
> org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:301)
> at
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167)
> at
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183)
> at
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299)
> at
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95)
> at
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:60)
> at
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:725)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:469)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
> at
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:399)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
>
[jira] [Commented] (SOLR-5467) Provide Solr Ref Guide in .epub format
[ https://issues.apache.org/jira/browse/SOLR-5467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16890171#comment-16890171 ] Cassandra Targett commented on SOLR-5467: - Yes, there are asciidoctor tools to convert the .adoc files to ePub: https://github.com/asciidoctor/asciidoctor-epub3. Is there a "need"? Not sure. I've kept this open because I think it would be nice to do someday. > Provide Solr Ref Guide in .epub format > -- > > Key: SOLR-5467 > URL: https://issues.apache.org/jira/browse/SOLR-5467 > Project: Solr > Issue Type: Wish > Components: documentation >Reporter: Cassandra Targett >Priority: Major > > From the solr-user list, a request for an .epub version of the Solr Ref Guide. > There are two possible approaches that immediately come to mind: > * Ask infra to install a plugin that automatically outputs the Confluence > pages in .epub > * Investigate converting HTML export to .epub with something like calibre > There might be other options, and there would be additional issues for > automating the process of creation and publication, so for now just recording > the request with an issue. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8346) Upgrade Zookeeper to version 3.5.5
[ https://issues.apache.org/jira/browse/SOLR-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883831#comment-16883831 ] Cassandra Targett commented on SOLR-8346: - I've got a report of someone not able to get ZK status in the Admin UI when using an external 3.5.5 ensemble with Solr 8.1.1 (before the changes in this issue), but they've added the "4lw.commands.whitelist" param to their zoo.cfg. I'm probably tired but I'm not able to figure out exactly what needed to be changed in the code to support that for an external ensemble - is it expected that the admin UI in pre-8.2 versions would not properly recognize that param? > Upgrade Zookeeper to version 3.5.5 > -- > > Key: SOLR-8346 > URL: https://issues.apache.org/jira/browse/SOLR-8346 > Project: Solr > Issue Type: Task > Components: SolrCloud >Reporter: Jan Høydahl >Assignee: Erick Erickson >Priority: Major > Labels: security, zookeeper > Fix For: master (9.0), 8.2 > > Attachments: SOLR-8346.patch, SOLR-8346.patch, SOLR-8346.patch, > SOLR-8346.patch, SOLR-8346.patch, SOLR_8346.patch > > > Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation > for this is SSL support. --Currently a 3.5.4-beta is released (2018-05-17).-- > Version 3.5.5 was released 2019-05-20 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13569) AdminUI visual indication of prod/test/dev environment
[ https://issues.apache.org/jira/browse/SOLR-13569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16876177#comment-16876177 ] Cassandra Targett commented on SOLR-13569: -- No, that should be fine I think. I had only skimmed the commit for any .adoc files changed but missed the change you made, so sorry for the noise on that. > AdminUI visual indication of prod/test/dev environment > -- > > Key: SOLR-13569 > URL: https://issues.apache.org/jira/browse/SOLR-13569 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.2 > > Attachments: Environment-hint.png, prod-example.png, test-example.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > To guard against accidentally changing the wrong cluster, we should add a > visual indication in the Admin UI of whether you currently work with a > production environment or not, e.g. a red bar on top with an optional > environment label, see sketch. The bar could by default be red for > production, yellow for test and green for dev. > !Environment-hint.png|width=700! -- 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-13571) Make recent RefGuide rank well in Google
[
https://issues.apache.org/jira/browse/SOLR-13571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16874198#comment-16874198
]
Cassandra Targett commented on SOLR-13571:
--
I'm not totally against the idea of having a "latest", but I don't quite get
why it can't be a redirect? My gut reaction is that it further complicates the
release process, and since I'm pretty much the only one who ever does it (with
one recent exception), I'd like to be very sure that additional steps are
necessary. I'd be more likely to get on board if you were able to spell out the
specific changes to the release process that this would cause.
Maybe it would be simpler to ask Infra to just change that big list of
redirects to go to one single page that says "You have a link to the old
version of the Ref Guide, here's where the latest versions are." Or just have
it go to https://lucene.apache.org/solr/guide/. I mean, it's the internet -
stuff moves and life pretty much goes on.
Related to that idea, we need to institute a proper 404 page and redirect rule
for it.
There are also a large number of duplicated files in each release - CSS, fonts,
images. I have been recently thinking I'd like to restructure everything so we
stop uploading things that are very unlikely to change from release-to-release,
but that is way beyond the scope here, and I don't have any concrete ideas
there yet.
I think it's worth asking if the value we'd get here is worth the effort of
more steps to the process and more duplication of content. It's been 3 years
since we moved. I agree that having the 6.6 Guide rank highest is not good. But
perhaps we can fix that in a simpler way?
> Make recent RefGuide rank well in Google
>
>
> Key: SOLR-13571
> URL: https://issues.apache.org/jira/browse/SOLR-13571
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from SOLR-13548
> The old Confluence ref-guide has a lot of pages pointing to it, and all of
> that link karma is delegated to the {{/solr/guide/6_6/}} html ref guide,
> making it often rank top. However we'd want newer content to rank high. See
> these comments for some first ideas.
--
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-13569) AdminUI visual indication of prod/test/dev environment
[ https://issues.apache.org/jira/browse/SOLR-13569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873604#comment-16873604 ] Cassandra Targett commented on SOLR-13569: -- No update to the Ref Guide for this? How will someone know what to set to make the visual indicators work? > AdminUI visual indication of prod/test/dev environment > -- > > Key: SOLR-13569 > URL: https://issues.apache.org/jira/browse/SOLR-13569 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.2 > > Attachments: Environment-hint.png, prod-example.png, test-example.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > To guard against accidentally changing the wrong cluster, we should add a > visual indication in the Admin UI of whether you currently work with a > production environment or not, e.g. a red bar on top with an optional > environment label, see sketch. The bar could by default be red for > production, yellow for test and green for dev. > !Environment-hint.png|width=700! -- 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-13548) Migrate Solr's Moin wiki to Confluence
[
https://issues.apache.org/jira/browse/SOLR-13548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867918#comment-16867918
]
Cassandra Targett commented on SOLR-13548:
--
So...this is much more complicated than it sounded at first.
You cannot bulk delete pages in Confluence, so they have to be done one by one.
However, because of the {{.htaccess}} rules, you cannot get to each page to
delete it.
There seem to be a couple of utility plugins installed to assist in deleting
groups of pages (from https://cwiki.apache.org/confluence/display/solr, click
the "..." icon on the far right and they're near the bottom of the list), but
those seem to invoke the redirects in some way because trying to use one just
takes you to the new Ref Guide site.
Another option I found online is to use WebDAV to access the Confluence site.
But that doesn't allow you to delete either because no matter what I do it says
an "@exports" directory is in use. It's possible that Infra has locked us out
there.
It seems to me there are 2 options: ask Infra to remove the redirect rules so
we can delete them page-by-page, or go extreme and delete the space. I strongly
suspect, though, that if we delete the space we can't recreate it with the same
name. It's possible Infra has some magic they can do to the database itself.
> Migrate Solr's Moin wiki to Confluence
> --
>
> Key: SOLR-13548
> URL: https://issues.apache.org/jira/browse/SOLR-13548
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> We have a deadline end of June to migrate Moin wiki to Confluence.
> This Jira will track migration of Solr's [https://wiki.apache.org/solr/] over
> to [https://cwiki.apache.org/confluence/display/SOLR]
> The old Confluence space currently hosts the old Reference Guide for version
> 6.5 before we moved to asciidoc. This will be overwritten.
> Steps:
> # Delete all pages in current SOLR space
> ## Q: Can we do a bulk delete ourselves or do we need to ask INFRA?
> # The rules in {{.htaccess}} which redirects to the 6.6 guide will remain as
> is
> # Run the migration tool at
> [https://selfserve.apache.org|https://selfserve.apache.org/]
> # Add a clearly visible link from front page to the ref guide for people
> landing there for docs
> After migration we'll clean up and weed out what is not needed, and then
> start moving developer-centric content into the main git repo (which will be
> covered in other JIRAs)
--
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-13548) Migrate Solr's Moin wiki to Confluence
[
https://issues.apache.org/jira/browse/SOLR-13548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866929#comment-16866929
]
Cassandra Targett commented on SOLR-13548:
--
I will try to get to it before I leave on a short trip on Thursday. If I can't
do it tomorrow sometime I will let you know.
> Migrate Solr's Moin wiki to Confluence
> --
>
> Key: SOLR-13548
> URL: https://issues.apache.org/jira/browse/SOLR-13548
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> We have a deadline end of June to migrate Moin wiki to Confluence.
> This Jira will track migration of Solr's [https://wiki.apache.org/solr/] over
> to [https://cwiki.apache.org/confluence/display/SOLR]
> The old Confluence space currently hosts the old Reference Guide for version
> 6.5 before we moved to asciidoc. This will be overwritten.
> Steps:
> # Delete all pages in current SOLR space
> ## Q: Can we do a bulk delete ourselves or do we need to ask INFRA?
> # The rules in {{.htaccess}} which redirects to the 6.6 guide will remain as
> is
> # Run the migration tool at
> [https://selfserve.apache.org|https://selfserve.apache.org/]
> # Add a clearly visible link from front page to the ref guide for people
> landing there for docs
> After migration we'll clean up and weed out what is not needed, and then
> start moving developer-centric content into the main git repo (which will be
> covered in other JIRAs)
--
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] [Assigned] (SOLR-13391) Add variance and standard deviation stream evaluators
[ https://issues.apache.org/jira/browse/SOLR-13391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett reassigned SOLR-13391: Assignee: Joel Bernstein > Add variance and standard deviation stream evaluators > - > > Key: SOLR-13391 > URL: https://issues.apache.org/jira/browse/SOLR-13391 > Project: Solr > Issue Type: Improvement > Components: streaming expressions >Reporter: Nazerke Seidan >Assignee: Joel Bernstein >Priority: Minor > Labels: pull-request-available > Fix For: 8.1 > > Time Spent: 2.5h > Remaining Estimate: 0h > > It seems variance and standard deviation stream evaluators are not supported > by any of the solr version. For example, > let(echo="m,v,sd", arr=array(1,3,3), m=mean(a), v=var(a), > sd=stddev(a)) > So far, only the mean function is implemented. I think it is useful to have > var and sttdev functions separately as a stream evaluator. -- 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] [Resolved] (LUCENE-8842) Add a GitHub Pull Request Template
[ https://issues.apache.org/jira/browse/LUCENE-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved LUCENE-8842. --- Resolution: Fixed Assignee: Cassandra Targett Fix Version/s: master (9.0) > Add a GitHub Pull Request Template > -- > > Key: LUCENE-8842 > URL: https://issues.apache.org/jira/browse/LUCENE-8842 > Project: Lucene - Core > Issue Type: Task > Components: general/tools >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: master (9.0) > > Time Spent: 1h 10m > Remaining Estimate: 0h > > GitHub supports having a template for issues and pull requests which can help > guide users toward providing important information in their pull requests > that will help get their contributions resolved faster. > From [this dev list > thread|https://lists.apache.org/thread.html/f9d6b40a83325d0ac93bc48e98c8c2924e1518d64b92a7ff193ca708@%3Cdev.lucene.apache.org%3E], > we'd like to explore creating a template for the lucene-solr project. > More information about GH PR templates can be found at: > https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository -- 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] (LUCENE-8842) Add a GitHub Pull Request Template
[ https://issues.apache.org/jira/browse/LUCENE-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16863443#comment-16863443 ] Cassandra Targett commented on LUCENE-8842: --- I just merged this in. I don't think I need to backport it to any branches since it's just for Github, which will use master no matter what? I also didn't add anything to CHANGES, but could if folks think it should be mentioned there. > Add a GitHub Pull Request Template > -- > > Key: LUCENE-8842 > URL: https://issues.apache.org/jira/browse/LUCENE-8842 > Project: Lucene - Core > Issue Type: Task > Components: general/tools >Reporter: Cassandra Targett >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > GitHub supports having a template for issues and pull requests which can help > guide users toward providing important information in their pull requests > that will help get their contributions resolved faster. > From [this dev list > thread|https://lists.apache.org/thread.html/f9d6b40a83325d0ac93bc48e98c8c2924e1518d64b92a7ff193ca708@%3Cdev.lucene.apache.org%3E], > we'd like to explore creating a template for the lucene-solr project. > More information about GH PR templates can be found at: > https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository -- 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-13047) Add facet2D Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862592#comment-16862592
]
Cassandra Targett edited comment on SOLR-13047 at 6/13/19 12:34 AM:
There were 2 pull requests created for this change - #659, which is closed, and
#660 which is still open. I presume since this is resolved that #660 can be
closed?
There is also another PR #669 which is still open and has the title "Facet2D" -
is that also related to this change?
was (Author: ctargett):
There were 2 pull requests created for this change - #659, which is closed, and
#660 which is still open. I presume since this is resolved that #660 can be
closed?
> Add facet2D Streaming Expression
>
>
> Key: SOLR-13047
> URL: https://issues.apache.org/jira/browse/SOLR-13047
> Project: Solr
> Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The current facet expression is a generic tool for creating multi-dimension
> aggregations. The *facet2D* Streaming Expression has semantics specific for 2
> dimensional facets which are designed to be *pivoted* into a matrix and
> operated on by *Math Expressions*.
> facet2D will use the json facet API under the covers.
> Proposed syntax:
> {code:java}
> facet2D(medrecords, q=*:*, x=diseases, y=symptoms, dimensions="300, 10",
> count(*)){code}
> The example above will return tuples containing the top 300 diseases and the
> top ten symptoms for each disease.
> Using math expression the tuples can be *pivoted* into a matrix where the
> rows of the matrix are the diseases, the columns of the matrix are the
> symptoms and the cells in the matrix contain the counts. This matrix can then
> be *clustered* to find clusters of *diseases* that are correlated by
> *symptoms*.
> {code:java}
> let(a=facet2D(medrecords, q=*:*, x=diseases, y=symptoms, dimensions="300,
> 10", count(*)),
> b=pivot(a, diseases, symptoms, count(*)),
> c=kmeans(b, 10)){code}
>
> *Implementation Note:*
> The implementation plan for this ticket is to create a new stream called
> Facet2DStream. The FacetStream code is a good starting point for the new
> implementation and can be adapted for the Facet2D parameters. Similar tests
> to the FacetStream can be added to StreamExpressionTest
>
--
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-13047) Add facet2D Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862592#comment-16862592
]
Cassandra Targett commented on SOLR-13047:
--
There were 2 pull requests created for this change - #659, which is closed, and
#660 which is still open. I presume since this is resolved that #660 can be
closed?
> Add facet2D Streaming Expression
>
>
> Key: SOLR-13047
> URL: https://issues.apache.org/jira/browse/SOLR-13047
> Project: Solr
> Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The current facet expression is a generic tool for creating multi-dimension
> aggregations. The *facet2D* Streaming Expression has semantics specific for 2
> dimensional facets which are designed to be *pivoted* into a matrix and
> operated on by *Math Expressions*.
> facet2D will use the json facet API under the covers.
> Proposed syntax:
> {code:java}
> facet2D(medrecords, q=*:*, x=diseases, y=symptoms, dimensions="300, 10",
> count(*)){code}
> The example above will return tuples containing the top 300 diseases and the
> top ten symptoms for each disease.
> Using math expression the tuples can be *pivoted* into a matrix where the
> rows of the matrix are the diseases, the columns of the matrix are the
> symptoms and the cells in the matrix contain the counts. This matrix can then
> be *clustered* to find clusters of *diseases* that are correlated by
> *symptoms*.
> {code:java}
> let(a=facet2D(medrecords, q=*:*, x=diseases, y=symptoms, dimensions="300,
> 10", count(*)),
> b=pivot(a, diseases, symptoms, count(*)),
> c=kmeans(b, 10)){code}
>
> *Implementation Note:*
> The implementation plan for this ticket is to create a new stream called
> Facet2DStream. The FacetStream code is a good starting point for the new
> implementation and can be adapted for the Facet2D parameters. Similar tests
> to the FacetStream can be added to StreamExpressionTest
>
--
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] [Resolved] (SOLR-13235) Split Ref Guide Collections API page into several sub-pages
[ https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-13235. -- Resolution: Fixed > Split Ref Guide Collections API page into several sub-pages > --- > > Key: SOLR-13235 > URL: https://issues.apache.org/jira/browse/SOLR-13235 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The Collections API page in the Ref Guide has become the de-facto place where > information about how to work with Solr collections is stored, but it is so > huge with API examples that information gets lost. > I did some work a couple months ago to split this up, and came up with this > approach to splitting up the content: > * *Cluster and Node Management*: Define properties for the entire cluster; > check the status of a cluster; remove replicas from a node; utilize a newly > added node; add or remove roles for a node. > * *Collection Management*: Create, list, reload and delete collections; set > collection properties; migrate documents to another collection; rebalance > leaders; backup and restore collections. > * *Collection Aliasing*: Create, list or delete collection aliases; set alias > properties. > * *Shard Management*: Create and delete a shard; split a shard into two or > more additional shards; force a shard leader. > * *Replica Management*: Add or delete a replica; set replica properties; move > a replica to a different node. > My existing local WIP leaves info on Async commands on the main > collections-api.adoc page, but creates new pages for each of the bullets > mentioned above, and moves the related API calls to those pages. Each topic > will be smaller and easier for us to manage on an ongoing basis. > Since I did the work a while ago, I need to bring it up to date with master, > so a patch & a branch with this work will be forthcoming shortly. -- 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-13235) Split Ref Guide Collections API page into several sub-pages
[
https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862206#comment-16862206
]
Cassandra Targett commented on SOLR-13235:
--
I closed the PR as I didn't get it done in the timeline I hoped and now there
are all sort of merge conflicts it would take forever to straighten out. I'll
make the same changes as that PR but not via the branch/PR.
It occurred to me yesterday splitting up the collections-api page also requires
updating the doc links in all the API specs in
{{solr/solrj/src/java/resources/apispec}}, so I will include that also.
> Split Ref Guide Collections API page into several sub-pages
> ---
>
> Key: SOLR-13235
> URL: https://issues.apache.org/jira/browse/SOLR-13235
> Project: Solr
> Issue Type: Improvement
> Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The Collections API page in the Ref Guide has become the de-facto place where
> information about how to work with Solr collections is stored, but it is so
> huge with API examples that information gets lost.
> I did some work a couple months ago to split this up, and came up with this
> approach to splitting up the content:
> * *Cluster and Node Management*: Define properties for the entire cluster;
> check the status of a cluster; remove replicas from a node; utilize a newly
> added node; add or remove roles for a node.
> * *Collection Management*: Create, list, reload and delete collections; set
> collection properties; migrate documents to another collection; rebalance
> leaders; backup and restore collections.
> * *Collection Aliasing*: Create, list or delete collection aliases; set alias
> properties.
> * *Shard Management*: Create and delete a shard; split a shard into two or
> more additional shards; force a shard leader.
> * *Replica Management*: Add or delete a replica; set replica properties; move
> a replica to a different node.
> My existing local WIP leaves info on Async commands on the main
> collections-api.adoc page, but creates new pages for each of the bullets
> mentioned above, and moves the related API calls to those pages. Each topic
> will be smaller and easier for us to manage on an ongoing basis.
> Since I did the work a while ago, I need to bring it up to date with master,
> so a patch & a branch with this work will be forthcoming shortly.
--
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-13235) Split Ref Guide Collections API page into several sub-pages
[ https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-13235: - Fix Version/s: (was: 8.1) 8.2 > Split Ref Guide Collections API page into several sub-pages > --- > > Key: SOLR-13235 > URL: https://issues.apache.org/jira/browse/SOLR-13235 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 50m > Remaining Estimate: 0h > > The Collections API page in the Ref Guide has become the de-facto place where > information about how to work with Solr collections is stored, but it is so > huge with API examples that information gets lost. > I did some work a couple months ago to split this up, and came up with this > approach to splitting up the content: > * *Cluster and Node Management*: Define properties for the entire cluster; > check the status of a cluster; remove replicas from a node; utilize a newly > added node; add or remove roles for a node. > * *Collection Management*: Create, list, reload and delete collections; set > collection properties; migrate documents to another collection; rebalance > leaders; backup and restore collections. > * *Collection Aliasing*: Create, list or delete collection aliases; set alias > properties. > * *Shard Management*: Create and delete a shard; split a shard into two or > more additional shards; force a shard leader. > * *Replica Management*: Add or delete a replica; set replica properties; move > a replica to a different node. > My existing local WIP leaves info on Async commands on the main > collections-api.adoc page, but creates new pages for each of the bullets > mentioned above, and moves the related API calls to those pages. Each topic > will be smaller and easier for us to manage on an ongoing basis. > Since I did the work a while ago, I need to bring it up to date with master, > so a patch & a branch with this work will be forthcoming shortly. -- 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] (LUCENE-8766) Add Luwak as a lucene module
[ https://issues.apache.org/jira/browse/LUCENE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859989#comment-16859989 ] Cassandra Targett commented on LUCENE-8766: --- Sorry for the delay here - if you get an acknowledgement of receipt then I believe you are OK to move forward with committing. I believe the CCLA is just like the ICLA in that it mostly just needs to be received, and since there aren't user permissions to update in the case of a software grant like this, there isn't anything that has to be done after the ASF has the agreement in hand. > Add Luwak as a lucene module > > > Key: LUCENE-8766 > URL: https://issues.apache.org/jira/browse/LUCENE-8766 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Luwak [https://github.com/flaxsearch/luwak] is a stored query engine, > allowing users to efficiently match a stream of documents against a large set > of queries. It's only dependency is lucene, and most recent updates have > just been upgrading the version of lucene against which it can run. > It's a generally useful piece of software, and already licensed as Apache 2. > The maintainers would like to donate it to the ASF, and merge it in to the > lucene-solr project. -- 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-13131) Category Routed Aliases
[ https://issues.apache.org/jira/browse/SOLR-13131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859100#comment-16859100 ] Cassandra Targett commented on SOLR-13131: -- [~gus_heck] - CHANGES.txt includes this issue under 9.0, but this issue says it's fixed in 8.1 (and the docs are in 8.1). Was the CHANGES entry perhaps put in the wrong place? See https://github.com/apache/lucene-solr/blob/master/solr/CHANGES.txt#L56 > Category Routed Aliases > --- > > Key: SOLR-13131 > URL: https://issues.apache.org/jira/browse/SOLR-13131 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (9.0) >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: indexingWithCRA.png, indexingwithoutCRA.png, > indexintWithoutCRA2.png > > > This ticket is to add a second type of routed alias in addition to the > current time routed aliases. The new type of alias will allow data driven > creation of collections based on the values of a field and automated > organization of these collections under an alias that allows the collections > to also be searched as a whole. > The use case in mind at present is an IOT device type segregation, but I > could also see this leading to the ability to direct updates to tenant > specific hardware (in cooperation with autoscaling). > This ticket also looks forward to (but does not include) the creation of a > Dimensionally Routed Alias which would allow organizing time routed data also > segregated by device > Further design details to be added in comments. > -- 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] (LUCENE-8842) Add a GitHub Pull Request Template
[
https://issues.apache.org/jira/browse/LUCENE-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16858914#comment-16858914
]
Cassandra Targett edited comment on LUCENE-8842 at 6/7/19 7:05 PM:
---
I've added what I had come up with a few months ago to the branch
{{jira/lucene-8842}} and created a PR for it.
There are three possible locations for the template:
# at the root level of the project ({{lucene-solr/.}}). That's what I've done
here.
# in a hidden directory {{lucene-solr/.github}}. This does not exist now, but
if we want to keep the top level cleaner, we could create this directory. If we
decide to add other GH-centric helpers, this might not be a bad idea.
# in a directory from the root level {{lucene-solr/docs}}. We don't have this
and don't have need of it, so this is probably not an option.
I mentioned in the PR that I am not sure if the currently commented-out top
section about how to create Jira issues is visible to users; this may need to
be changed to some variation of what I have there to be actually visible. PR
creators would need to remove it when creating PRs, and some would neglect to.
But maybe that's fine.
was (Author: ctargett):
I've added what I had come up with a few months ago to the branch
{{jira/lucene-8842}} and created a PR for it.
There are three possible locations for the template:
# at the root level of the project ({{lucene-solr/.}}. That's what I've done
here.
# in a hidden directory {{lucene-solr/.github}}. This does not exist now, but
if we want to keep the top level cleaner, we could create this directory. If we
decide to add other GH-centric helpers, this might not be a bad idea.
# in a directory from the root level {{lucene-solr/docs}}. We don't have this
and don't have need of it, so this is probably not an option.
I mentioned in the PR that I am not sure if the currently commented-out top
section about how to create Jira issues is visible to users; this may need to
be changed to some variation of what I have there to be actually visible. PR
creators would need to remove it when creating PRs, and some would neglect to.
But maybe that's fine.
> Add a GitHub Pull Request Template
> --
>
> Key: LUCENE-8842
> URL: https://issues.apache.org/jira/browse/LUCENE-8842
> Project: Lucene - Core
> Issue Type: Task
> Components: general/tools
>Reporter: Cassandra Targett
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> GitHub supports having a template for issues and pull requests which can help
> guide users toward providing important information in their pull requests
> that will help get their contributions resolved faster.
> From [this dev list
> thread|https://lists.apache.org/thread.html/f9d6b40a83325d0ac93bc48e98c8c2924e1518d64b92a7ff193ca708@%3Cdev.lucene.apache.org%3E],
> we'd like to explore creating a template for the lucene-solr project.
> More information about GH PR templates can be found at:
> https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository
--
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] (LUCENE-8842) Add a GitHub Pull Request Template
[
https://issues.apache.org/jira/browse/LUCENE-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16858914#comment-16858914
]
Cassandra Targett commented on LUCENE-8842:
---
I've added what I had come up with a few months ago to the branch
{{jira/lucene-8842}} and created a PR for it.
There are three possible locations for the template:
# at the root level of the project ({{lucene-solr/.}}. That's what I've done
here.
# in a hidden directory {{lucene-solr/.github}}. This does not exist now, but
if we want to keep the top level cleaner, we could create this directory. If we
decide to add other GH-centric helpers, this might not be a bad idea.
# in a directory from the root level {{lucene-solr/docs}}. We don't have this
and don't have need of it, so this is probably not an option.
I mentioned in the PR that I am not sure if the currently commented-out top
section about how to create Jira issues is visible to users; this may need to
be changed to some variation of what I have there to be actually visible. PR
creators would need to remove it when creating PRs, and some would neglect to.
But maybe that's fine.
> Add a GitHub Pull Request Template
> --
>
> Key: LUCENE-8842
> URL: https://issues.apache.org/jira/browse/LUCENE-8842
> Project: Lucene - Core
> Issue Type: Task
> Components: general/tools
>Reporter: Cassandra Targett
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> GitHub supports having a template for issues and pull requests which can help
> guide users toward providing important information in their pull requests
> that will help get their contributions resolved faster.
> From [this dev list
> thread|https://lists.apache.org/thread.html/f9d6b40a83325d0ac93bc48e98c8c2924e1518d64b92a7ff193ca708@%3Cdev.lucene.apache.org%3E],
> we'd like to explore creating a template for the lucene-solr project.
> More information about GH PR templates can be found at:
> https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository
--
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] [Created] (LUCENE-8842) Add a GitHub Pull Request Template
Cassandra Targett created LUCENE-8842: - Summary: Add a GitHub Pull Request Template Key: LUCENE-8842 URL: https://issues.apache.org/jira/browse/LUCENE-8842 Project: Lucene - Core Issue Type: Task Components: general/tools Reporter: Cassandra Targett GitHub supports having a template for issues and pull requests which can help guide users toward providing important information in their pull requests that will help get their contributions resolved faster. >From [this dev list >thread|https://lists.apache.org/thread.html/f9d6b40a83325d0ac93bc48e98c8c2924e1518d64b92a7ff193ca708@%3Cdev.lucene.apache.org%3E], > we'd like to explore creating a template for the lucene-solr project. More information about GH PR templates can be found at: https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository -- 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-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855943#comment-16855943
]
Cassandra Targett commented on SOLR-13510:
--
[~caomanhdat], could you backport to branch_8_1 also? I think we should
consider an 8.1.2 for this problem.
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-13510.patch
>
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
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-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854670#comment-16854670
]
Cassandra Targett commented on SOLR-13510:
--
The same person commented about this behavior to SOLR-13421. The issues are
possibly duplicates?
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
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] (LUCENE-8820) Download page must not redirect to mirror page
[ https://issues.apache.org/jira/browse/LUCENE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854581#comment-16854581 ] Cassandra Targett commented on LUCENE-8820: --- bq. For Solr I'm also considering a (non-versioned) link to ref-guide on the download page, what do others think? The link would go to lucene.apache.org/solr/guide, you mean? That would be a good addition IMO. > Download page must not redirect to mirror page > -- > > Key: LUCENE-8820 > URL: https://issues.apache.org/jira/browse/LUCENE-8820 > Project: Lucene - Core > Issue Type: Bug > Components: general/website >Reporter: Sebb >Assignee: Jan Høydahl >Priority: Major > > The direct download page [1] currently redirects to the mirror system [2] > after a few seconds. > I think that is wrong; users should be encouraged to verify the downloads, > but the redirect makes verification harder. > The normal download page [3] is OK. > [1] [http://lucene.apache.org/solr/mirrors-solr-latest-redir.html] > [2] http://www.apache.org/dyn/closer.lua/lucene/solr/8.1.1 > [3] http://lucene.apache.org/solr/downloads.html -- 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-13502) Investigate using something other than ZooKeeper's "4 letter words" for the admin UI status
[
https://issues.apache.org/jira/browse/SOLR-13502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852064#comment-16852064
]
Cassandra Targett commented on SOLR-13502:
--
bq. users will have to modify their zoo.cfg
My initial reaction is, so what? We already have a number of changes users need
to make in their zoo.cfg to run with Solr and to me this is just another item
on the list to properly run ZK securely in our environment. Unless I'm missing
something, I don't see it as something that needs a lot of discussion (with
it's risks of bikeshedding), it is simply a fact. It's nice to have a heads up
via an issue (like you've done here), of course, but it just doesn't seem to me
like a situation we should jump through a lot of hoops to avoid.
> Investigate using something other than ZooKeeper's "4 letter words" for the
> admin UI status
> ---
>
> Key: SOLR-13502
> URL: https://issues.apache.org/jira/browse/SOLR-13502
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> ZooKeeper 3.5.5 requires a whitelist of allowed "4 letter words". The only
> place I see on a quick look at the Solr code where 4lws are used is in the
> admin UI "ZK Status" link.
> In order to use the admin UI "ZK Status" link, users will have to modify
> their zoo.cfg file with
> {code}
> 4lw.commands.whitelist=mntr,conf,ruok
> {code}
> This JIRA is to see if there are alternatives to using 4lw for the admin UI.
> This depends on SOLR-8346. If we find an alternative, we need to remove the
> additions to the ref guide that mention changing zoo.cfg (just scan for 4lw
> in all the .adoc files) and remove SolrZkServer.ZK_WHITELIST_PROPERTY and all
> references to it (SolrZkServer and SolrTestCaseJ4).
--
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-13349) High CPU usage in Solr due to Java 8 bug
[
https://issues.apache.org/jira/browse/SOLR-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16846744#comment-16846744
]
Cassandra Targett commented on SOLR-13349:
--
Yes, 7.7.2 is coming very soon - within the next couple of weeks.
> High CPU usage in Solr due to Java 8 bug
>
>
> Key: SOLR-13349
> URL: https://issues.apache.org/jira/browse/SOLR-13349
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13349.patch
>
>
> We've had sporadic reports of high CPU usage in Solr 7. Lukas Weiss reported
> a Java 8 bug that appears to be the root cause (I have not personally
> verified), see: [https://bugs.openjdk.java.net/browse/JDK-8129861] e-mail
> reproduced below:
> CommitTracker makes this call:
> Executors.newScheduledThreadPool(0, new
> DefaultSolrThreadFactory("commitScheduler"));
> The supposition is that calling this with 1 will fix this (untested)
> [~ichattopadhyaya] This affects 6.6 and IIUC you're spinning a new version.
> We'll need to verify and include this fix.
> [~jpountz] You're right. I first thought "naaah, it wouldn't be that far
> back" but your question made me check, thanks!
> AFAICT, this is the only place in Solr/Lucene that uses zero.
> Using Java 9+ is another work-around.
> Anyone picking this up should port to 7.7 as well.
> e-mail from the user's list (many thanks to Lukas and Adam).
> Apologies, I can’t figure out how to reply to the Solr mailing list.
> I just ran across the same high CPU usage issue. I believe it’’s caused by
> this commit which was introduced in Solr 7.7.0
>
> [https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5]
> There is a bug in JDK versions <=8 where using 0 threads in the
> ScheduledThreadPool causes high CPU usage:
> [https://bugs.openjdk.java.net/browse/JDK-8129861]
> Oddly, the latest version
> of solr/core/src/java/org/apache/solr/update/CommitTracker.java on
> master still uses 0 executors as the default. Presumably most everyone is
> using JDK 9 or greater which has the bug fixed, so they don’t experience
> the bug.
> Feel free to relay this back to the mailing list.
> Thanks,
> Adam Guthrie
>
>
--
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-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16846238#comment-16846238 ] Cassandra Targett commented on SOLR-13452: -- One thing we shouldn't forget about is the Ref Guide which has its own build.xml in solr/solr-ref-guide. I'm hazy enough on how it works without looking at it to know off the top of my head if it can be deferred or if it has dependencies on the main build, but I'll see if I can find some time to take a crack at it. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- 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-13016) Computing suggestions when policy have "#EQUAL" or "#ALL" rules take too long
[ https://issues.apache.org/jira/browse/SOLR-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845154#comment-16845154 ] Cassandra Targett commented on SOLR-13016: -- [~noble.paul] - here's another issue that appears in 7.7 CHANGES.txt but is not resolved and has no fix version. Is it complete? If not, what else is left to be done in case someone else wants to pick it up? > Computing suggestions when policy have "#EQUAL" or "#ALL" rules take too long > - > > Key: SOLR-13016 > URL: https://issues.apache.org/jira/browse/SOLR-13016 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Attachments: SOLR-13016.patch, SOLR-13016.patch, SOLR-13016.patch, > SOLR-13016.patch, SOLR-13016.patch > > > When rules have computed values such as "#EQUAL" or "#ALL" , it takes too > long to compute. The problem is these values are computed too many times and > as the no:of nodes increase it almost takes forever. These values don't > change and they can be cached -- 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-12885) BinaryResponseWriter (javabin format) should directly copy from Bytesref to output
[
https://issues.apache.org/jira/browse/SOLR-12885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845150#comment-16845150
]
Cassandra Targett commented on SOLR-12885:
--
[~noble.paul] - here's another issue that appears in CHANGES.txt (for 7.7) but
wasn't resolved, and now is marked like it's going to be in 8.2.
*PLEASE* fix your workflow so you start resolving these in a more timely manner
and accurate fix versions.
> BinaryResponseWriter (javabin format) should directly copy from Bytesref to
> output
> --
>
> Key: SOLR-12885
> URL: https://issues.apache.org/jira/browse/SOLR-12885
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-12885.patch, SOLR-12885.patch, SOLR-12885.patch,
> SOLR-12885.patch, SOLR-12885.patch
>
>
> The format format in which bytes are stored in {{BytesRef}} and the javabin
> string format are both the same. We don't need to convert the string/text
> fields from {{BytesRef}} to String and back to UTF8
> {{Now a String/Text field is read and written out as follows}}
> {{luceneindex(UTF8 bytes) --> UTF16 (char[]) --> new String() a copy of UTF16
> char[] --> UTF8bytes(javabin format)}}
> This does not add a new type to javabin. It's encoded as String in the
> serialized data. When it is deserialized, you get a String back
--
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-12868) Request forwarding for v2 API is broken
[
https://issues.apache.org/jira/browse/SOLR-12868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845149#comment-16845149
]
Cassandra Targett commented on SOLR-12868:
--
[~noble.paul] - please see my earlier comment about this appearing in 7.6
CHANGES. Is it resolved? Since the RM process automatically bumps versions,
this now appears as though it's slated to be in 8.2, although from what I can
tell - but can't be sure - it seems this was fixed in 7.6.
> Request forwarding for v2 API is broken
> ---
>
> Key: SOLR-12868
> URL: https://issues.apache.org/jira/browse/SOLR-12868
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud, v2 API
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (9.0), 8.2
>
>
> I was working with Noble Paul to investigate test failures seen in SOLR-12806
> where we found this issue. Due to a bug, replicas of a collection weren't
> spread evenly so there were some nodes which did not have any replicas at
> all. In such cases, when a v2 API call hits an empty node, it is not
> forwarded to the right path on the remote node causing test failures.
> e.g. a call to {{/c/collection/_introspect}} is forwarded as
> {{http://127.0.0.1:63326/solr/collection1/_introspect?method=POST&wt=javabin&version=2&command=}}
> and {{/c/collection1/abccdef}} is forwarded as
> {{http://127.0.0.1:63326/solr/collection1/abccdef}}
> In summary, a remote query for v2 API from an empty node is converted to a v1
> style call which may not be a valid path. We should forward v2 API calls
> as-is without changing the paths.
--
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-13468) autoscaling/suggestions should be able to give suggestions from payload
[
https://issues.apache.org/jira/browse/SOLR-13468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841196#comment-16841196
]
Cassandra Targett commented on SOLR-13468:
--
Actually, the v1 & v2 examples added here don't make any sense. There is no
"old way" of doing the Autoscaling API requests (i.e., as HTTP request
parameters). We should only add that when there is a difference in syntax, not
when the examples are exactly the same. I'm going to distill that into a single
example, and fix several typos in the text also.
The other errors are from a badly formatted {{[source]}} block, they'll go away
with the change I'm making above.
> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling
> configuration sent as a payload . This is helpful in debugging the system or
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json' -d '{
> "cluster-policy": [
> {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
> ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {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-13468) autoscaling/suggestions should be able to give suggestions from payload
[
https://issues.apache.org/jira/browse/SOLR-13468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841190#comment-16841190
]
Cassandra Targett commented on SOLR-13468:
--
[~noble.paul], the Ref Guide commits here broke the Ref Guide builds. It looks
like you introduced duplicate anchor IDs in the HTML output, and also used
references that don't exist:
{noformat}
[java] ID occurs multiple times: v1getcomponent
[java] ...
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/config-api.html
[java] ...
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-api.html
[java] ID occurs multiple times: v2getcomponent
[java] ...
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/config-api.html
[java] ...
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-api.html
[java] Relative link points at id that doesn't exist in dest:
solrcloud-autoscaling-api.html#write-api
[java] ... source:
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-triggers.html
[java] Relative link points at id that doesn't exist in dest:
solrcloud-autoscaling-api.html#create-update-trigger
[java] ... source:
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-triggers.html
[java] Relative link points at id that doesn't exist in dest:
solrcloud-autoscaling-api.html#remove-trigger
[java] ... source:
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-triggers.html
[java] Relative link points at id that doesn't exist in dest:
solrcloud-autoscaling-api.html#create-and-modify-cluster-preferences
[java] ... source:
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-policy-preferences.html
[java] Relative link points at id that doesn't exist in dest:
solrcloud-autoscaling-api.html#create-and-modify-collection-specific-policy
[java] ... source:
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-policy-preferences.html
[java] Relative link points at id that doesn't exist in dest:
solrcloud-autoscaling-api.html#change-autoscaling-properties
[java] ... source:
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solr-upgrade-notes.html
[java] Processed 2511 links (1822 relative) to 3348 anchors in 253 files
[java] Total of 8 problems found
{noformat}
(from https://builds.apache.org/job/Solr-reference-guide-master/15910/)
> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling
> configuration sent as a payload . This is helpful in debugging the system or
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json' -d '{
> "cluster-policy": [
> {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
> ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {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-13112) Upgrade jackson to 2.9.8
[ https://issues.apache.org/jira/browse/SOLR-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837401#comment-16837401 ] Cassandra Targett commented on SOLR-13112: -- [~krisden], I wasn't sure if I'd have time today, so offline I asked if Hoss would do it for me but he hasn't started it yet. Since you did the original commit and you have the time, I'm fine if you don't mind doing it. > Upgrade jackson to 2.9.8 > > > Key: SOLR-13112 > URL: https://issues.apache.org/jira/browse/SOLR-13112 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 > Environment: RedHat Linux. May run from RHEL versions 5, 6 or 7 > but this issue is from Sonatype component scan and should be independent of > Linux platform version. >Reporter: RobertHathaway >Assignee: Kevin Risden >Priority: Major > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: SOLR-13112.patch > > Time Spent: 20m > Remaining Estimate: 0h > > We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of > Solr - 7.6.0 Build, > Using Scanner 1.56.0-01 > Threat Level 8 Against Solr v7.6. com.fasterxml.jackson.core : > jackson-databind : 2.9.6 > FasterXML jackson-databind 2.x before 2.9.7 might allow remote attackers to > execute arbitrary code by leveraging failure to block the slf4j-ext class > from polymorphic deserialization. > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14718 -- 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-13112) Upgrade jackson to 2.9.8
[ https://issues.apache.org/jira/browse/SOLR-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-13112: - Fix Version/s: 7.7.2 > Upgrade jackson to 2.9.8 > > > Key: SOLR-13112 > URL: https://issues.apache.org/jira/browse/SOLR-13112 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 > Environment: RedHat Linux. May run from RHEL versions 5, 6 or 7 > but this issue is from Sonatype component scan and should be independent of > Linux platform version. >Reporter: RobertHathaway >Assignee: Kevin Risden >Priority: Major > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: SOLR-13112.patch > > Time Spent: 20m > Remaining Estimate: 0h > > We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of > Solr - 7.6.0 Build, > Using Scanner 1.56.0-01 > Threat Level 8 Against Solr v7.6. com.fasterxml.jackson.core : > jackson-databind : 2.9.6 > FasterXML jackson-databind 2.x before 2.9.7 might allow remote attackers to > execute arbitrary code by leveraging failure to block the slf4j-ext class > from polymorphic deserialization. > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14718 -- 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] [Reopened] (SOLR-13112) Upgrade jackson to 2.9.8
[ https://issues.apache.org/jira/browse/SOLR-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett reopened SOLR-13112: -- Reopening to backport to branch_7_7. > Upgrade jackson to 2.9.8 > > > Key: SOLR-13112 > URL: https://issues.apache.org/jira/browse/SOLR-13112 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 > Environment: RedHat Linux. May run from RHEL versions 5, 6 or 7 > but this issue is from Sonatype component scan and should be independent of > Linux platform version. >Reporter: RobertHathaway >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13112.patch > > Time Spent: 20m > Remaining Estimate: 0h > > We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of > Solr - 7.6.0 Build, > Using Scanner 1.56.0-01 > Threat Level 8 Against Solr v7.6. com.fasterxml.jackson.core : > jackson-databind : 2.9.6 > FasterXML jackson-databind 2.x before 2.9.7 might allow remote attackers to > execute arbitrary code by leveraging failure to block the slf4j-ext class > from polymorphic deserialization. > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14718 -- 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-13424) Ref Guide PDF build throws Java warnings after requiring Java 11 on master
[
https://issues.apache.org/jira/browse/SOLR-13424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-13424:
-
Summary: Ref Guide PDF build throws Java warnings after requiring Java 11
on master (was: Ref Guide PDF build throws Java errors after requiring Java 11
on master)
> Ref Guide PDF build throws Java warnings after requiring Java 11 on master
> --
>
> Key: SOLR-13424
> URL: https://issues.apache.org/jira/browse/SOLR-13424
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>Priority: Major
>
> Since the {{master}} branch requires Java 11, the Ref Guide build has started
> throwing WARNINGs that we should look into. Despite the WARNINGs, the PDF
> build finishes successfully and appears the same as usual.
> There are a couple moving parts here - first some classes [~hossman] wrote to
> validate links in the PDF, and second a .jar from the {{asciidoctor-ant}}
> project. I suspect some of these are related to Hoss' code and some are from
> the project that's doing the PDF conversion.
> I'll put the output from a Jenkins job in the comment to show the errors.
--
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-13424) Ref Guide PDF build throws Java errors after requiring Java 11 on master
[
https://issues.apache.org/jira/browse/SOLR-13424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824216#comment-16824216
]
Cassandra Targett commented on SOLR-13424:
--
This is from
https://builds.apache.org/view/L/view/Lucene/job/Solr-reference-guide-master/15365/
(23 April 2019).
The PDF target has several dependent targets, so runs in stages.
The {{build-nav-data-files}} dependent target produces the following. This is
from Hoss' classes, and builds the hierarchical page navigation:
{code}
build-nav-data-files:
[java] Building up tree of all known pages
[java] unsupported Java version "11", defaulting to 1.7
[java] WARNING: An illegal reflective access operation has occurred
[java] WARNING: Illegal reflective access by org.jruby.util.io.FilenoUtil
(file:/home/jenkins/.ivy2/cache/org.asciidoctor/asciidoctor-ant/jars/asciidoctor-ant-1.6.0-alpha.5.jar)
to method sun.nio.ch.SelChImpl.getFD()
[java] WARNING: Please consider reporting this to the maintainers of
org.jruby.util.io.FilenoUtil
[java] WARNING: Use --illegal-access=warn to enable warnings of further
illegal reflective access operations
[java] WARNING: All illegal access operations will be denied in a future
release
[java] Creating
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content/_data/pdf-main-body.adoc
[java] Creating
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content/_data/scrollnav.json
[java] Creating
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content/_data/sidebar.json
{code}
The {{bare-bones-html-validation}} creates a stripped-down HTML for checking
that inter-document links work properly, and is also from Hoss' classes, but
uses asciidoctor-ant to do the conversion to HTML (some unrelated messages at
the end have been stripped):
{code}
bare-bones-html-validation:
[mkdir] Created dir:
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/bare-bones-html
[asciidoctor:convert] unsupported Java version "11", defaulting to 1.7
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jruby.util.io.FilenoUtil
(file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/solr-ref-guide/lib/asciidoctor-ant-1.6.0-alpha.5.jar)
to method sun.nio.ch.SelChImpl.getFD()
WARNING: Please consider reporting this to the maintainers of
org.jruby.util.io.FilenoUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
[asciidoctor:convert] Render asciidoc files from
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
to
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/bare-bones-html
with backend=html5
...
[java] Processed 2526 links (1839 relative) to 3355 anchors in 253 files
[echo] Validated Links & Anchors via:
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/bare-bones-html/
{code}
> Ref Guide PDF build throws Java errors after requiring Java 11 on master
>
>
> Key: SOLR-13424
> URL: https://issues.apache.org/jira/browse/SOLR-13424
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>Priority: Major
>
> Since the {{master}} branch requires Java 11, the Ref Guide build has started
> throwing WARNINGs that we should look into. Despite the WARNINGs, the PDF
> build finishes successfully and appears the same as usual.
> There are a couple moving parts here - first some classes [~hossman] wrote to
> validate links in the PDF, and second a .jar from the {{asciidoctor-ant}}
> project. I suspect some of these are related to Hoss' code and some are from
> the project that's doing the PDF conversion.
> I'll put the output from a Jenkins job in the comment to show the errors.
--
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] [Created] (SOLR-13424) Ref Guide PDF build throws Java errors after requiring Java 11 on master
Cassandra Targett created SOLR-13424:
Summary: Ref Guide PDF build throws Java errors after requiring
Java 11 on master
Key: SOLR-13424
URL: https://issues.apache.org/jira/browse/SOLR-13424
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: documentation
Reporter: Cassandra Targett
Since the {{master}} branch requires Java 11, the Ref Guide build has started
throwing WARNINGs that we should look into. Despite the WARNINGs, the PDF build
finishes successfully and appears the same as usual.
There are a couple moving parts here - first some classes [~hossman] wrote to
validate links in the PDF, and second a .jar from the {{asciidoctor-ant}}
project. I suspect some of these are related to Hoss' code and some are from
the project that's doing the PDF conversion.
I'll put the output from a Jenkins job in the comment to show the errors.
--
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-13422) bin/post command not working when run from crontab
[ https://issues.apache.org/jira/browse/SOLR-13422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824129#comment-16824129 ] Cassandra Targett commented on SOLR-13422: -- Linking as a duplicate to SOLR-11515 as it looks like the same problem to me. I'll close the other one since it's had no comments or assignments since it was filed. > bin/post command not working when run from crontab > -- > > Key: SOLR-13422 > URL: https://issues.apache.org/jira/browse/SOLR-13422 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Affects Versions: 7.5, 7.7.1 >Reporter: Carsten Agger >Assignee: Erik Hatcher >Priority: Major > Labels: features > > I'm working with a script where I want to send a command to delete all > elements in an index; notably, > > /opt/solr/bin/post -c -d > "*:*" > > When run interactively, this works fine. > However, when run automatically as a cron job, it gives this interesting > output: > Unrecognized argument: "*:*" > If this was intended to be a data file, it does not exist relative to /root > The culprit seems to be these lines, 143-148: > if [[ ! -t 0 ]]; then > MODE="stdin" > else > #when no stdin exists and -d specified, the rest of the arguments > #are assumed to be strings to post as-is > MODE="args" > > This code seems to be doing the opposite of what the comment says - it sets > MODE="stdin" if stdin is NOT a terminal, but if it IS (i.e., there IS an > stdin) it assumes the rest of the args can be posted as-is. > On the other hand, if the condition is reversed, my command will fail > interactively but not when run as a cron job. Both options are, of course, > unsatisfactory. > It _will_ actually work in both cases, if instead the command to delete the > contents of the index is written as: > echo "*:*" | /opt/solr/bin/post -c > departments -d > I've confirmed this bug in SOLR v. 7.7.1 and 7.5 - it is presumably present > in more versions. > I've raised the issue on the solr-user mailing list, where I was asked to > file a Jira report. -- 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] [Resolved] (SOLR-11515) bin/post uses "-t" to check for stdin, easily breaks when run from cron (which has no terminal)
[
https://issues.apache.org/jira/browse/SOLR-11515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett resolved SOLR-11515.
--
Resolution: Duplicate
Closing as a duplicate of more recently filed SOLR-13422 since the more recent
issue has been assigned.
> bin/post uses "-t" to check for stdin, easily breaks when run from cron
> (which has no terminal)
> ---
>
> Key: SOLR-11515
> URL: https://issues.apache.org/jira/browse/SOLR-11515
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Reporter: Hoss Man
>Priority: Major
>
> one of our users (matt__) spent all day on freenode#solr trying to figure out
> why a simple script he had that called {{bin/post}} would work fine when he
> ran it, but didn't seem to do anything when run as a cronjob.
> After helping him setup better logging from cron, it ultimiately came down to
> the fact that a command like this (which was the very first thing in his
> script)...
> {code}
> bin/post -c yyy -host xxx -d 'zzz'
> {code}
> ...was failing with an error like this...
> {noformat}
> Unrecognized argument: zzz
> If this was intended to be a data file, it does not exist relative to
> /opt/blah/blah
> {noformat}
> Ultimately we determined that the problem was how {{bin/post}} tests for
> "stdin" -- by checking to see if it's _not_ being run in a terminal (with '
> {{! -t 0}} ') -- in which case it doesn't treat the argument after {{-d}} as
> data, and instead lets it fall through to the next iteration of the arg
> parsing loop (as either another switch, or a filename)
> the problem here being that running (in a script) as a cronjob is another
> case where {{bin/post}} is "not being run in a terminal" so the {{-d}}
> parsing would up completely ignoring the {{...}} string, evne though
> there was nothing being redirected on stdin.
> the workaround is to use {{echo}} to give {{bin/post}} some stdin, since it
> was going to expect it for any usage of {{-d}}...
> {code}
> echo 'zzz' | bin/post -c yyy -host xxx -d
> {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] [Resolved] (SOLR-13406) Solr Documentation Incorrect Link
[ https://issues.apache.org/jira/browse/SOLR-13406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-13406. -- Resolution: Duplicate The broken link was fixed in the 7.6 Ref Guide (via SOLR-12784) - we are unlikely to update the 6.6 guide. > Solr Documentation Incorrect Link > - > > Key: SOLR-13406 > URL: https://issues.apache.org/jira/browse/SOLR-13406 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Stephen Lewis Bianamara >Priority: Major > > There is a broken link in this documentation > [https://lucene.apache.org/solr/guide/6_6/language-analysis.html] > The example of stemdict.txt goes to a not found SVN link: > [http://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/stemdict.txt] > This link does not exist in the 7_7 documentation, and instead a file is > inlined to the doc -- 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] [Resolved] (SOLR-13379) Replica not adding automatically in solr 7.4
[ https://issues.apache.org/jira/browse/SOLR-13379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-13379. -- Resolution: Invalid The Jira system is not a support portal; we request that users use the solr-user mailing list for questions such as these instead. Information on how to subscribe is available at: http://lucene.apache.org/solr/community.html#mailing-lists-irc When you send a message to the list, please include more information than you have here. Anyone able to help you will need to know what sort of autoscaling policy you have configured, how you're adding the new node to the cluster, and what you do see happening. You'll have a higher likelihood of a reply if you provide that information in the mail to the list. > Replica not adding automatically in solr 7.4 > > > Key: SOLR-13379 > URL: https://issues.apache.org/jira/browse/SOLR-13379 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.4 >Reporter: ragupathi >Priority: Major > Labels: performance > Fix For: 7.4 > > > Hi Team, > We're able to create new server via auto-scaling for our solr cluster 7.4 > version. But the newly created server is not adding in our solr cluster > automatically. Is there any settings or configurations we need to add in > order to add the replica automatically in cluster for any collections. > Regards, > Ragupathi > -- 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] [Resolved] (SOLR-13378) Unable data import in my created collection solr 8
[
https://issues.apache.org/jira/browse/SOLR-13378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett resolved SOLR-13378.
--
Resolution: Invalid
There are several simple reasons why this might occur, and the problem most
likely traces to a local misconfiguration.
Our Jira system is not a support portal, please use the solr-user mailing list
for this type of questions until a bug has been positively identified.
Information on how to subscribe at:
http://lucene.apache.org/solr/community.html#mailing-lists-irc
> Unable data import in my created collection solr 8
> --
>
> Key: SOLR-13378
> URL: https://issues.apache.org/jira/browse/SOLR-13378
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: John
>Priority: Major
>
> I saved solr-data-config.xml, schemam.xml and solrconfig.xml in
> /opt/solr/server/solr/configsets/_default/conf folder, but im unable to
> import the data.
>
> Its showing error below:
> {code}
> The solrconfig.xml file for this index does not have an operational
> DataImportHandler defined!
> \{code}
>
> {code}centos 21956 1 95 04:56 pts/0 00:00:10 java -server -Xms1g -Xmx1g
> -XX:NewRatio=3 -XX:SurvivorRatio=4 -XX:TargetSurvivorRatio=90
> -XX:MaxTenuringThreshold=8 -XX:+UseConcMarkSweepGC -XX:ConcGCThreads=4
> -XX:ParallelGCThreads=4 -XX:+CMSScavengeBeforeRemark
> -XX:PretenureSizeThreshold=64m -XX:+UseCMSInitiatingOccupancyOnly
> -XX:CMSInitiatingOccupancyFraction=50 -XX:CMSMaxAbortablePrecleanTime=6000
> -XX:+CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled
> -XX:-OmitStackTraceInFastThrow -verbose:gc -XX:+PrintHeapAtGC
> -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps
> -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime
> -Xloggc:/opt/solr/server/logs/solr_gc.log -XX:+UseGCLogFileRotation
> -XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20M -DzkClientTimeout=15000
> -DzkHost=zookeeper-01:2181,zookeeper-02:2181,zookeeper-03:2181
> -Dsolr.log.dir=/opt/solr/server/logs -Djetty.port=8983 -DSTOP.PORT=7983
> -DSTOP.KEY=solrrocks -Duser.timezone=UTC -Djetty.home=/opt/solr/server
> -Dsolr.solr.home=/opt/solr/server/solr -Dsolr.data.home=
> -Dsolr.install.dir=/opt/solr
> -Dsolr.default.confdir=/opt/solr/server/solr/configsets/_default/conf
> -Xss256k -Dsolr.jetty.https.port=8983 -Dsolr.log.muteconsole
> -XX:OnOutOfMemoryError=/opt/solr/bin/oom_solr.sh 8983 /opt/solr/server/logs
> -jar start.jar --module=http
> {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-13336) maxBooleanClauses ignored; can result in exponential expansion of naive queries
[
https://issues.apache.org/jira/browse/SOLR-13336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-13336:
-
Security: Public (was: Private (Security Issue))
> maxBooleanClauses ignored; can result in exponential expansion of naive
> queries
> ---
>
> Key: SOLR-13336
> URL: https://issues.apache.org/jira/browse/SOLR-13336
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.0, 7.6, master (9.0)
>Reporter: Michael Gibney
>Priority: Major
>
> Since SOLR-10921 it appears that Solr always sets
> {{BooleanQuery.maxClauseCount}} (at the Lucene level) to
> {{Integer.MAX_VALUE-1}}. I assume this is because Solr parses
> {{maxBooleanClauses}} out of the config and applies it externally.
> In any case, when used as part of
> {{lucene.util.QueryBuilder.analyzeGraphPhrase}} (and possibly other places?),
> the Lucene code checks internally against only the static {{maxClauseCount}}
> variable (permanently set to {{Integer.MAX_VALUE-1}} in the context of Solr).
> Thus in at least one case ({{analyzeGraphPhrase()}}, but possibly others?),
> {{maxBooleanClauses}} is having no effect. I'm pretty sure this is what's
> underlying the [issue reported here as being related to Solr
> 7.6|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201902.mbox/%3CCAF%3DheHE6-MOtn2XRbEg7%3D1tpNEGtE8GaChnOhFLPeJzpF18SGA%40mail.gmail.com%3E].
> To summarize, users are definitely susceptible (to varying degrees of likely
> severity, assuming no actual _malicious_ attack) if:
> # Running Solr >= 7.6.0
> # Using edismax with "ps" param set to >0
> # Query-time analysis chain is _at all_ capable of producing graphs (e.g.,
> WordDelimiterGraphFilter, SynonymGraphFilter that has corresponding synonyms
> with varying token lengths.
> Users are _particularly_ vulnerable in practice if they have query-time
> {{WordDelimiterGraphFilter}} configured with {{preserveOriginal=true}}.
> To clarify, Lucene/Solr 7.6 didn't exactly _introduce_ the issue; it only
> increased the likelihood of problems manifesting (as a result of
> LUCENE-8531). Notably, the "enumerated strings" approach to graph phrase
> query (reintroduced by LUCENE-8531) was previously in place pre-6.5 – at
> which point it could rely on default Lucene-level {{maxClauseCount}} failsafe
> (removed as of 7.0). This explains the odd "Affects versions" =>
> maxBooleanClauses was disabled at the Lucene level (in Solr contexts)
> starting with version 7.0, but the change became more likely to manifest
> problems for users as of 7.6.
--
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] [Created] (SOLR-13361) Ref Guide: Upgrade docs for 7.x -> 8.0 migration
Cassandra Targett created SOLR-13361:
Summary: Ref Guide: Upgrade docs for 7.x -> 8.0 migration
Key: SOLR-13361
URL: https://issues.apache.org/jira/browse/SOLR-13361
Project: Solr
Issue Type: Task
Security Level: Public (Default Security Level. Issues are Public)
Components: documentation
Reporter: Cassandra Targett
Assignee: Cassandra Targett
Fix For: master (9.0), 8.0
Ref Guide for 8.0 needs upgrade docs similar to what we've done for other major
releases, so {{major-changes-in-solr-8.adoc}} needs a review and update before
the 8.0 Guide can be released.
--
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] (LUCENE-8726) WrappedDoubleValuesSource can leak IndexSearcher references
[ https://issues.apache.org/jira/browse/LUCENE-8726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804960#comment-16804960 ] Cassandra Targett commented on LUCENE-8726: --- Great, thanks Alan! > WrappedDoubleValuesSource can leak IndexSearcher references > --- > > Key: LUCENE-8726 > URL: https://issues.apache.org/jira/browse/LUCENE-8726 > Project: Lucene - Core > Issue Type: Bug >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 7.7.2, 8.1 > > Attachments: LUCENE-8726.patch > > > Cause of SOLR-13315 > Index-specific DoubleValuesSources can be created by > DoubleValuesSource.rewrite(), and the various consumers of these sources are > careful not to store these rewritten sources on long-lived objects, such as > queries that may be re-used between searchers. However, the bridge code > between ValueSource and DoubleValuesSource does not return a new object from > its rewrite method, instead caching the passed-in IndexSearcher, which means > references to this searcher may leak. -- 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-12879) Query Parser for MinHash/LSH
[
https://issues.apache.org/jira/browse/SOLR-12879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804956#comment-16804956
]
Cassandra Targett commented on SOLR-12879:
--
bq. I do not see the docs for this updated/added in 8.0 ...
Looks like the docs patches were not ever committed. We haven't done the 8.0
Ref Guide yet, so I can review them and commit so they can be included. I
didn't follow this issue, so just to confirm, both of the {{*.adoc.fragment}}
patches were intended to be added?
> Query Parser for MinHash/LSH
>
>
> Key: SOLR-12879
> URL: https://issues.apache.org/jira/browse/SOLR-12879
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 8.0
>Reporter: Andy Hind
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 8.0
>
> Attachments: minhash.filter.adoc.fragment, minhash.patch,
> minhash.qparser.adoc.fragment
>
>
> Following on from https://issues.apache.org/jira/browse/LUCENE-6968, provide
> a query parser that builds queries that provide a measure of Jaccard
> similarity. The initial patch includes banded queries that were also proposed
> on the original issue.
>
> I have one outstanding questions:
> * Should the score from the overall query be normalised?
> Note, that the band count is currently approximate and may be one less than
> in practise.
--
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] (LUCENE-8726) WrappedDoubleValuesSource can leak IndexSearcher references
[ https://issues.apache.org/jira/browse/LUCENE-8726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804257#comment-16804257 ] Cassandra Targett commented on LUCENE-8726: --- [~romseygeek], I know a user who ran into this with Solr 7.5, and it occurred to me others might hit it too. Would it be possible to backport this into branch_7_7 so we could release it with the next bug fix release of Lucene & Solr 7.7.x that we do? > WrappedDoubleValuesSource can leak IndexSearcher references > --- > > Key: LUCENE-8726 > URL: https://issues.apache.org/jira/browse/LUCENE-8726 > Project: Lucene - Core > Issue Type: Bug >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 8.1 > > Attachments: LUCENE-8726.patch > > > Cause of SOLR-13315 > Index-specific DoubleValuesSources can be created by > DoubleValuesSource.rewrite(), and the various consumers of these sources are > careful not to store these rewritten sources on long-lived objects, such as > queries that may be re-used between searchers. However, the bridge code > between ValueSource and DoubleValuesSource does not return a new object from > its rewrite method, instead caching the passed-in IndexSearcher, which means > references to this searcher may leak. -- 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-13349) High CPU usage in Solr due to Java 8 bug
[
https://issues.apache.org/jira/browse/SOLR-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16801885#comment-16801885
]
Cassandra Targett commented on SOLR-13349:
--
Does it really impact 6.6? If the theory is correct that the change from 1 to 0
is causing the problem, then the code change occurred with 7.7:
branch_6_6:
https://github.com/apache/lucene-solr/blob/branch_6_6/solr/core/src/java/org/apache/solr/update/CommitTracker.java#L58
branch_7_7:
https://github.com/apache/lucene-solr/blob/branch_7_7/solr/core/src/java/org/apache/solr/update/CommitTracker.java#L62
> High CPU usage in Solr due to Java 8 bug
>
>
> Key: SOLR-13349
> URL: https://issues.apache.org/jira/browse/SOLR-13349
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6, 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Priority: Major
>
> We've had sporadic reports of high CPU usage in Solr 7. Lukas Weiss reported
> a Java 8 bug that appears to be the root cause (I have not personally
> verified), see: [https://bugs.openjdk.java.net/browse/JDK-8129861] e-mail
> reproduced below:
> CommitTracker makes this call:
> Executors.newScheduledThreadPool(0, new
> DefaultSolrThreadFactory("commitScheduler"));
> The supposition is that calling this with 1 will fix this (untested)
> [~ichattopadhyaya] This affects 6.6 and IIUC you're spinning a new version.
> We'll need to verify and include this fix.
> [~jpountz] You're right. I first thought "naaah, it wouldn't be that far
> back" but your question made me check, thanks!
> AFAICT, this is the only place in Solr/Lucene that uses zero.
> Using Java 9+ is another work-around.
> Anyone picking this up should port to 7.7 as well.
> e-mail from the user's list (many thanks to Lukas and Adam).
> Apologies, I can’t figure out how to reply to the Solr mailing list.
> I just ran across the same high CPU usage issue. I believe it’’s caused by
> this commit which was introduced in Solr 7.7.0
>
> [https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5]
> There is a bug in JDK versions <=8 where using 0 threads in the
> ScheduledThreadPool causes high CPU usage:
> [https://bugs.openjdk.java.net/browse/JDK-8129861]
> Oddly, the latest version
> of solr/core/src/java/org/apache/solr/update/CommitTracker.java on
> master still uses 0 executors as the default. Presumably most everyone is
> using JDK 9 or greater which has the bug fixed, so they don’t experience
> the bug.
> Feel free to relay this back to the mailing list.
> Thanks,
> Adam Guthrie
>
>
--
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-11959) CDCR unauthorized to replicate to a target collection that is update protected in security.json
[
https://issues.apache.org/jira/browse/SOLR-11959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16801666#comment-16801666
]
Cassandra Targett commented on SOLR-11959:
--
Totally missed the doc patch on this, sorry. I applied it finally.
> CDCR unauthorized to replicate to a target collection that is update
> protected in security.json
> ---
>
> Key: SOLR-11959
> URL: https://issues.apache.org/jira/browse/SOLR-11959
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, CDCR
>Affects Versions: 7.2
>Reporter: Donny Andrews
>Priority: Major
> Attachments: SOLR-11959.patch
>
>
> Steps to reproduce:
> # Create a source and a target collection in their respective clusters.
> # Update security.json to require a non-admin role to read and write.
> # Index to source collection
> Expected:
> The target collection should receive the update
> Actual:
> {code:java}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://redacted/solr/redacted: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 Unauthorized request, Response code: 401
>
> HTTP ERROR 401
> Problem accessing /solr/redacted/update. Reason:
> Unauthorized request, Response code: 401
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816)
> at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
> at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
> at
> org.apache.solr.handler.CdcrReplicator.sendRequest(CdcrReplicator.java:140)
> at org.apache.solr.handler.CdcrReplicator.run(CdcrReplicator.java:104)
> at
> org.apache.solr.handler.CdcrReplicatorScheduler.lambda$null$0(CdcrReplicatorScheduler.java:81)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){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-12809) Document recommended Java/Solr combinations (JDK 11?)
[ https://issues.apache.org/jira/browse/SOLR-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16797514#comment-16797514 ] Cassandra Targett commented on SOLR-12809: -- I'm +1 for a matrix, but I'd like to discourage a matrix that has a list of footnotes in it as in the latest example. You might find it easier to write, but it's harder for users and they're the ones we're trying to serve here. We have one already in the Ref Guide, and it's a horrible way of presenting information (https://lucene.apache.org/solr/guide/7_7/field-properties-by-use-case.html). It's way better IMO to just repeat the information in the cells, and as far as your effort, copy/paste can be your friend. > Document recommended Java/Solr combinations (JDK 11?) > - > > Key: SOLR-12809 > URL: https://issues.apache.org/jira/browse/SOLR-12809 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > JDK 8 will be EOL early next year (except for "premier support"). JDK 9, 10 > and 11 all have issues for Solr and Lucene IIUC. > Also IIUC Oracle will start requiring commercial licenses for 11. > This Jira is to discuss what we want to do going forward. Among the topics: > * Skip straight to 11, skipping 9 and 10? If so how to resolve current > issues? > * How much emphasis on OpenJDK .vs. Oracle's version > * What to do about dependencies that don't work (for whatever reason) with > the version of Java we go with? > * ??? > This may turn into an umbrella Jira with sub-tasks of course. Since JDK 11 > has had a GA release, I'd also like to have a record of where the current > issues are to refer people to. -- 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-12884) Admin UI doesn't show info about *Point fields in Schema browser screen
[
https://issues.apache.org/jira/browse/SOLR-12884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16795152#comment-16795152
]
Cassandra Targett commented on SOLR-12884:
--
Changed the title of the issue to reflect the problem since I kept trying to
look for it and couldn't find it based on the old title.
> Admin UI doesn't show info about *Point fields in Schema browser screen
> ---
>
> Key: SOLR-12884
> URL: https://issues.apache.org/jira/browse/SOLR-12884
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 8.0
>Reporter: Erick Erickson
>Priority: Major
>
> One of the conference attendees noted that you go to the schema browser and
> click on, say, a pint field, then click "load term info", nothing is shown.
> admin/luke similarly doesn't show much interesting, here's the response for a
> pint .vs. a tint field:
> "popularity":\{ "type":"pint", "schema":"I-SD-OF--"},
> "popularityt":{ "type":"tint", "schema":"I-S--OF--",
> "index":"-TS--", "docs":15},
>
> What, if anything, should we do in these two cases? Since the points-based
> numerics don't have terms like Trie* fields, I don't think we _can_ show much
> more so the above makes sense, it's just jarring to end users and looks like
> a bug.
> WDYT about putting in some useful information though. Say for the Admin UI
> for points-based "terms cannot be shown for points-based fields" or some such?
--
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-12884) Admin UI doesn't show info about *Point fields in Schema browser screen
[
https://issues.apache.org/jira/browse/SOLR-12884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-12884:
-
Summary: Admin UI doesn't show info about *Point fields in Schema browser
screen (was: Admin UI, admin/luke and *Point fields)
> Admin UI doesn't show info about *Point fields in Schema browser screen
> ---
>
> Key: SOLR-12884
> URL: https://issues.apache.org/jira/browse/SOLR-12884
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 8.0
>Reporter: Erick Erickson
>Priority: Major
>
> One of the conference attendees noted that you go to the schema browser and
> click on, say, a pint field, then click "load term info", nothing is shown.
> admin/luke similarly doesn't show much interesting, here's the response for a
> pint .vs. a tint field:
> "popularity":\{ "type":"pint", "schema":"I-SD-OF--"},
> "popularityt":{ "type":"tint", "schema":"I-S--OF--",
> "index":"-TS--", "docs":15},
>
> What, if anything, should we do in these two cases? Since the points-based
> numerics don't have terms like Trie* fields, I don't think we _can_ show much
> more so the above makes sense, it's just jarring to end users and looks like
> a bug.
> WDYT about putting in some useful information though. Say for the Admin UI
> for points-based "terms cannot be shown for points-based fields" or some such?
--
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] [Resolved] (SOLR-13301) [CVE-2019-0192] Deserialization of untrusted data via jmx.serviceUrl
[
https://issues.apache.org/jira/browse/SOLR-13301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett resolved SOLR-13301.
--
Resolution: Information Provided
> [CVE-2019-0192] Deserialization of untrusted data via jmx.serviceUrl
>
>
> Key: SOLR-13301
> URL: https://issues.apache.org/jira/browse/SOLR-13301
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: config-api
>Affects Versions: 5.0, 5.1, 5.2, 5.2.1, 5.3, 5.3.1, 5.3.2, 5.4, 5.4.1,
> 5.5, 5.5.1, 5.5.2, 5.5.3, 5.5.4, 5.5.5, 6.0, 6.0.1, 6.1, 6.1.1, 6.2, 6.2.1,
> 6.3, 6.4, 6.4.1, 6.4.2, 6.5, 6.5.1, 6.6, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
> Fix For: 7.0
>
> Attachments: SOLR-13301.patch
>
>
> From the vulnerability reporter:
> {quote}ConfigAPI allows to set a jmx.serviceUrl that will create a new
> [JMXConnectorServerFactory|https://docs.oracle.com/javase/7/docs/api/javax/management/remote/JMXConnectorServerFactory.html]
> and trigger a call with 'bind' operation to a target RMI/LDAP server. A
> malicious RMI server could respond with arbitrary object that will be
> deserialized on the Solr side using java's ObjectInputStream, which is
> considered unsafe. This type of vulnerabilities can be exploited with
> ysoserial tool. Depending on the target classpath, an attacker can use one of
> the "gadget chains" to trigger Remote Code Execution on the Solr side.
> {quote}
> Mitigation:
> Any of the following are enough to prevent this vulnerability:
> * Upgrade to Apache Solr 7.0 or later.
> * Disable the ConfigAPI if not in use, by running Solr with the system
> property {{disable.configEdit=true}}
> * If upgrading or disabling the Config API are not viable options, apply
> [^SOLR-13301.patch] and re-compile Solr.
> * Ensure your network settings are configured so that only trusted traffic
> is allowed to ingress/egress your hosts running Solr.
> Since Solr 7.0, JMX server is no longer configurable via API
--
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-13296) Example of Preanalyzed JSON in ref guide invalid
[
https://issues.apache.org/jira/browse/SOLR-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16786785#comment-16786785
]
Cassandra Targett commented on SOLR-13296:
--
Since the 8.0 Ref Guide isn't out yet, IMO this should be backported into
branch_8_0. I'll do that once the new 8.0 RC is out so I don't screw that
process up (probably wouldn't, but just to be safest), but there's no reason to
knowingly release with bad info.
> Example of Preanalyzed JSON in ref guide invalid
>
>
> Key: SOLR-13296
> URL: https://issues.apache.org/jira/browse/SOLR-13296
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 7.6
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Trivial
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-13296.patch
>
>
> Writing a test for a use case that was pre-analyzing a field for a customer I
> decided to first check that the config could successfully accept a chunk of
> preanalyzed json. Thus I grabbed the example in the docs and BOOM
> {code}
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from
> server at http://127.0.0.1:63302/solr/testCol_shard1_replica_n1: Exception
> writing document id 1 to the index; possible analysis error: startOffset must
> be non-negative, and endOffset must be >= startOffset, and offsets must not
> go backwards startOffset=5,endOffset=8,lastStartOffset=123 for field
> 'preanalyzed'
> {code}
> Turns out the example has token offsets that go backwards... attaching a
> patch to make the (mostly nonsensical) example at least technically valid
--
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-13259) Ref Guide: Add explicit docs on when to reindex after field/schema changes
[ https://issues.apache.org/jira/browse/SOLR-13259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16783625#comment-16783625 ] Cassandra Targett edited comment on SOLR-13259 at 3/4/19 7:05 PM: -- Thanks everyone who reviewed and gave feedback, I've incorporated just about all of it somehow. We can iterate on the page going forward. Anyone who wants to refer to the page before 8.0 Ref Guide is out can use the page from the branch_8x build: https://builds.apache.org/view/L/view/Lucene/job/Solr-reference-guide-8.x/javadoc/reindexing.html was (Author: ctargett): Thanks everyone who reviewed and gave feedback, I've incorporated just about all of it somehow. We can iterate on the page going forward. > Ref Guide: Add explicit docs on when to reindex after field/schema changes > -- > > Key: SOLR-13259 > URL: https://issues.apache.org/jira/browse/SOLR-13259 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: 8.0, master (9.0) > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Many changes to field definitions, field types, or other things defined in > the schema require documents to be reindexed, but some can be OK if the > consequences of not reindexing are acceptable, and still other changes do not > require a reindex at all. > It would be nice if the Ref Guide had some definitive information about these > types of changes to assist users with planning changes to the schema. -- 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] [Resolved] (SOLR-13259) Ref Guide: Add explicit docs on when to reindex after field/schema changes
[ https://issues.apache.org/jira/browse/SOLR-13259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-13259. -- Resolution: Fixed Thanks everyone who reviewed and gave feedback, I've incorporated just about all of it somehow. We can iterate on the page going forward. > Ref Guide: Add explicit docs on when to reindex after field/schema changes > -- > > Key: SOLR-13259 > URL: https://issues.apache.org/jira/browse/SOLR-13259 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: 8.0, master (9.0) > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Many changes to field definitions, field types, or other things defined in > the schema require documents to be reindexed, but some can be OK if the > consequences of not reindexing are acceptable, and still other changes do not > require a reindex at all. > It would be nice if the Ref Guide had some definitive information about these > types of changes to assist users with planning changes to the schema. -- 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-12884) Admin UI, admin/luke and *Point fields
[
https://issues.apache.org/jira/browse/SOLR-12884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-12884:
-
Component/s: Admin UI
> Admin UI, admin/luke and *Point fields
> --
>
> Key: SOLR-12884
> URL: https://issues.apache.org/jira/browse/SOLR-12884
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 8.0
>Reporter: Erick Erickson
>Priority: Major
>
> One of the conference attendees noted that you go to the schema browser and
> click on, say, a pint field, then click "load term info", nothing is shown.
> admin/luke similarly doesn't show much interesting, here's the response for a
> pint .vs. a tint field:
> "popularity":\{ "type":"pint", "schema":"I-SD-OF--"},
> "popularityt":{ "type":"tint", "schema":"I-S--OF--",
> "index":"-TS--", "docs":15},
>
> What, if anything, should we do in these two cases? Since the points-based
> numerics don't have terms like Trie* fields, I don't think we _can_ show much
> more so the above makes sense, it's just jarring to end users and looks like
> a bug.
> WDYT about putting in some useful information though. Say for the Admin UI
> for points-based "terms cannot be shown for points-based fields" or some such?
--
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-13278) Using multiple dictionaries with Solr Suggester
[
https://issues.apache.org/jira/browse/SOLR-13278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-13278:
-
Fix Version/s: (was: 7.7)
> Using multiple dictionaries with Solr Suggester
> ---
>
> Key: SOLR-13278
> URL: https://issues.apache.org/jira/browse/SOLR-13278
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 7.5
>Reporter: R Chander
>Priority: Major
> Attachments: solr.json
>
>
> When I query using a single dictionary, I get the expected suggest results.
>
> However, when I run this query on two dictionaries:
> [{color:#0066cc}http://localhost:8983/solr/test/suggest?wt=json&suggest.count=10&suggest.q=gcintranet&suggest.dictionary=gcintranet&suggest.cfq=gcintranet&suggest.dictionary=infosite&suggest.cfq=infosite{color}]
> I get the same output as shown in the attached solr.json file.
>
>
--
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-13278) Using multiple dictionaries with Solr Suggester
[
https://issues.apache.org/jira/browse/SOLR-13278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16780629#comment-16780629
]
Cassandra Targett commented on SOLR-13278:
--
Please describe the bug here? By simply uploading a response file, you're
expecting us to guess at it the problem you're seeing. You're putting the onus
on us to figure out the problem, and that's not likely to yield you much
response.
Since the problem is so ill-defined here, it seems likely that you should first
take your question to the Solr user list before filling a Jira - this isn't a
support portal, that's what we use the Solr user list for. Information on how
to subscribe is at:
http://lucene.apache.org/solr/community.html#mailing-lists-irc
> Using multiple dictionaries with Solr Suggester
> ---
>
> Key: SOLR-13278
> URL: https://issues.apache.org/jira/browse/SOLR-13278
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 7.5
>Reporter: R Chander
>Priority: Major
> Fix For: 7.7
>
> Attachments: solr.json
>
>
> When I query using a single dictionary, I get the expected suggest results.
>
> However, when I run this query on two dictionaries:
> [{color:#0066cc}http://localhost:8983/solr/test/suggest?wt=json&suggest.count=10&suggest.q=gcintranet&suggest.dictionary=gcintranet&suggest.cfq=gcintranet&suggest.dictionary=infosite&suggest.cfq=infosite{color}]
> I get the same output as shown in the attached solr.json file.
>
>
--
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] [Resolved] (SOLR-13274) BasicAuthPlugin causes MetricsHistoryHandler errors - "could not get tags from node" - 401 require authentication
[ https://issues.apache.org/jira/browse/SOLR-13274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-13274. -- Resolution: Duplicate Closing as a duplicate of SOLR-12860. > BasicAuthPlugin causes MetricsHistoryHandler errors - "could not get tags > from node" - 401 require authentication > - > > Key: SOLR-13274 > URL: https://issues.apache.org/jira/browse/SOLR-13274 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.4 >Reporter: Danny Shih >Priority: Major > > With a SOLR 7.4.0 server correctly configured in cloud mode with the > BasicAuthPlugin, we are seeing the following WARN log spammed. > It's unclear if there's something actually wrong with metrics functionality > (we don't really use it). > Relevant thread: > http://lucene.472066.n3.nabble.com/Overseer-could-not-get-tags-td4409997.html#a4426307 > --- > 2019-02-26 15:56:16.996 -0800 (,,,) MetricsHistoryHandler-12-thread-1 : WARN > org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider - could not get > tags from node localhost:11000_solr > org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error > from server at https://localhost:11000/solr: Expected mime type > application/octet-stream but got text/html. > > > Error 401 require authentication > > HTTP ERROR 401 > Problem accessing /solr/admin/metrics. Reason: > require authentication > > > at > org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607) > ~[solr-solrj-7.4.0.jar:7.4.0 9060ac689c270b02143f375de0348b7f626adebc - > jpountz - 2018-06-18 16:55:14] > at > org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) > ~[solr-solrj-7.4.0.jar:7.4.0 9060ac689c270b02143f375de0348b7f626adebc - > jpountz - 2018-06-18 16:55:14] > at > org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) > ~[solr-solrj-7.4.0.jar:7.4.0 9060ac689c270b02143f375de0348b7f626adebc - > jpountz - 2018-06-18 16:55:14] > at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) > ~[solr-solrj-7.4.0.jar:7.4.0 9060ac689c270b02143f375de0348b7f626adebc - > jpountz - 2018-06-18 16:55:14] > at > org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:292) > ~[solr-solrj-7.4.0.jar:7.4.0 9060ac689c270b02143f375de0348b7f626adebc - > jpountz - 2018-06-18 16:55:14] > at > org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchMetrics(SolrClientNodeStateProvider.java:150) > ~[solr-solrj-7.4.0.jar:7.4.0 9060ac689c270b02143f375de0348b7f626adebc - > jpountz - 2018-06-18 16:55:14] > at > org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:199) > ~[solr-solrj-7.4.0.jar:7.4.0 9060ac689c270b02143f375de0348b7f626adebc - > jpountz - 2018-06-18 16:55:14] > at > org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76) > ~[solr-solrj-7.4.0.jar:7.4.0 9060ac689c270b02143f375de0348b7f626adebc - > jpountz - 2018-06-18 16:55:14] > at > org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:111) > ~[solr-solrj-7.4.0.jar:7.4.0 9060ac689c270b02143f375de0348b7f626adebc - > jpountz - 2018-06-18 16:55:14] > at > org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:495) > ~[solr-core-7.4.0.jar:7.4.0 9060ac689c270b02143f375de0348b7f626adebc - > jpountz - 2018-06-18 16:55:13] > at > org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:368) > ~[solr-core-7.4.0.jar:7.4.0 9060ac689c270b02143f375de0348b7f626adebc - > jpountz - 2018-06-18 16:55:13] > at > org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:230) > ~[solr-core-7.4.0.jar:7.4.0 9060ac689c270b02143f375de0348b7f626adebc - > jpountz - 2018-06-18 16:55:13] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [?:1.8.0_181-b13] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > [?:1.8.0_181-b13] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > [?:1.8.0_181-b13] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > [?:1.8.0_181-b13] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [?:1.8.0_181-b13] > at > java.util.concurrent.ThreadPoolExecutor$Worke
[jira] [Resolved] (SOLR-13275) I am using solr in my project.when i try to search with keyword utilities in my project it gives 403 error
[ https://issues.apache.org/jira/browse/SOLR-13275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-13275. -- Resolution: Invalid Solr support is available from the solr-user mailing list only. Please see http://lucene.apache.org/solr/community.html#mailing-lists-irc for how to subscribe. > I am using solr in my project.when i try to search with keyword utilities in > my project it gives 403 error > -- > > Key: SOLR-13275 > URL: https://issues.apache.org/jira/browse/SOLR-13275 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ashlesha >Priority: Major > > I am using solr in my project.when i try to search with keyword utilities in > my project it gives 403 error.But when i search by keword uti it gives me > desired result -- 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-13256) Ref Guide: Upgrade Notes for 7.7
[
https://issues.apache.org/jira/browse/SOLR-13256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771316#comment-16771316
]
Cassandra Targett commented on SOLR-13256:
--
I took a look at the patch - to date, we haven't mentioned Known Issues in the
Upgrade Notes. I saw you had the one for the maxShardsPerNode problem in an
earlier patch, but in this patch I see you've added another item for whatever
it is wrong with whichever URP or whatever.
It would be nice if we could do something for a Known Issues list, but it's
actually really hard for Solr. There are over 1500 open "Bugs" in Jira, many of
them open for a long, long time. What's the criteria for being included here?
What about all the prior releases?
Maybe it makes sense to hold the 7.7 Ref Guide until we figure out what is
going to happen with those issues re: 7.7.1? It seems they are both big enough
to warrant a 7.7.1 release on their own, and if they are fixed we won't have to
worry about explaining them, we can say as a community we recommend moving to
7.7.1 since it resolves both of those issues.
> Ref Guide: Upgrade Notes for 7.7
>
>
> Key: SOLR-13256
> URL: https://issues.apache.org/jira/browse/SOLR-13256
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13256.patch
>
>
> With 7.7 released and out the door, we should get the ball moving on a 7.7
> ref-guide. One of the prerequisites for that process is putting together
> some upgrade notes that can go in
> {{solr/solr-ref-guide/src/solr-upgrade-notes.adoc}} for users upgrading to
> 7.7.
> I'm going to take a look at CHANGES and take a first pass at the "upgrading"
> section for 7.7. If anyone has anything they know should be in the list,
> please let me know and I'll try to include it.
--
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] [Created] (SOLR-13259) Ref Guide: Add explicit docs on when to reindex after field/schema changes
Cassandra Targett created SOLR-13259: Summary: Ref Guide: Add explicit docs on when to reindex after field/schema changes Key: SOLR-13259 URL: https://issues.apache.org/jira/browse/SOLR-13259 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Reporter: Cassandra Targett Assignee: Cassandra Targett Fix For: 8.0, master (9.0) Many changes to field definitions, field types, or other things defined in the schema require documents to be reindexed, but some can be OK if the consequences of not reindexing are acceptable, and still other changes do not require a reindex at all. It would be nice if the Ref Guide had some definitive information about these types of changes to assist users with planning changes to the schema. -- 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-13235) Split Ref Guide Collections API page into several sub-pages
[ https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16769756#comment-16769756 ] Cassandra Targett commented on SOLR-13235: -- I've created a PR for this in lieu of a patch: https://github.com/apache/lucene-solr/pull/575 > Split Ref Guide Collections API page into several sub-pages > --- > > Key: SOLR-13235 > URL: https://issues.apache.org/jira/browse/SOLR-13235 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: 8.0, master (9.0) > > Time Spent: 10m > Remaining Estimate: 0h > > The Collections API page in the Ref Guide has become the de-facto place where > information about how to work with Solr collections is stored, but it is so > huge with API examples that information gets lost. > I did some work a couple months ago to split this up, and came up with this > approach to splitting up the content: > * *Cluster and Node Management*: Define properties for the entire cluster; > check the status of a cluster; remove replicas from a node; utilize a newly > added node; add or remove roles for a node. > * *Collection Management*: Create, list, reload and delete collections; set > collection properties; migrate documents to another collection; rebalance > leaders; backup and restore collections. > * *Collection Aliasing*: Create, list or delete collection aliases; set alias > properties. > * *Shard Management*: Create and delete a shard; split a shard into two or > more additional shards; force a shard leader. > * *Replica Management*: Add or delete a replica; set replica properties; move > a replica to a different node. > My existing local WIP leaves info on Async commands on the main > collections-api.adoc page, but creates new pages for each of the bullets > mentioned above, and moves the related API calls to those pages. Each topic > will be smaller and easier for us to manage on an ongoing basis. > Since I did the work a while ago, I need to bring it up to date with master, > so a patch & a branch with this work will be forthcoming shortly. -- 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-13235) Split Ref Guide Collections API page into several sub-pages
[ https://issues.apache.org/jira/browse/SOLR-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-13235: - Description: The Collections API page in the Ref Guide has become the de-facto place where information about how to work with Solr collections is stored, but it is so huge with API examples that information gets lost. I did some work a couple months ago to split this up, and came up with this approach to splitting up the content: * *Cluster and Node Management*: Define properties for the entire cluster; check the status of a cluster; remove replicas from a node; utilize a newly added node; add or remove roles for a node. * *Collection Management*: Create, list, reload and delete collections; set collection properties; migrate documents to another collection; rebalance leaders; backup and restore collections. * *Collection Aliasing*: Create, list or delete collection aliases; set alias properties. * *Shard Management*: Create and delete a shard; split a shard into two or more additional shards; force a shard leader. * *Replica Management*: Add or delete a replica; set replica properties; move a replica to a different node. My existing local WIP leaves info on Async commands on the main collections-api.adoc page, but creates new pages for each of the bullets mentioned above, and moves the related API calls to those pages. Each topic will be smaller and easier for us to manage on an ongoing basis. Since I did the work a while ago, I need to bring it up to date with master, so a patch & a branch with this work will be forthcoming shortly. was: The Collections API page has become the de-facto place where information about how to work with Solr collections is stored, but it is so huge with API examples that information gets lost. I did some work a couple months ago to split this up, and came up with this approach to splitting up the content: * *Cluster and Node Management*: Define properties for the entire cluster; check the status of a cluster; remove replicas from a node; utilize a newly added node; add or remove roles for a node. * *Collection Management*: Create, list, reload and delete collections; set collection properties; migrate documents to another collection; rebalance leaders; backup and restore collections. * *Collection Aliasing*: Create, list or delete collection aliases; set alias properties. * *Shard Management*: Create and delete a shard; split a shard into two or more additional shards; force a shard leader. * *Replica Management*: Add or delete a replica; set replica properties; move a replica to a different node. My existing local WIP leaves info on Async commands on the main collections-api.adoc page, but creates new pages for each of the bullets mentioned above, and moves the related API calls to those pages. Each topic will be smaller and easier for us to manage on an ongoing basis. Since I did the work a while ago, I need to bring it up to date with master, so a patch & a branch with this work will be forthcoming shortly. > Split Ref Guide Collections API page into several sub-pages > --- > > Key: SOLR-13235 > URL: https://issues.apache.org/jira/browse/SOLR-13235 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > Fix For: 8.0, master (9.0) > > > The Collections API page in the Ref Guide has become the de-facto place where > information about how to work with Solr collections is stored, but it is so > huge with API examples that information gets lost. > I did some work a couple months ago to split this up, and came up with this > approach to splitting up the content: > * *Cluster and Node Management*: Define properties for the entire cluster; > check the status of a cluster; remove replicas from a node; utilize a newly > added node; add or remove roles for a node. > * *Collection Management*: Create, list, reload and delete collections; set > collection properties; migrate documents to another collection; rebalance > leaders; backup and restore collections. > * *Collection Aliasing*: Create, list or delete collection aliases; set alias > properties. > * *Shard Management*: Create and delete a shard; split a shard into two or > more additional shards; force a shard leader. > * *Replica Management*: Add or delete a replica; set replica properties; move > a replica to a different node. > My existing local WIP leaves info on Async commands on the main > collections-api.adoc page, but creates new pages for each of the bullets > mentioned above, and moves the related API calls to those pages. Each topic >
[jira] [Created] (SOLR-13235) Split Ref Guide Collections API page into several sub-pages
Cassandra Targett created SOLR-13235: Summary: Split Ref Guide Collections API page into several sub-pages Key: SOLR-13235 URL: https://issues.apache.org/jira/browse/SOLR-13235 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Reporter: Cassandra Targett Assignee: Cassandra Targett Fix For: 8.0, master (9.0) The Collections API page has become the de-facto place where information about how to work with Solr collections is stored, but it is so huge with API examples that information gets lost. I did some work a couple months ago to split this up, and came up with this approach to splitting up the content: * *Cluster and Node Management*: Define properties for the entire cluster; check the status of a cluster; remove replicas from a node; utilize a newly added node; add or remove roles for a node. * *Collection Management*: Create, list, reload and delete collections; set collection properties; migrate documents to another collection; rebalance leaders; backup and restore collections. * *Collection Aliasing*: Create, list or delete collection aliases; set alias properties. * *Shard Management*: Create and delete a shard; split a shard into two or more additional shards; force a shard leader. * *Replica Management*: Add or delete a replica; set replica properties; move a replica to a different node. My existing local WIP leaves info on Async commands on the main collections-api.adoc page, but creates new pages for each of the bullets mentioned above, and moves the related API calls to those pages. Each topic will be smaller and easier for us to manage on an ongoing basis. Since I did the work a while ago, I need to bring it up to date with master, so a patch & a branch with this work will be forthcoming shortly. -- 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-12833) Use timed-out lock in DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-12833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763030#comment-16763030 ] Cassandra Targett commented on SOLR-12833: -- [~markrmil...@gmail.com], I think this be resolved? It appears in the CHANGES for 7.7, so it being open and only marked for 8.0 makes me unsure. > Use timed-out lock in DistributedUpdateProcessor > > > Key: SOLR-12833 > URL: https://issues.apache.org/jira/browse/SOLR-12833 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: update, UpdateRequestProcessors >Affects Versions: 7.5, 8.0 >Reporter: jefferyyuan >Assignee: Mark Miller >Priority: Minor > Fix For: 8.0 > > Attachments: SOLR-12833.patch, SOLR-12833.patch > > Time Spent: 20m > Remaining Estimate: 0h > > There is a synchronize block that blocks other update requests whose IDs fall > in the same hash bucket. The update waits forever until it gets the lock at > the synchronize block, this can be a problem in some cases. > > Some add/update requests (for example updates with spatial/shape analysis) > like may take time (30+ seconds or even more), this would the request time > out and fail. > Client may retry the same requests multiple times or several minutes, this > would make things worse. > The server side receives all the update requests but all except one can do > nothing, have to wait there. This wastes precious memory and cpu resource. > We have seen the case 2000+ threads are blocking at the synchronize lock, and > only a few updates are making progress. Each thread takes 3+ mb memory which > causes OOM. > Also if the update can't get the lock in expected time range, its better to > fail fast. > > We can have one configuration in solrconfig.xml: > updateHandler/versionLock/timeInMill, so users can specify how long they want > to wait the version bucket lock. > The default value can be -1, so it behaves same - wait forever until it gets > the lock. -- 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-12833) Use timed-out lock in DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-12833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763030#comment-16763030 ] Cassandra Targett edited comment on SOLR-12833 at 2/7/19 7:57 PM: -- [~markrmil...@gmail.com], I think this can be resolved? It appears in the CHANGES for 7.7, so it being open and only marked for 8.0 makes me unsure. was (Author: ctargett): [~markrmil...@gmail.com], I think this be resolved? It appears in the CHANGES for 7.7, so it being open and only marked for 8.0 makes me unsure. > Use timed-out lock in DistributedUpdateProcessor > > > Key: SOLR-12833 > URL: https://issues.apache.org/jira/browse/SOLR-12833 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: update, UpdateRequestProcessors >Affects Versions: 7.5, 8.0 >Reporter: jefferyyuan >Assignee: Mark Miller >Priority: Minor > Fix For: 8.0 > > Attachments: SOLR-12833.patch, SOLR-12833.patch > > Time Spent: 20m > Remaining Estimate: 0h > > There is a synchronize block that blocks other update requests whose IDs fall > in the same hash bucket. The update waits forever until it gets the lock at > the synchronize block, this can be a problem in some cases. > > Some add/update requests (for example updates with spatial/shape analysis) > like may take time (30+ seconds or even more), this would the request time > out and fail. > Client may retry the same requests multiple times or several minutes, this > would make things worse. > The server side receives all the update requests but all except one can do > nothing, have to wait there. This wastes precious memory and cpu resource. > We have seen the case 2000+ threads are blocking at the synchronize lock, and > only a few updates are making progress. Each thread takes 3+ mb memory which > causes OOM. > Also if the update can't get the lock in expected time range, its better to > fail fast. > > We can have one configuration in solrconfig.xml: > updateHandler/versionLock/timeInMill, so users can specify how long they want > to wait the version bucket lock. > The default value can be -1, so it behaves same - wait forever until it gets > the lock. -- 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-13226) Add note for Node Added Trigger documentation in Autoscaling
[
https://issues.apache.org/jira/browse/SOLR-13226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16761899#comment-16761899
]
Cassandra Targett commented on SOLR-13226:
--
I don't know...in general, I wonder why anyone would expect a rule to be
followed when they set it as optional.
Putting all replicas on a single node feels like a different problem. Setting
the rules as strict may mitigate the problem, but why is Solr doing that?
> Add note for Node Added Trigger documentation in Autoscaling
>
>
> Key: SOLR-13226
> URL: https://issues.apache.org/jira/browse/SOLR-13226
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: Amrit Sarkar
>Priority: Major
> Attachments: SOLR-13226.patch, Screen Shot 2019-02-05 at 3.55.31
> AM.png, Screen Shot 2019-02-05 at 4.02.00 AM.png
>
>
> Node Added Trigger doesn't abide by SOFT rules [strict: false] and results in
> abnormal cluster operational behavior.
> Let's say; we wish to do the following:
> 1. Not more than 10 cores reside on Single node.
> 2. Wish to distribute the cores, replicas equally to each Node.
> If we go by the following policy:
> not more than one replica for unique shard on a node. not a strict rule.
> {code}
> {"replica":"<2", "shard": "#EACH", "node": "#ANY", "strict": false},
> {code}
> distribute the replicas equally across the nodes, not a strict rule.
> {code}
> {"replica": "#EQUAL", "node": "#ANY", "strict": false},
> {code}
> not more than 10 cores allowed on a single node, strict rule.
> {code}
> {"cores": "<10", "node": "#ANY"}
> {code}
> cluster state ends up like:
> Screenshot -1
> Only the strict rule is followed and multiple replicas are added to single
> Solr node, as rules are not strict – _{"replica":"<2", "shard": "#EACH",
> "node": "#ANY", "strict": false}_
> While the following with all strict rule generate normal operational
> behavior, add a replica to each shard of collection 'wiki' :
> {code}
> [
> {"replica":"<2", "shard": "#EACH", "node": "#ANY"},
> {"replica": "#EQUAL", "node": "#ANY"},
> {"cores": "<10", "node": "#ANY"}
> ]
> {code}
> Screenshot -2
> This behavior should be documented.
--
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-13129) Document nested child docs in the ref guide
[ https://issues.apache.org/jira/browse/SOLR-13129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16761882#comment-16761882 ] Cassandra Targett commented on SOLR-13129: -- By the way, I am a very nit-picky editor, you'll see this in my comments to the PR. Please do not take my feedback as negative even though I'm a little rushed and probably not as polite as I could be in all my comments. Thank you for writing this up and working with us to get it right. > Document nested child docs in the ref guide > --- > > Key: SOLR-13129 > URL: https://issues.apache.org/jira/browse/SOLR-13129 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.0 >Reporter: David Smiley >Priority: Major > Fix For: 8.0 > > Time Spent: 7h 10m > Remaining Estimate: 0h > > Solr 8.0 will have nicer support for nested child documents than its > predecessors. This should be documented in one place in the ref guide (to > the extent that makes sense). Users need to the schema ramifications (incl. > special fields and that some aspects are optional and when), what a nested > document "looks like" (XML, JSON, SolrJ), how to use the child doc > transformer, how to use block join queries, and get some overview of how this > all works. Maybe mention some plausible future enhancements / direction this > is going in (e.g. path query language?). Some of this is already done but > it's in various places and could be moved. Unlike other features which > conveniently fit into one spot in the documentation (like a query parser), > this is a more complex issue that has multiple aspects – more > "cross-cutting", and so IMO doesn't belong in the current doc pigeon holes. -- 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-13129) Document nested child docs in the ref guide
[ https://issues.apache.org/jira/browse/SOLR-13129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16761801#comment-16761801 ] Cassandra Targett commented on SOLR-13129: -- I've been _*swamped*_ lately - day job, personal life, everything feels like one long list of stuff I'm not getting done - so I know you've pinged me a couple of times and I apologize that I haven't responded. I'll try to take a look at the work here today. > Document nested child docs in the ref guide > --- > > Key: SOLR-13129 > URL: https://issues.apache.org/jira/browse/SOLR-13129 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.0 >Reporter: David Smiley >Priority: Major > Fix For: 8.0 > > Time Spent: 5h 10m > Remaining Estimate: 0h > > Solr 8.0 will have nicer support for nested child documents than its > predecessors. This should be documented in one place in the ref guide (to > the extent that makes sense). Users need to the schema ramifications (incl. > special fields and that some aspects are optional and when), what a nested > document "looks like" (XML, JSON, SolrJ), how to use the child doc > transformer, how to use block join queries, and get some overview of how this > all works. Maybe mention some plausible future enhancements / direction this > is going in (e.g. path query language?). Some of this is already done but > it's in various places and could be moved. Unlike other features which > conveniently fit into one spot in the documentation (like a query parser), > this is a more complex issue that has multiple aspects – more > "cross-cutting", and so IMO doesn't belong in the current doc pigeon holes. -- 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] [Resolved] (SOLR-13221) Solr Admin Query UI: highlighting parameter checkboxes not functioning
[ https://issues.apache.org/jira/browse/SOLR-13221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-13221. -- Resolution: Duplicate > Solr Admin Query UI: highlighting parameter checkboxes not functioning > -- > > Key: SOLR-13221 > URL: https://issues.apache.org/jira/browse/SOLR-13221 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Erik Hatcher >Priority: Minor > > When using the Solr Admin UI Query "tab", several of the highlighting > checkboxes are not functioning. When hl is checked the checkboxes > hl.requireFieldMatch, hl.usePhraseHighlighter, and hl.highlightMultiTerm do > not set the appropriate request parameters. -- 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] (LUCENE-8667) NPE due to missing input checking in ValueSourceParser
[
https://issues.apache.org/jira/browse/LUCENE-8667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755184#comment-16755184
]
Cassandra Targett commented on LUCENE-8667:
---
FYI, issues can be moved to a different project in the case of mistakes like
these. Since Lucene and Solr are under the same PMC, a comment asking for a
committer to move the issue would be preferred to closing and recreating it.
And easier for you too, I suspect.
> NPE due to missing input checking in ValueSourceParser
> --
>
> Key: LUCENE-8667
> URL: https://issues.apache.org/jira/browse/LUCENE-8667
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Johannes Kloos
>Priority: Minor
> Attachments: home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?q={!frange%20l=10%20u=100}joindf(genre:comedy,$x)
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.lucene.queries.function.valuesource.JoinDocFreqValueSource.hashCode(JoinDocFreqValueSource.java:98)
> at
> org.apache.solr.search.function.ValueSourceRangeFilter.hashCode(ValueSourceRangeFilter.java:139)
> at
> org.apache.solr.search.SolrConstantScoreQuery.hashCode(SolrConstantScoreQuery.java:138)
> at org.apache.solr.search.QueryResultKey.(QueryResultKey.java:46)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1328)
> at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:567)
> at
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1434)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:373)
> [...]
> {noformat}
> As far as I can tell, the bug comes about as follows:
> In org.apache.solr.search.ValueSourceParser, in the addParser(“joindf”, …)
> statement (lines 335-342), we extract the arguments f0 and qf without
> checking if these arguments could not be parsed. The test case produces a
> null pointer for the qfield field in the JoinDocFreqValueSource instance.
> This causes problems in hashcode (as evidenced in this bug), since it expects
> qfield to be non-null.
> Looking at the usages of qfield, it is generally expected to be non-null, so
> it seems we are missing input validation in the parser.
> We found this bug using [Diffblue Microservices
> Testing|https://www.diffblue.com/labs/]. Find more information on this [fuzz
> testing
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results].
--
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] (LUCENE-8604) Add TestRuleLimitSysouts tests, do some cleanup and add hard limit
[ https://issues.apache.org/jira/browse/LUCENE-8604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated LUCENE-8604: -- Fix Version/s: 8.0 > Add TestRuleLimitSysouts tests, do some cleanup and add hard limit > -- > > Key: LUCENE-8604 > URL: https://issues.apache.org/jira/browse/LUCENE-8604 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: 8.0, 7.7 > > Time Spent: 10m > Remaining Estimate: 0h > > PR from github here. > https://github.com/apache/lucene-solr/pull/524 -- 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] (LUCENE-8604) Add TestRuleLimitSysouts tests, do some cleanup and add hard limit
[ https://issues.apache.org/jira/browse/LUCENE-8604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746896#comment-16746896 ] Cassandra Targett commented on LUCENE-8604: --- Added 8.0 to the fixVersion since it doesn't look like this was backported to branch_7x (or maybe it was and the commit didn't show up here). > Add TestRuleLimitSysouts tests, do some cleanup and add hard limit > -- > > Key: LUCENE-8604 > URL: https://issues.apache.org/jira/browse/LUCENE-8604 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: 8.0, 7.7 > > Time Spent: 10m > Remaining Estimate: 0h > > PR from github here. > https://github.com/apache/lucene-solr/pull/524 -- 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-10963) Sample model json format for MultipleAdditiveTreesModel is incorrect
[
https://issues.apache.org/jira/browse/SOLR-10963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-10963:
-
Fix Version/s: (was: 6.7)
> Sample model json format for MultipleAdditiveTreesModel is incorrect
>
>
> Key: SOLR-10963
> URL: https://issues.apache.org/jira/browse/SOLR-10963
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Affects Versions: 6.4, 6.4.1, 6.4.2, 6.5, 6.5.1, 6.6
>Reporter: Stefan Langenmaier
>Assignee: Christine Poerschke
>Priority: Major
> Fix For: 7.0
>
> Attachments: SOLR10963-fix-documentation-for-json-format.patch
>
>
> When I try to use the example json file in the javadoc of
> MultipleAdditiveTreesModel.java I receive the following error:
> {{org.apache.solr.ltr.model.ModelException: Model type does not exist
> org.apache.solr.ltr.model.MultipleAdditiveTreesModel}}
> The sample model from the
> [documentation|https://lucene.apache.org/solr/guide/6_6/learning-to-rank.html#LearningToRank-Examples]
> is working. The difference seems to be the quoted numbers. I can confirm
> that once quoted I no longer have the problem and the setter methods all
> expect Strings.
> It's a little bit confusing as this error message does not really pin down
> the root of the problem.
--
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-13145) Provide better error when ref guide deps are not installed
[
https://issues.apache.org/jira/browse/SOLR-13145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746445#comment-16746445
]
Cassandra Targett commented on SOLR-13145:
--
+1 for the simple change in the patch.
bq. What if the ant build inside solr-ref-guide did a check for all gems and
versions as the very first task?
Great idea, but would require a bit more surgery. IMO, let's not hold up a
simple fail-on-error for something more complex unless Gus or you or someone
else has time to implement it relatively soon. Failure when the biggest thing
you need is missing is a positive incremental improvement.
> Provide better error when ref guide deps are not installed
> --
>
> Key: SOLR-13145
> URL: https://issues.apache.org/jira/browse/SOLR-13145
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: 8.0
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Trivial
> Attachments: SOLR-13145.patch
>
>
> Recently I tried to build the ref guide only to find I didn't have the deps
> installed on that particular machine (mostly I do solr dev on my desktop
> cause it's faster). The error I got was unenlightening:
> {code:java}
> build-site:
> [java] Exception in thread "main" java.lang.NullPointerException
> [java] at CheckLinksAndAnchors.main(CheckLinksAndAnchors.java:156)
> BUILD FAILED
> {code}
> This happens because CheckLinksAndAnchors.main() is trying to list the files
> in the directory into which Jeckyll didn't put the html and getting null.
> I think the problem here is that we let the build continue when Jeckyll
> failed. Attaching patch to fail out when Jeckyll is not found with this
> message:
> {code:java}
> -build-site:
> [echo] Running Jekyll...
> [exec] rbenv: jekyll: command not found
> BUILD FAILED
> /Users/gus/projects/solr/lucene-solr/solr/solr-ref-guide/build.xml:299: exec
> returned: 127
> {code}
> That at least will point the dev in the right direction, since clearly
> something required is not found.
--
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-13144) Reference guide section on IndexUpgraderTool needs to be updated
[ https://issues.apache.org/jira/browse/SOLR-13144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745359#comment-16745359 ] Cassandra Targett commented on SOLR-13144: -- Please also see SOLR-12281. Updating a single page is only be a part of the overall story that needs to be described in detail in at least a couple places of the Guide (page for upgrading to 8.0, etc.) > Reference guide section on IndexUpgraderTool needs to be updated > > > Key: SOLR-13144 > URL: https://issues.apache.org/jira/browse/SOLR-13144 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-13144.patch > > > The section on IndexUpgrader Tool (and I'll remove the space too) leads to > the conclusion that you can successfully upgrade an index X->X+1->X+2 which > isn't true. I'll attach a proposed doc change in a minute. > I'm thinking of only putting this in master and 8x on the theory that AFAIK, > the enforcement of this restriction is only 8x and later. > This is doc-only, if no objections I'll commit this weekend at the latest. -- 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] [Resolved] (SOLR-12424) Search trigger does not accept handler
[
https://issues.apache.org/jira/browse/SOLR-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett resolved SOLR-12424.
--
Resolution: Fixed
Fix Version/s: 7.4
The documentation was updated for 7.4, so I think this was just a docs mistake.
> Search trigger does not accept handler
> --
>
> Key: SOLR-12424
> URL: https://issues.apache.org/jira/browse/SOLR-12424
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: Varun Thacker
>Priority: Major
> Fix For: 7.4
>
>
> This ref guide page (
> [http://lucene.apache.org/solr/guide/7_3/solrcloud-autoscaling-triggers.html#search-rate-trigger]
> ) provides an example JSON for a search trigger.
> If I post that on master I get the following error
> {code:java}
> ERROR - 2018-05-30 02:29:54.837; [ ]
> org.apache.solr.handler.RequestHandlerBase;
> org.apache.solr.api.ApiBag$ExceptionWithErrObject: Error in command payload,
> errors: [{set-trigger={name=search_rate_trigger, event=searchRate,
> collection=test, handler=/select, rate=100.0, waitFor=1m, enabled=true,
> actions=[{name=compute_plan, class=solr.ComputePlanAction},
> {name=execute_plan, class=solr.ExecutePlanAction}]}, errorMessages=[Error
> validating trigger config search_rate_trigger:
> TriggerValidationException{name=search_rate_trigger,
> details='{handler=unknown property}'}]}],
> at
> org.apache.solr.cloud.autoscaling.AutoScalingHandler.processOps(AutoScalingHandler.java:210)
> at
> org.apache.solr.cloud.autoscaling.AutoScalingHandler.handleRequestBody(AutoScalingHandler.java:148)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:324)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
> ...{code}
> From the JSON payload if I remove the "handler" key it works.
--
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-12815) Implement maxOps limit for IndexSizeTrigger
[
https://issues.apache.org/jira/browse/SOLR-12815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16744644#comment-16744644
]
Cassandra Targett commented on SOLR-12815:
--
[~ab], this appears in CHANGES.txt for 7.6, can it be resolved?
> Implement maxOps limit for IndexSizeTrigger
> ---
>
> Key: SOLR-12815
> URL: https://issues.apache.org/jira/browse/SOLR-12815
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>
> {{IndexSizeTrigger}} can currently generate unlimited number of requested
> operations (such as split shard). Combined with the avalanche effect in
> SOLR-12730 this may cause a massive spike in the cluster load, and some of
> these operations may fail.
> It's probably better to put an arbitrary limit on the maximum number of
> generated ops requested in one trigger event. This will delay some of the
> needed changes (thus leading to thresholds being exceeded to a larger degree)
> but it will increase the likelihood that all operations succeed.
> A similar limit already exists in {{SearchRateTrigger}}.
--
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-12467) allow to change the autoscaling configuration via SolrJ
[ https://issues.apache.org/jira/browse/SOLR-12467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-12467: - Component/s: AutoScaling > allow to change the autoscaling configuration via SolrJ > --- > > Key: SOLR-12467 > URL: https://issues.apache.org/jira/browse/SOLR-12467 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling, SolrJ >Affects Versions: 7.3.1 >Reporter: Hendrik Haddorp >Priority: Minor > > Using SolrJ's CloudSolrClient it is possible to read the autoscaling > configuration: > cloudSolrClient.getZkStateReader().getAutoScalingConfig() > There is however no way to update it. One can only read out the list of life > nodes and then do a call to Solr using the LBHttpSolrClient for example. > Given that the config is stored in ZooKeeper and thus could be written > directly and even when no Solr instance is running this is not optimal. -- 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-12868) Request forwarding for v2 API is broken
[
https://issues.apache.org/jira/browse/SOLR-12868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16744568#comment-16744568
]
Cassandra Targett commented on SOLR-12868:
--
[~noble.paul], here's *another* issue that appears in CHANGES.txt for 7.6 but
isn't marked as resolved. Can it be resolved?
It seems to happen frequently that we find issues that should have been
resolved months ago. Any way you could modify the way you work with issues so
these are resolved closer to the time of your commits, like the rest of us do?
> Request forwarding for v2 API is broken
> ---
>
> Key: SOLR-12868
> URL: https://issues.apache.org/jira/browse/SOLR-12868
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud, v2 API
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.6, 8.0
>
>
> I was working with Noble Paul to investigate test failures seen in SOLR-12806
> where we found this issue. Due to a bug, replicas of a collection weren't
> spread evenly so there were some nodes which did not have any replicas at
> all. In such cases, when a v2 API call hits an empty node, it is not
> forwarded to the right path on the remote node causing test failures.
> e.g. a call to {{/c/collection/_introspect}} is forwarded as
> {{http://127.0.0.1:63326/solr/collection1/_introspect?method=POST&wt=javabin&version=2&command=}}
> and {{/c/collection1/abccdef}} is forwarded as
> {{http://127.0.0.1:63326/solr/collection1/abccdef}}
> In summary, a remote query for v2 API from an empty node is converted to a v1
> style call which may not be a valid path. We should forward v2 API calls
> as-is without changing the paths.
--
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-12977) Autoscaling policy initialisation tries to fetch metrics from dead nodes
[
https://issues.apache.org/jira/browse/SOLR-12977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16744451#comment-16744451
]
Cassandra Targett commented on SOLR-12977:
--
[~noble.paul], This appears in CHANGES.txt for 7.6, so it should be resolved?
> Autoscaling policy initialisation tries to fetch metrics from dead nodes
>
>
> Key: SOLR-12977
> URL: https://issues.apache.org/jira/browse/SOLR-12977
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 7.6, 8.0
>
>
> Autoscaling policy initialisation tries to fetch metrics for each node during
> construction. However, it does not skip the known dead nodes causing a
> timeout to be logged. We should skip such requests entirely.
> {code}
> 20579 WARN (AutoscalingActionExecutor-37-thread-1) []
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 127.0.0.1:63255_solr
> org.apache.solr.client.solrj.SolrServerException: Server refused connection
> at: http://127.0.0.1:63255/solr
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:650)
> ~[java/:?]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[java/:?]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[java/:?]
> at
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1260)
> ~[java/:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[java/:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
> [java/:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:186)
> [java/:?]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getReplicaInfo(SolrClientNodeStateProvider.java:169)
> [java/:?]
> at
> org.apache.solr.client.solrj.cloud.autoscaling.Row.(Row.java:60)
> [java/:?]
> at
> org.apache.solr.client.solrj.cloud.autoscaling.Suggester.getSuggestion(Suggester.java:181)
> [java/:?]
> at
> org.apache.solr.cloud.autoscaling.ComputePlanAction.process(ComputePlanAction.java:114)
> [java/:?]
> at
> org.apache.solr.cloud.autoscaling.ScheduledTriggers.lambda$null$419(ScheduledTriggers.java:308)
> [java/:?]
> {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] [Resolved] (SOLR-12908) Add a default set of cluster preferences
[ https://issues.apache.org/jira/browse/SOLR-12908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-12908. -- Resolution: Not A Problem Marking as Not a Problem. I have some doc changes I will push shortly that will make these defaults more clear in the Ref Guide. > Add a default set of cluster preferences > > > Key: SOLR-12908 > URL: https://issues.apache.org/jira/browse/SOLR-12908 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling >Reporter: Varun Thacker >Priority: Major > > Similar to SOLR-12845 where we want to add a set of default cluster policies, > we should add some default cluster preferences as well > > We should always be trying to minimze cores , maximize freedisk for example. -- 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-12023) Autoscaling policy engine shuffles replicas needlessly and can also suggest nonexistent replicas to be moved
[ https://issues.apache.org/jira/browse/SOLR-12023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16744433#comment-16744433 ] Cassandra Targett commented on SOLR-12023: -- Did the commits here get straightened out? Is this in a release? Can it be resolved again? > Autoscaling policy engine shuffles replicas needlessly and can also suggest > nonexistent replicas to be moved > > > Key: SOLR-12023 > URL: https://issues.apache.org/jira/browse/SOLR-12023 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling, SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Noble Paul >Priority: Major > Fix For: 7.6, 8.0 > > Attachments: SOLR-11066-failing.patch, SOLR-12023.patch > > > A test that I wrote in SOLR-11066 found the following problem: > Cluster: 2 nodes > Collection: 1 shard, 3 replicas, maxShardsPerNode=5 > No autoscaling policy or preference applied > When the trigger runs, the computed plan needlessly shuffles all three > replicas and then proceeds to return suggestions with only numbers as core > names. These cores do not exist. I found that these numbers are generated > internally by the framework as placeholders for moved cores for further > calculations. They should never ever be suggested to the users. -- 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-12806) when strict=false is specified, prioritize node allocation using non strict rules
[
https://issues.apache.org/jira/browse/SOLR-12806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16744426#comment-16744426
]
Cassandra Targett commented on SOLR-12806:
--
[~noble.paul], so is this fixed? It's in 7.6 CHANGES.txt.
> when strict=false is specified, prioritize node allocation using non strict
> rules
> -
>
> Key: SOLR-12806
> URL: https://issues.apache.org/jira/browse/SOLR-12806
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-12806.patch
>
>
> if a rule is specified as
> for instance if a policy rule as follows exists
> {code:java}
> {"replica" : "#ALL", "freedisk" : "<500", "strict" : false}
> {code}
>
> If no no nodes have {{freedisk}} more than 500 GB, Solr ignores this rule
> completely and assign nodes. Ideally it should still prefer a node with
> {{freedisk}} of 450GB compared to a node that has {{freedisk}} of 400GB
--
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-7896) Add a login page for Solr Administrative Interface
[ https://issues.apache.org/jira/browse/SOLR-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16738713#comment-16738713 ] Cassandra Targett commented on SOLR-7896: - I added what I wanted to add to the Overview of the Solr Admin UI page about the login screen. I can never just edit one thing, so while I was there I decided it was a good idea to consolidate the content in the getting-assistance.adoc file into the same Overview page. > Add a login page for Solr Administrative Interface > -- > > Key: SOLR-7896 > URL: https://issues.apache.org/jira/browse/SOLR-7896 > Project: Solr > Issue Type: New Feature > Components: Admin UI, Authentication, security >Affects Versions: 5.2.1 >Reporter: Aaron Greenspan >Assignee: Jan Høydahl >Priority: Major > Labels: authentication, login, password > Fix For: 8.0, 7.7 > > Attachments: SOLR-7896-bugfix-7jan.patch, > SOLR-7896-bugfix-7jan.patch, dispatchfilter-code.png, eventual_auth.png, > login-page.png, login-screen-2.png, logout.png, unknown_scheme.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Now that Solr supports Authentication plugins, the missing piece is to be > allowed access from Admin UI when authentication is enabled. For this we need > * Some plumbing in Admin UI that allows the UI to detect 401 responses and > redirect to login page > * Possibility to have multiple login pages depending on auth method and > redirect to the correct one > * [AngularJS HTTP > interceptors|https://docs.angularjs.org/api/ng/service/$http#interceptors] to > add correct HTTP headers on all requests when user is logged in > This issue should aim to implement some of the plumbing mentioned above, and > make it work with Basic Auth. -- 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-12891) Injection Dangers in Streaming Expressions
[ https://issues.apache.org/jira/browse/SOLR-12891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-12891: - Priority: Minor (was: Blocker) > Injection Dangers in Streaming Expressions > -- > > Key: SOLR-12891 > URL: https://issues.apache.org/jira/browse/SOLR-12891 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Affects Versions: 7.5, 8.0 >Reporter: Gus Heck >Priority: Minor > Labels: security > Attachments: SOLR-12891.patch, SOLR-12891.patch, SOLR-12891.patch, > SOLR12819example.java > > > I just spent some time fiddling with streaming expressions for fun, reading > Erick Erickson's blog > ([https://lucidworks.com/2017/12/06/streaming-expressions-in-solrj/)] and the > example given in the ref guide > ([https://lucene.apache.org/solr/guide/7_5/streaming-expressions.html#streaming-requests-and-responses)] > and it occurred to me that we are recommending string concatenation into an > expression language with the power to harm the server, or other network > services visible from the server. I'm starting this Jira as a security issue > to avoid creating a public impression of insecurity, feel free to undo that > if I have guessed wrong. I haven't developed an exploit example, but it would > go something like this: > # Some portion of an expression is built including user supplied data using > the techniques we're recommending in the ref guide > # Malicious user constructs input data that breaks out of the expression > (SOLR-10894 is relevant here), probably somewhere inside a let() expression > where one could simply define an additional variable taking the value of a > malicious expression... > # update() expression is executed to add/overwrite data, jdbc() makes a JDBC > connection to a database visible to the server, or the malicious expression > executes some very expensive expression for DOS effect. > Technically this is of course the fault of the end user who allowed unchecked > input into programmatic execution, but when I think about how to check the > input I realize that the only way to be sure is to construct for myself a > notion of exactly how the parser behaves and then determine what needs to be > escaped. To do this I need to dig into the expression parser code... > How to escape input is also already unclear as shown by SOLR-10894 > There's another important wrinkle that would easily be missed by someone > trying to construct their own escaping/protection system relating to > parameter substitution as discussed here: SOLR-8458 > I think the solution to this is that SolrJ API should be enhanced to provide > an escaping utility at a minimum and possibly a "prepared expression" similar > to SQL prepared statements and call this issue to attention in the ref guide > once these tools are available... > Additionally, templating features might be a useful addition to help folks > manage large expressions and facilitate re-use of patterns... such templating > should also have this issue in mind when/if they are added. -- 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-12891) Injection Dangers in Streaming Expressions
[ https://issues.apache.org/jira/browse/SOLR-12891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-12891: - Security: Public (was: Private (Security Issue)) Changed issue visibility from private to public. > Injection Dangers in Streaming Expressions > -- > > Key: SOLR-12891 > URL: https://issues.apache.org/jira/browse/SOLR-12891 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Affects Versions: 7.5, 8.0 >Reporter: Gus Heck >Priority: Blocker > Labels: security > Attachments: SOLR-12891.patch, SOLR-12891.patch, SOLR-12891.patch, > SOLR12819example.java > > > I just spent some time fiddling with streaming expressions for fun, reading > Erick Erickson's blog > ([https://lucidworks.com/2017/12/06/streaming-expressions-in-solrj/)] and the > example given in the ref guide > ([https://lucene.apache.org/solr/guide/7_5/streaming-expressions.html#streaming-requests-and-responses)] > and it occurred to me that we are recommending string concatenation into an > expression language with the power to harm the server, or other network > services visible from the server. I'm starting this Jira as a security issue > to avoid creating a public impression of insecurity, feel free to undo that > if I have guessed wrong. I haven't developed an exploit example, but it would > go something like this: > # Some portion of an expression is built including user supplied data using > the techniques we're recommending in the ref guide > # Malicious user constructs input data that breaks out of the expression > (SOLR-10894 is relevant here), probably somewhere inside a let() expression > where one could simply define an additional variable taking the value of a > malicious expression... > # update() expression is executed to add/overwrite data, jdbc() makes a JDBC > connection to a database visible to the server, or the malicious expression > executes some very expensive expression for DOS effect. > Technically this is of course the fault of the end user who allowed unchecked > input into programmatic execution, but when I think about how to check the > input I realize that the only way to be sure is to construct for myself a > notion of exactly how the parser behaves and then determine what needs to be > escaped. To do this I need to dig into the expression parser code... > How to escape input is also already unclear as shown by SOLR-10894 > There's another important wrinkle that would easily be missed by someone > trying to construct their own escaping/protection system relating to > parameter substitution as discussed here: SOLR-8458 > I think the solution to this is that SolrJ API should be enhanced to provide > an escaping utility at a minimum and possibly a "prepared expression" similar > to SQL prepared statements and call this issue to attention in the ref guide > once these tools are available... > Additionally, templating features might be a useful addition to help folks > manage large expressions and facilitate re-use of patterns... such templating > should also have this issue in mind when/if they are added. -- 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-7896) Add a login page for Solr Administrative Interface
[ https://issues.apache.org/jira/browse/SOLR-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16736041#comment-16736041 ] Cassandra Targett commented on SOLR-7896: - Thanks Jan, your additions help for sure, but what I was thinking about was adding some text to the Admin UI docs (someone who isn't sure why they are seeing a login screen may start there when looking for reasons why). Since SOLR-13116 isn't as urgent as I thought it would be, I'll take care of it. > Add a login page for Solr Administrative Interface > -- > > Key: SOLR-7896 > URL: https://issues.apache.org/jira/browse/SOLR-7896 > Project: Solr > Issue Type: New Feature > Components: Admin UI, Authentication, security >Affects Versions: 5.2.1 >Reporter: Aaron Greenspan >Assignee: Jan Høydahl >Priority: Major > Labels: authentication, login, password > Fix For: master (9.0), 7.7 > > Attachments: SOLR-7896-bugfix-7jan.patch, > SOLR-7896-bugfix-7jan.patch, dispatchfilter-code.png, eventual_auth.png, > login-page.png, login-screen-2.png, logout.png, unknown_scheme.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Now that Solr supports Authentication plugins, the missing piece is to be > allowed access from Admin UI when authentication is enabled. For this we need > * Some plumbing in Admin UI that allows the UI to detect 401 responses and > redirect to login page > * Possibility to have multiple login pages depending on auth method and > redirect to the correct one > * [AngularJS HTTP > interceptors|https://docs.angularjs.org/api/ng/service/$http#interceptors] to > add correct HTTP headers on all requests when user is logged in > This issue should aim to implement some of the plumbing mentioned above, and > make it work with Basic Auth. -- 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] [Resolved] (SOLR-13111) CVE-2017-1000190 Threat Level 9 Against Solr v7.6. org.simpleframework : simple-xml : 2.7.1. SimpleXML (latest version 2.7.1) is vulnerable to an XXE vulnerability res
[ https://issues.apache.org/jira/browse/SOLR-13111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-13111. -- Resolution: Invalid The vulnerability reported by the scanner is a false positive. It is not possible to exploit the vulnerability in this dependency in Solr. We have created a page that includes this and several other dependencies that are flagged and explains how they are not true vulnerabilities for Solr: https://wiki.apache.org/solr/SolrSecurity#Solr_and_Vulnerability_Scanning_Tools. I investigated this dependency and added this .jar today since the .jar is only needed during compilation and not runtime. If you had discovered a real vulnerability, the ASF has created guidelines for how to report it, detailed here: https://www.apache.org/security/. Ideally, a report is sent to secur...@apache.org first, but if a JIRA is created first instead, you are encouraged to mark the issue as private so attack vectors are not exposed to the general public before they can be mitigated by the community in the form of patches or new releases. > CVE-2017-1000190 Threat Level 9 Against Solr v7.6. org.simpleframework : > simple-xml : 2.7.1. SimpleXML (latest version 2.7.1) is vulnerable to an XXE > vulnerability resulting SSRF, information disclosure, DoS and so on. > - > > Key: SOLR-13111 > URL: https://issues.apache.org/jira/browse/SOLR-13111 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 > Environment: RedHat Linux. May run from RHEL versions 5, 6 or 7 > but this issue is from Sonatype component scan and should be independent of > Linux platform version. >Reporter: RobertHathaway >Priority: Blocker > > We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of > Solr - 7.6.0 Build, > Using Scanner 1.56.0-01 > Threat Level 9 Against Solr v7.6. org.simpleframework > SimpleXML (latest version 2.7.1) is vulnerable to an XXE vulnerability > resulting SSRF, information disclosure, DoS and so on. > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000190 -- 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] [Resolved] (SOLR-13113) CVE-2018-1000632 Threat Level 7 Against Solr v7.6. dom4j : dom4j : 1.6.1. dom4j version prior to version 2.1.1 contains a CWE-91: XML Injection vulnerability in Class:
[ https://issues.apache.org/jira/browse/SOLR-13113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-13113. -- Resolution: Invalid The vulnerability reported by the scanner is a false positive. It is not possible to exploit the vulnerability in this dependency in Solr. We have created a page that includes this and several other dependencies that are flagged and explains how they are not true vulnerabilities for Solr: https://wiki.apache.org/solr/SolrSecurity#Solr_and_Vulnerability_Scanning_Tools. This .jar is listed there. If you had discovered a real vulnerability, the ASF has created guidelines for how to report it, detailed here: https://www.apache.org/security/. Ideally, a report is sent to secur...@apache.org first, but if a JIRA is created first instead, you are encouraged to mark the issue as private so attack vectors are not exposed to the general public before they can be mitigated by the community in the form of patches or new releases. > CVE-2018-1000632 Threat Level 7 Against Solr v7.6. dom4j : dom4j : 1.6.1. > dom4j version prior to version 2.1.1 contains a CWE-91: XML Injection > vulnerability in Class: Element. Methods: addElement, addAttribute ... > > > Key: SOLR-13113 > URL: https://issues.apache.org/jira/browse/SOLR-13113 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Environment: RedHat Linux. May run from RHEL versions 5, 6 or 7 but > this issue is from Sonatype component scan and should be independent of Linux > platform version. >Reporter: RobertHathaway >Priority: Blocker > > We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of > Solr - 7.6.0 Build, > Using Scanner 1.56.0-01 > Threat Level 7 Against Solr v7.6. dom4j : dom4j : 1.6.1 > dom4j version prior to version 2.1.1 contains a CWE-91: XML Injection > vulnerability in Class: Element. Methods: addElement, addAttribute that can > result in an attacker tampering with XML documents through XML injection. > This attack appear to be exploitable via an attacker specifying attributes or > elements in the XML document. This vulnerability appears to have been fixed > in 2.1.1 or later. > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000632 -- 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] [Resolved] (SOLR-13109) CVE-2015-1832 Threat Level 9 Against Solr v7.6. org.apache.derby : derby : 10.9.1.0. XML external entity (XXE) vulnerability in the SqlXmlUtil code in Apache Derby befo
[ https://issues.apache.org/jira/browse/SOLR-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-13109. -- Resolution: Invalid The vulnerability reported by the scanner is a false positive. It is not possible to exploit the vulnerability in this dependency in Solr. We have created a page that includes this and several other dependencies that are flagged and explains how they are not true vulnerabilities for Solr: https://wiki.apache.org/solr/SolrSecurity#Solr_and_Vulnerability_Scanning_Tools. This .jar is listed there. If you had discovered a real vulnerability, the ASF has created guidelines for how to report it, detailed here: https://www.apache.org/security/. Ideally, a report is sent to secur...@apache.org first, but if a JIRA is created first instead, you are encouraged to mark the issue as private so attack vectors are not exposed to the general public before they can be mitigated by the community in the form of patches or new releases. > CVE-2015-1832 Threat Level 9 Against Solr v7.6. org.apache.derby : derby : > 10.9.1.0. XML external entity (XXE) vulnerability in the SqlXmlUtil code in > Apache Derby before 10.12.1.1, w/o Java Security Manager, ...attackers to > read arbitrary files or DOS > - > > Key: SOLR-13109 > URL: https://issues.apache.org/jira/browse/SOLR-13109 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 > Environment: RedHat Linux. May run from RHEL versions 5, 6 or 7 > but this issue is from Sonatype component scan and should be independent of > Linux platform version. >Reporter: RobertHathaway >Priority: Blocker > > Threat Level 9/Critical from Sonatype Application Composition Report run Of > Solr - 7.6.0, Using Scanner 1.56.0-01. Enterprise security won't allow us to > move past Solr 6.5 unless this is fixed or somehow remediated. Lots of issues > in Solr 7.1 also, may be best to move to latest Solr. > h2. CVE-2015-1832 Detail > h3. Current Description > XML external entity (XXE) vulnerability in the SqlXmlUtil code in Apache > Derby before 10.12.1.1, when a Java Security Manager is not in place, allows > context-dependent attackers to read arbitrary files or cause a denial of > service (resource consumption) via vectors involving XmlVTI and the XML > datatype. > h3. Impact > *CVSS v3.0 Severity and Metrics:* > *Base Score:* [ 9.1 CRITICAL > |https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CVE-2015-1832&vector=AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H] > > *Vector:* AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H ([V3 > legend|https://www.first.org/cvss/specification-document]) > *Impact Score:* 5.2 > *Exploitability Score:* 3.9 > [https://nvd.nist.gov/vuln/detail/CVE-2015-1832] -- 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] [Resolved] (SOLR-13114) CVE-2018-8009 Threat Level 7 Against Solr v7.6. org.apache.hadoop : hadoop-common : 2.7.4. Apache Hadoop 3.1.0, 3.0.0-alpha to 3.0.2, 2.9.0 to 2.9.1, 2.8.0 to 2.8.4, 2
[ https://issues.apache.org/jira/browse/SOLR-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-13114. -- Resolution: Invalid The vulnerability reported by the scanner is a false positive. It is not possible to exploit the vulnerability in this dependency in Solr. We have created a page that includes this and several other dependencies that are flagged and explains how they are not true vulnerabilities for Solr: https://wiki.apache.org/solr/SolrSecurity#Solr_and_Vulnerability_Scanning_Tools. This .jar is listed there. If you had discovered a real vulnerability, the ASF has created guidelines for how to report it, detailed here: https://www.apache.org/security/. Ideally, a report is sent to secur...@apache.org first, but if a JIRA is created first instead, you are encouraged to mark the issue as private so attack vectors are not exposed to the general public before they can be mitigated by the community in the form of patches or new releases. > CVE-2018-8009 Threat Level 7 Against Solr v7.6. org.apache.hadoop : > hadoop-common : 2.7.4. Apache Hadoop 3.1.0, 3.0.0-alpha to 3.0.2, 2.9.0 to > 2.9.1, 2.8.0 to 2.8.4, 2.0.0-alpha to 2.7.6, 0.23.0 to 0.23.11 is exploitable > via the zip slip vulnerability > - > > Key: SOLR-13114 > URL: https://issues.apache.org/jira/browse/SOLR-13114 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 > Environment: RedHat Linux. May run from RHEL versions 5, 6 or 7 but > this issue is from Sonatype component scan and should be independent of Linux > platform version. >Reporter: RobertHathaway >Priority: Blocker > > We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of > Solr - 7.6.0 Build, > Using Scanner 1.56.0-01 > Threat Level 7 Against Solr v7.6. org.apache.hadoop : hadoop-common : 2.7.4 > Apache Hadoop 3.1.0, 3.0.0-alpha to 3.0.2, 2.9.0 to 2.9.1, 2.8.0 to 2.8.4, > 2.0.0-alpha to 2.7.6, 0.23.0 to 0.23.11 is exploitable via the zip slip > vulnerability in places that accept a zip file. > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8009 -- 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] [Resolved] (SOLR-13115) CVE-2012-0881(CVE-2013-4002) Threat Level 7 Against Solr v7.6. xerces : xercesImpl : 2.9.1. Apache Xerces2 Java Parser before 2.12.0 allows remote attackers to cause a
[ https://issues.apache.org/jira/browse/SOLR-13115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-13115. -- Resolution: Invalid The vulnerability reported by the scanner is a false positive. It is not possible to exploit the vulnerability in this dependency in Solr. We have created a page that includes this and several other dependencies that are flagged and explains how they are not true vulnerabilities for Solr: https://wiki.apache.org/solr/SolrSecurity#Solr_and_Vulnerability_Scanning_Tools. This .jar is listed there. If you had discovered a real vulnerability, the ASF has created guidelines for how to report it, detailed here: https://www.apache.org/security/. Ideally, a report is sent to secur...@apache.org first, but if a JIRA is created first instead, you are encouraged to mark the issue as private so attack vectors are not exposed to the general public before they can be mitigated by the community in the form of patches or new releases. > CVE-2012-0881(CVE-2013-4002) Threat Level 7 Against Solr v7.6. xerces : > xercesImpl : 2.9.1. Apache Xerces2 Java Parser before 2.12.0 allows remote > attackers to cause a denial of service (CPU consumption) via a crafted > message to an XML service... > > > Key: SOLR-13115 > URL: https://issues.apache.org/jira/browse/SOLR-13115 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 > Environment: RedHat Linux. May run from RHEL versions 5, 6 or 7 but > this issue is from Sonatype component scan and should be independent of Linux > platform version. >Reporter: RobertHathaway >Priority: Blocker > > We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of > Solr - 7.6.0 Build, > Using Scanner 1.56.0-01 > Threat Level 7 Against Solr v7.6. xerces : xercesImpl : 2.9.1 > Two Issues arising due to Apache Xerces2 Java Parser before 2.12.0. > h2. CVE-2012-0881 > Apache Xerces2 Java Parser before 2.12.0 allows remote attackers to cause a > denial of service (CPU consumption) via a crafted message to an XML service, > which triggers hash table collisions. > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0881 > h2. CVE-2013-4002 > XMLscanner.java in Apache Xerces2 Java Parser before 2.12.0, as used in the > Java Runtime Environment (JRE) in IBM Java 5.0 before 5.0 SR16-FP3, 6 before > 6 SR14, 6.0.1 before 6.0.1 SR6, and 7 before 7 SR5 as well as Oracle Java SE > 7u40 and earlier, Java SE 6u60 and earlier, Java SE 5.0u51 and earlier, > JRockit R28.2.8 and earlier, JRockit R27.7.6 and earlier, Java SE Embedded > 7u40 and earlier, and possibly other products allows remote attackers to > cause a denial of service via vectors related to XML attribute names. > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4002 -- 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
