[jira] [Commented] (SOLR-14669) Solr 8.6 / ZK 3.6.1 / Admin UI - ZK Status Null
[ https://issues.apache.org/jira/browse/SOLR-14669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161795#comment-17161795 ] Jörn Franke commented on SOLR-14669: ah sorry, right it looks similar > Solr 8.6 / ZK 3.6.1 / Admin UI - ZK Status Null > --- > > Key: SOLR-14669 > URL: https://issues.apache.org/jira/browse/SOLR-14669 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI, SolrCloud >Affects Versions: 8.6 >Reporter: Jörn Franke >Priority: Minor > > When opening the Admin UI / ZK Status page it shows just null. Solr 8.6.0 / > ZK 3.6.1. Zk is a 3 node ensemble. > It seems to be cosmetic in the UI - otherwise Solr seems to work fine. > Deleted already browser cache and restarted browser. Issue persists. > In the logfiles I find the following error: > 2020-07-20 16:34:27.853 ERROR (qtp767511741-2227) [ ] > o.a.s.h.RequestHandlerBase java.lang.NumberFormatException: For input string: > "null" > at > java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > at java.base/java.lang.Integer.parseInt(Integer.java:652) > at java.base/java.lang.Integer.parseInt(Integer.java:770) > at > org.apache.solr.handler.admin.ZookeeperStatusHandler.getZkStatus(ZookeeperStatusHandler.java:116) > at > org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:78) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211) > at > org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:839) > at > org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:805) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:558) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:419) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at > org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at org.eclipse.jetty.server.Server.handle(Server.java:505) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) > at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) > at > org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:427) > at > org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:321) > at > org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) > at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) > at > org.eclipse.jetty.util.thread.strat
[jira] [Commented] (SOLR-14669) Solr 8.6 / ZK 3.6.1 / Admin UI - ZK Status Null
[ https://issues.apache.org/jira/browse/SOLR-14669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161793#comment-17161793 ] Jörn Franke commented on SOLR-14669: Not exactly, here it is with ZK 3.6.1 and not 3.5.x maybe they did some update to the status commands > Solr 8.6 / ZK 3.6.1 / Admin UI - ZK Status Null > --- > > Key: SOLR-14669 > URL: https://issues.apache.org/jira/browse/SOLR-14669 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI, SolrCloud >Affects Versions: 8.6 >Reporter: Jörn Franke >Priority: Minor > > When opening the Admin UI / ZK Status page it shows just null. Solr 8.6.0 / > ZK 3.6.1. Zk is a 3 node ensemble. > It seems to be cosmetic in the UI - otherwise Solr seems to work fine. > Deleted already browser cache and restarted browser. Issue persists. > In the logfiles I find the following error: > 2020-07-20 16:34:27.853 ERROR (qtp767511741-2227) [ ] > o.a.s.h.RequestHandlerBase java.lang.NumberFormatException: For input string: > "null" > at > java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > at java.base/java.lang.Integer.parseInt(Integer.java:652) > at java.base/java.lang.Integer.parseInt(Integer.java:770) > at > org.apache.solr.handler.admin.ZookeeperStatusHandler.getZkStatus(ZookeeperStatusHandler.java:116) > at > org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:78) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211) > at > org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:839) > at > org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:805) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:558) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:419) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at > org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at org.eclipse.jetty.server.Server.handle(Server.java:505) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) > at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) > at > org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:427) > at > org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:321) > at > org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) > at org.eclipse.jetty.io.ChannelEndPoint$2.run(Chan
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[ https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161809#comment-17161809 ] ASF subversion and git services commented on LUCENE-9312: - Commit 8ebf2d0b2187d849032747d0102ca5eb57b76f05 in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8ebf2d0 ] LUCENE-9312: Allow builds against arbitrary JVMs (squashed jira/LUCENE-9312) > Allow builds against arbitrary JVMs (even those unsupported by gradle) > -- > > Key: LUCENE-9312 > URL: https://issues.apache.org/jira/browse/LUCENE-9312 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[ https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-9312. - Fix Version/s: master (9.0) Resolution: Fixed > Allow builds against arbitrary JVMs (even those unsupported by gradle) > -- > > Key: LUCENE-9312 > URL: https://issues.apache.org/jira/browse/LUCENE-9312 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[ https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161808#comment-17161808 ] ASF subversion and git services commented on LUCENE-9312: - Commit 8ebf2d0b2187d849032747d0102ca5eb57b76f05 in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8ebf2d0 ] LUCENE-9312: Allow builds against arbitrary JVMs (squashed jira/LUCENE-9312) > Allow builds against arbitrary JVMs (even those unsupported by gradle) > -- > > Key: LUCENE-9312 > URL: https://issues.apache.org/jira/browse/LUCENE-9312 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161815#comment-17161815 ] Dawid Weiss commented on LUCENE-9433: - bq. At this point is it even possible to build Lucene without having the parent directory? No. This is a monolithic gradle build right now (one root). Splitting the build for Solr and Lucene is another topic. bq. Make it a placeholder with a notation about Solr moving to a TLP and fix it up then. We should split the build into separate Solr and Lucene subprojects, eventually, in preparation for Solr TLP. For now I'd just state exactly what actually works in lucene/README.md -- go to parent directory, build with gradlew -p lucene assemble. > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Items that may need to be addressed: > * -Testing with OpenJDK early access releases- > * Mavenizing > * Test speed (?) > * Update any mentions of ant in the ref guide > * Update Confluence, in particular "how to contribute" > * Update Jenkins to not try to run ant anything > * make an eclipse task (netbeans too?) > * various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle > * fix some relative links in javadocs which contain ant module names > * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, > and some in the README.md. This one should probably be its own JIRA since > it'll require quite a bit of verification... -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14435) createNodeSet and createNodeSet.shuffle parameters missing from Collection Restore RefGuide
[
https://issues.apache.org/jira/browse/SOLR-14435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161818#comment-17161818
]
Andras Salamon commented on SOLR-14435:
---
I was checking the 8.5 docs. What's happened with maxShardsPerNode? Oh
SOLR-12847.
Yes, [~epugh] that was my suggestion.
> createNodeSet and createNodeSet.shuffle parameters missing from Collection
> Restore RefGuide
> ---
>
> Key: SOLR-14435
> URL: https://issues.apache.org/jira/browse/SOLR-14435
> Project: Solr
> Issue Type: Improvement
> Components: documentation
>Reporter: Andras Salamon
>Assignee: David Eric Pugh
>Priority: Minor
> Attachments: SOLR-14435-01.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Although {{createNodeSet}} and {{createNodeSet.shuffle}} parameters are
> supported by the Collection RESTORE command (I've tested it), they are
> missing from the documentation:
> [https://lucene.apache.org/solr/guide/8_5/collection-management.html#collection-management]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9438) Add gradle workflow support for Eclipse IDE
Dawid Weiss created LUCENE-9438: --- Summary: Add gradle workflow support for Eclipse IDE Key: LUCENE-9438 URL: https://issues.apache.org/jira/browse/LUCENE-9438 Project: Lucene - Core Issue Type: Sub-task Reporter: Dawid Weiss Assignee: Dawid Weiss -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9438) Add gradle workflow support for Eclipse IDE
[ https://issues.apache.org/jira/browse/LUCENE-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-9438: Attachment: capture-1.png > Add gradle workflow support for Eclipse IDE > --- > > Key: LUCENE-9438 > URL: https://issues.apache.org/jira/browse/LUCENE-9438 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Attachments: capture-1.png > > > Off the top of my head I've tried using the eclipse plugin (this should > prepare "static" classpath entries pointing at local gradle caches). It > almost works... almost because we have references between sub-atomic project > elements (tests and main) that make Eclipse see these as circular (because > Eclipse treats project sources and main classes as one). > I pushed this code to jira/LUCENE-9438. Perhaps there are ways of making it > work. I'm not a big fan of having a single "blob" project with all the > sources and classpaths combined (the IDE won't help you figure out what's > accessible from a given subproject then) but maybe it's the only way to make > it work for Eclipse, don't know. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9438) Add gradle workflow support for Eclipse IDE
[ https://issues.apache.org/jira/browse/LUCENE-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-9438: Description: Off the top of my head I've tried using the eclipse plugin (this should prepare "static" classpath entries pointing at local gradle caches). It almost works... almost because we have references between sub-atomic project elements (tests and main) that make Eclipse see these as circular (because Eclipse treats project sources and main classes as one). I pushed this code to jira/LUCENE-9438. Perhaps there are ways of making it work. I'm not a big fan of having a single "blob" project with all the sources and classpaths combined (the IDE won't help you figure out what's accessible from a given subproject then) but maybe it's the only way to make it work for Eclipse, don't know. > Add gradle workflow support for Eclipse IDE > --- > > Key: LUCENE-9438 > URL: https://issues.apache.org/jira/browse/LUCENE-9438 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Attachments: capture-1.png > > > Off the top of my head I've tried using the eclipse plugin (this should > prepare "static" classpath entries pointing at local gradle caches). It > almost works... almost because we have references between sub-atomic project > elements (tests and main) that make Eclipse see these as circular (because > Eclipse treats project sources and main classes as one). > I pushed this code to jira/LUCENE-9438. Perhaps there are ways of making it > work. I'm not a big fan of having a single "blob" project with all the > sources and classpaths combined (the IDE won't help you figure out what's > accessible from a given subproject then) but maybe it's the only way to make > it work for Eclipse, don't know. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
murblanc commented on a change in pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#discussion_r457925818
##
File path: solr/core/src/java/org/apache/solr/cloud/gumi/Replica.java
##
@@ -0,0 +1,34 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+/**
+ * An instantiation (or one of the copies) of a given {@link Shard} of a given
{@link SolrCollection}.
+ * Objects of this type are returned by the Solr framework to the plugin, they
are not built by the plugin. When the
+ * plugin wants to add a replica it goes through {@link
WorkOrderFactory#createWorkOrderCreateReplica}).
+ * TODO is there an elegant way to have this type also used by the plugin to
add replicas? (insisting on elegant)
+ */
+public interface Replica {
Review comment:
Couple reasons not to use `org.apache.solr.common.cloud.Replica`:
The abstraction level there is "weak". For example from a replica getting a
shard returns a String with Shard name. The plugin can't do much with a String.
We'd have to provide the plugin with a way to convert that String into data,
adding complexity. It's easier to have a real object (interface) that can be
used right away (in our case to get the index of the shard in the collection,
possibly other data will be added as other use cases are inventoried).
There are or might be things in this class (it's not even an interface) that
the plugin doesn't need and shouldn't know about. No reason to expose those.
Also, exposing an internal implementation class to external plugin code
(code the community will not necessarily have access to) forces not to change
that internal class to not risk breaking the external plugins. This might be a
problem, it limits refactoring. By having an insulation layer (Adapter/Wrapper
pattern) we can refactor `org.apache.solr.common.cloud.Replica` as much as we
want, and will adapt the (internal) implementation provided for
`org.apache.solr.cloud.gumi.Replica` so client plugin code is not impacted.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
murblanc commented on a change in pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#discussion_r457929742
##
File path: solr/core/src/java/org/apache/solr/cloud/gumi/SolrCollection.java
##
@@ -0,0 +1,35 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+import java.util.Set;
+
+/**
+ * Represents a Collection in SolrCloud. Although naming this class
"Collection" is possible it would be confusing.
+ */
+public interface SolrCollection {
Review comment:
Same as above for `Replica`, here the class is even more complex.
For example we've been having discussions on getting rid of the term "Slice"
and standardizing on "Shard". If we expose `DocCollection` in its current
state, `Slice` can't be renamed.
Also, if we want to build a simulation framework later for plugin
developers, that layer will have a clean and easy interface to build on, since
that's all the plugins are seeing. Building it will not require reaching into
Solr code in various places and add hooks for the simulator. And removing it
will be a lot easier as well :)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
murblanc commented on a change in pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#discussion_r457931798
##
File path: solr/core/src/java/org/apache/solr/cloud/gumi/ReplicaType.java
##
@@ -0,0 +1,25 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+/**
+ * TODO: move into {@link Replica}?
+ */
+public enum ReplicaType {
Review comment:
I didn't want to expose `Replica` as stated above and I therefore can't
use `Replica.Type`.
If `Type` were in its own Java file and a pure enum, reuse would have been
possible. But even then, not sure it would have been a good idea: an internal
replica type might eventually include things we don't want a plugin to be able
to manipulate.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
murblanc commented on a change in pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#discussion_r457933563
##
File path:
solr/core/src/java/org/apache/solr/cloud/gumi/CreateCollectionRequest.java
##
@@ -0,0 +1,35 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+/**
+ * Request for creating a new collection with a given number of shards and
replication factor for various replica types.
+ *
+ * Note there is no need at this stage to allow the request to convey each
shard hash range for example, this can be handled
+ * by the Solr side implementation without needing the plugin to worry about
it.
+ *
+ */
+public interface CreateCollectionRequest extends Request {
+ String getCollectionName();
+
+ int getShardCount();
+
+ int getNRTReplicationFactor();
Review comment:
Not sure we need the count here. This is a creation request for a new
collection, not a representation of the cluster state.
If you look at the
`[Shard](https://github.com/apache/lucene-solr/pull/1684/files#diff-9633f5e169fa3095062451599daac213)`
class, that's where cluster state is passed to the plugin and there we do have
access to the replicas.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
murblanc commented on a change in pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#discussion_r457933563
##
File path:
solr/core/src/java/org/apache/solr/cloud/gumi/CreateCollectionRequest.java
##
@@ -0,0 +1,35 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+/**
+ * Request for creating a new collection with a given number of shards and
replication factor for various replica types.
+ *
+ * Note there is no need at this stage to allow the request to convey each
shard hash range for example, this can be handled
+ * by the Solr side implementation without needing the plugin to worry about
it.
+ *
+ */
+public interface CreateCollectionRequest extends Request {
+ String getCollectionName();
+
+ int getShardCount();
+
+ int getNRTReplicationFactor();
Review comment:
Not sure we need the count here. This is a creation request for a new
collection, not a representation of the cluster state.
If you look at the
[Shard](https://github.com/apache/lucene-solr/pull/1684/files#diff-9633f5e169fa3095062451599daac213)
class, that's where cluster state is passed to the plugin and there we do have
access to the replicas.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
murblanc commented on a change in pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#discussion_r457937538
##
File path: solr/core/src/java/org/apache/solr/cloud/gumi/SolrCollection.java
##
@@ -0,0 +1,35 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+import java.util.Set;
+
+/**
+ * Represents a Collection in SolrCloud. Although naming this class
"Collection" is possible it would be confusing.
+ */
+public interface SolrCollection {
Review comment:
BTW the two sample plugins
([SamplePluginMinimizeCores](https://github.com/apache/lucene-solr/pull/1684/files#diff-ddbe185b5e7922b91b90dfabfc50df4c)
and
[SamplePluginRandomPlacement](https://github.com/apache/lucene-solr/pull/1684/files#diff-a707d47e9a1c89551d455e2ad167f5a5))
show how the interfaces are used.
If we wanted to use existing classes instead of some of the interfaces in
the proposal (even though I think it's a bad idea because it will make
refactoring challenging), we can easily play with the various interfaces and
see what it means and how the plugin code evolves.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14671) NumberFormatException when acessing ZK Status page in 8.6.0
Henrik created SOLR-14671:
-
Summary: NumberFormatException when acessing ZK Status page in
8.6.0
Key: SOLR-14671
URL: https://issues.apache.org/jira/browse/SOLR-14671
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Admin UI, SolrCloud
Affects Versions: 8.6
Reporter: Henrik
The Admin -> Cloud -> ZK Status page in Solr 8.6.0 does not show any data
except for the error message "null". I get the following exception in solr.log:
{code:java}
ERROR [20200721T080439,063] qtp478489615-24
org.apache.solr.servlet.HttpSolrCall - null:java.lang.NumberFormatException:
null
at java.base/java.lang.Integer.parseInt(Integer.java:620)
at java.base/java.lang.Integer.parseInt(Integer.java:776)
at
org.apache.solr.common.cloud.ZkDynamicConfig$Server.parseLine(ZkDynamicConfig.java:142)
at
org.apache.solr.common.cloud.ZkDynamicConfig.lambda$parseLines$0(ZkDynamicConfig.java:58)
at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
at
java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at
java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
at
org.apache.solr.common.cloud.ZkDynamicConfig.parseLines(ZkDynamicConfig.java:53)
at
org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
at
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:500)
at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
at
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
at
org.
[jira] [Commented] (LUCENE-9437) Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible
[
https://issues.apache.org/jira/browse/LUCENE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161885#comment-17161885
]
Michael McCandless commented on LUCENE-9437:
Thanks [~goankur]. I think it makes sense to make {{decode}} public.
Thank you for improving the javadoc too.
Instead of saying {{Change the visibility to 'public'...}} can you just say
{{This method is public ...}}? I.e., future Lucene users reading this javadoc
are not particularly concerned that we had at some point changed it to public,
but rather that it *is* now public.
> Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly
> accessible
> -
>
> Key: LUCENE-9437
> URL: https://issues.apache.org/jira/browse/LUCENE-9437
> Project: Lucene - Core
> Issue Type: Improvement
>Affects Versions: 8.6
>Reporter: Ankur
>Priority: Trivial
> Attachments: LUCENE-9437.patch
>
>
> Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is
> set to 'protected'. This prevents the method from being used outside this
> class in a setting where BinaryDocValues reader is instantiated outside the
> class and binary payload containing ordinals still needs to be decoded.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14671) NumberFormatException when acessing ZK Status page in 8.6.0
[
https://issues.apache.org/jira/browse/SOLR-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik updated SOLR-14671:
--
Description:
The Admin -> Cloud -> ZK Status page in Solr 8.6.0 does not show any data
except for the error message "null". I get the following exception in solr.log:
{code:java}
ERROR [20200721T081301,835] qtp478489615-21
org.apache.solr.handler.RequestHandlerBase - java.lang.NumberFormatException:
null
at java.base/java.lang.Integer.parseInt(Integer.java:620)
at java.base/java.lang.Integer.parseInt(Integer.java:776)
at
org.apache.solr.common.cloud.ZkDynamicConfig$Server.parseLine(ZkDynamicConfig.java:142)
at
org.apache.solr.common.cloud.ZkDynamicConfig.lambda$parseLines$0(ZkDynamicConfig.java:58)
at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
at
java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at
java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
at
org.apache.solr.common.cloud.ZkDynamicConfig.parseLines(ZkDynamicConfig.java:53)
at
org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
at
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:500)
at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
at
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at java.base/java.lang.Thread.run(Thread.java:830)
ERROR [20200721T081301,836] qtp47
[jira] [Commented] (LUCENE-9438) Add gradle workflow support for Eclipse IDE
[
https://issues.apache.org/jira/browse/LUCENE-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161932#comment-17161932
]
Robert Muir commented on LUCENE-9438:
-
The single "blob" project isnt a fanboy thing, I don't think anyone "likes" it:
it is just a practical thing so that this IDE really works and doesn't choke
all the time. As Uwe Schindler mentioned, it is a hack, but it works. A big
important thing is keeping the eclipse memory reasonable so you can actually
use it and it doesn't OOM. Because when it crashes you tend to lose work, which
is really frustrating.
Even with just a single blob project and keeping things minimal, you constantly
have to be your own "garbage collector" and be sure to not have too many
projects open at once. I always make sure to close unused ones, otherwise it
slows down too much and I know it will only crash and cause lost work.
Personally, I use it the same way as Uwe does: as a fancy autocomplete editor
(because java is an extremely verbose language). For any other programming
language I really just use vim, but for java it is just too painful to e.g.
type in every {{import}} statement manually or rename things :) Running build
and tests, git operations, etc: I do all this stuff from the commandline. From
Uwe's comments, I think he uses a similar strategy.
> Add gradle workflow support for Eclipse IDE
> ---
>
> Key: LUCENE-9438
> URL: https://issues.apache.org/jira/browse/LUCENE-9438
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
> Attachments: capture-1.png
>
>
> Off the top of my head I've tried using the eclipse plugin (this should
> prepare "static" classpath entries pointing at local gradle caches). It
> almost works... almost because we have references between sub-atomic project
> elements (tests and main) that make Eclipse see these as circular (because
> Eclipse treats project sources and main classes as one).
> I pushed this code to jira/LUCENE-9438. Perhaps there are ways of making it
> work. I'm not a big fan of having a single "blob" project with all the
> sources and classpaths combined (the IDE won't help you figure out what's
> accessible from a given subproject then) but maybe it's the only way to make
> it work for Eclipse, don't know.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9438) Add gradle workflow support for Eclipse IDE
[ https://issues.apache.org/jira/browse/LUCENE-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161940#comment-17161940 ] Dawid Weiss commented on LUCENE-9438: - That was my point: autocomplete in such a setup doesn't really work as it'll suggest things that shouldn't be visible on a given subproject's classpath. Also, I know Eclipse can be a pain with multi-project workspaces - this was one of the key reasons I moved from Eclipse to IntelliJ, actually. > Add gradle workflow support for Eclipse IDE > --- > > Key: LUCENE-9438 > URL: https://issues.apache.org/jira/browse/LUCENE-9438 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Attachments: capture-1.png > > > Off the top of my head I've tried using the eclipse plugin (this should > prepare "static" classpath entries pointing at local gradle caches). It > almost works... almost because we have references between sub-atomic project > elements (tests and main) that make Eclipse see these as circular (because > Eclipse treats project sources and main classes as one). > I pushed this code to jira/LUCENE-9438. Perhaps there are ways of making it > work. I'm not a big fan of having a single "blob" project with all the > sources and classpaths combined (the IDE won't help you figure out what's > accessible from a given subproject then) but maybe it's the only way to make > it work for Eclipse, don't know. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9438) Add gradle workflow support for Eclipse IDE
[ https://issues.apache.org/jira/browse/LUCENE-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161947#comment-17161947 ] Robert Muir commented on LUCENE-9438: - gradle cant solve these issues though... and intellij isnt an option for me. no offense but i have been thru this battle over and over with maven, gradle before. and each time they think that their build tool will fix it but they dont understand it is just .project and .classpath and stuff and their new fancy build tool is not relevant. i will try to set aside some time to make an eclipse target here. > Add gradle workflow support for Eclipse IDE > --- > > Key: LUCENE-9438 > URL: https://issues.apache.org/jira/browse/LUCENE-9438 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Attachments: capture-1.png > > > Off the top of my head I've tried using the eclipse plugin (this should > prepare "static" classpath entries pointing at local gradle caches). It > almost works... almost because we have references between sub-atomic project > elements (tests and main) that make Eclipse see these as circular (because > Eclipse treats project sources and main classes as one). > I pushed this code to jira/LUCENE-9438. Perhaps there are ways of making it > work. I'm not a big fan of having a single "blob" project with all the > sources and classpaths combined (the IDE won't help you figure out what's > accessible from a given subproject then) but maybe it's the only way to make > it work for Eclipse, don't know. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9438) Add gradle workflow support for Eclipse IDE
[
https://issues.apache.org/jira/browse/LUCENE-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161963#comment-17161963
]
Dawid Weiss commented on LUCENE-9438:
-
I really am IDE-agnostic, I don't care. I use what works, including vi.
Generating global .classpath should be relatively easy; snippets that may be
helpful here:
Collect sourcesets from all java projects:
{code}
if (project.plugins.findPlugin(JavaPlugin)) {
[
project.sourceSets.main.java.srcDirs,
project.sourceSets.test.java.srcDirs,
].flatten().each { srcLocation ->
{code}
Source folders should have per-location outputs (in case the same class is
duplicated in multiple source locations).
To collect (resolved) dependencies - there are bits and pieces in
jar-checks.gradle that should be relevant.
After that it's about deduping and generating .classpath; maybe manually
filtering some stuff.
Should be doable, but some trial and error is definitely in order.
> Add gradle workflow support for Eclipse IDE
> ---
>
> Key: LUCENE-9438
> URL: https://issues.apache.org/jira/browse/LUCENE-9438
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
> Attachments: capture-1.png
>
>
> Off the top of my head I've tried using the eclipse plugin (this should
> prepare "static" classpath entries pointing at local gradle caches). It
> almost works... almost because we have references between sub-atomic project
> elements (tests and main) that make Eclipse see these as circular (because
> Eclipse treats project sources and main classes as one).
> I pushed this code to jira/LUCENE-9438. Perhaps there are ways of making it
> work. I'm not a big fan of having a single "blob" project with all the
> sources and classpaths combined (the IDE won't help you figure out what's
> accessible from a given subproject then) but maybe it's the only way to make
> it work for Eclipse, don't know.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14669) Solr 8.6 / ZK 3.6.1 / Admin UI - ZK Status Null
[ https://issues.apache.org/jira/browse/SOLR-14669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161986#comment-17161986 ] Erick Erickson commented on SOLR-14669: --- Should have pointed out that I made the link for info. SOLR-14463 claims the problem is fixed in 8.6, but you're reporting it in 8.6 so we have to figure out what's up with that. Any chance you're not really running 8.6? > Solr 8.6 / ZK 3.6.1 / Admin UI - ZK Status Null > --- > > Key: SOLR-14669 > URL: https://issues.apache.org/jira/browse/SOLR-14669 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI, SolrCloud >Affects Versions: 8.6 >Reporter: Jörn Franke >Priority: Minor > > When opening the Admin UI / ZK Status page it shows just null. Solr 8.6.0 / > ZK 3.6.1. Zk is a 3 node ensemble. > It seems to be cosmetic in the UI - otherwise Solr seems to work fine. > Deleted already browser cache and restarted browser. Issue persists. > In the logfiles I find the following error: > 2020-07-20 16:34:27.853 ERROR (qtp767511741-2227) [ ] > o.a.s.h.RequestHandlerBase java.lang.NumberFormatException: For input string: > "null" > at > java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > at java.base/java.lang.Integer.parseInt(Integer.java:652) > at java.base/java.lang.Integer.parseInt(Integer.java:770) > at > org.apache.solr.handler.admin.ZookeeperStatusHandler.getZkStatus(ZookeeperStatusHandler.java:116) > at > org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:78) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211) > at > org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:839) > at > org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:805) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:558) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:419) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at > org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at org.eclipse.jetty.server.Server.handle(Server.java:505) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) > at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) > at > org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:427) > at > org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:321) > at > org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) >
[jira] [Commented] (SOLR-14671) NumberFormatException when acessing ZK Status page in 8.6.0
[
https://issues.apache.org/jira/browse/SOLR-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161987#comment-17161987
]
Erick Erickson commented on SOLR-14671:
---
Not quite the same stack trace though?
> NumberFormatException when acessing ZK Status page in 8.6.0
> ---
>
> Key: SOLR-14671
> URL: https://issues.apache.org/jira/browse/SOLR-14671
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, SolrCloud
>Affects Versions: 8.6
>Reporter: Henrik
>Priority: Major
>
> The Admin -> Cloud -> ZK Status page in Solr 8.6.0 does not show any data
> except for the error message "null". I get the following exception in
> solr.log:
> {code:java}
> ERROR [20200721T081301,835] qtp478489615-21
> org.apache.solr.handler.RequestHandlerBase - java.lang.NumberFormatException:
> null
> at java.base/java.lang.Integer.parseInt(Integer.java:620)
> at java.base/java.lang.Integer.parseInt(Integer.java:776)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig$Server.parseLine(ZkDynamicConfig.java:142)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.lambda$parseLines$0(ZkDynamicConfig.java:58)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.parseLines(ZkDynamicConfig.java:53)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
> org.eclipse.jetty.util.thread.
[jira] [Commented] (SOLR-14671) NumberFormatException when acessing ZK Status page in 8.6.0
[
https://issues.apache.org/jira/browse/SOLR-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161992#comment-17161992
]
Henrik commented on SOLR-14671:
---
We're running zookeeper 3.5.7, maybe the content in /zookeeper/config is
different?
> NumberFormatException when acessing ZK Status page in 8.6.0
> ---
>
> Key: SOLR-14671
> URL: https://issues.apache.org/jira/browse/SOLR-14671
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, SolrCloud
>Affects Versions: 8.6
>Reporter: Henrik
>Priority: Major
>
> The Admin -> Cloud -> ZK Status page in Solr 8.6.0 does not show any data
> except for the error message "null". I get the following exception in
> solr.log:
> {code:java}
> ERROR [20200721T081301,835] qtp478489615-21
> org.apache.solr.handler.RequestHandlerBase - java.lang.NumberFormatException:
> null
> at java.base/java.lang.Integer.parseInt(Integer.java:620)
> at java.base/java.lang.Integer.parseInt(Integer.java:776)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig$Server.parseLine(ZkDynamicConfig.java:142)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.lambda$parseLines$0(ZkDynamicConfig.java:58)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
> at
> org.apache.solr.common.cloud.ZkDynamicConfig.parseLines(ZkDynamicConfig.java:53)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at
>
[jira] [Updated] (SOLR-14671) NumberFormatException when accessing ZK Status page in 8.6.0
[
https://issues.apache.org/jira/browse/SOLR-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik updated SOLR-14671:
--
Description:
The Admin -> Cloud -> ZK Status page in Solr 8.6.0 does not show any data
except for the error message "null". I get the following exception in solr.log:
{code:java}
ERROR [20200721T081301,835] qtp478489615-21
org.apache.solr.handler.RequestHandlerBase - java.lang.NumberFormatException:
null
at java.base/java.lang.Integer.parseInt(Integer.java:620)
at java.base/java.lang.Integer.parseInt(Integer.java:776)
at
org.apache.solr.common.cloud.ZkDynamicConfig$Server.parseLine(ZkDynamicConfig.java:142)
at
org.apache.solr.common.cloud.ZkDynamicConfig.lambda$parseLines$0(ZkDynamicConfig.java:58)
at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
at
java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at
java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
at
org.apache.solr.common.cloud.ZkDynamicConfig.parseLines(ZkDynamicConfig.java:53)
at
org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:83)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
at
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:500)
at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
at
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at java.base/java.lang.Thread.run(Thread.java:830)
ERROR [20200721T081301,836] qtp47
[jira] [Created] (SOLR-14672) Make timeouts configurable for the Streaming Expression SolrClientCache
Joel Bernstein created SOLR-14672: - Summary: Make timeouts configurable for the Streaming Expression SolrClientCache Key: SOLR-14672 URL: https://issues.apache.org/jira/browse/SOLR-14672 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Joel Bernstein Currently the connection timeouts used by the SolrClientCache when creating new clients is hard coded. This ticket will make these settings configurable. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14673) Add command line tool executing Streaming Expressions
Joel Bernstein created SOLR-14673: - Summary: Add command line tool executing Streaming Expressions Key: SOLR-14673 URL: https://issues.apache.org/jira/browse/SOLR-14673 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Reporter: Joel Bernstein This ticket will provide a simple command line tool that will run a Streaming Expression from the command line and return the results as a delimited result set. This will allow Streaming Expressions to be used from the command line to extract data as well as load data into Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14673) Add command line tool for executing Streaming Expressions
[ https://issues.apache.org/jira/browse/SOLR-14673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-14673: -- Summary: Add command line tool for executing Streaming Expressions (was: Add command line tool executing Streaming Expressions) > Add command line tool for executing Streaming Expressions > - > > Key: SOLR-14673 > URL: https://issues.apache.org/jira/browse/SOLR-14673 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Priority: Major > > This ticket will provide a simple command line tool that will run a Streaming > Expression from the command line and return the results as a delimited result > set. This will allow Streaming Expressions to be used from the command line > to extract data as well as load data into Solr. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14673) Add command line tool for executing Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-14673:
--
Description:
This ticket will provide a simple command line tool that will run a Streaming
Expression from the command line and return the results as a delimited result
set. This will allow Streaming Expressions to be used from the command line to
extract data as well as load data into Solr.
Sample syntax:
{code:java}
bin/expr zkhost file {code}
was:
This ticket will provide a simple command line tool that will run a Streaming
Expression from the command line and return the results as a delimited result
set. This will allow Streaming Expressions to be used from the command line to
extract data as well as load data into Solr.
> Add command line tool for executing Streaming Expressions
> -
>
> Key: SOLR-14673
> URL: https://issues.apache.org/jira/browse/SOLR-14673
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Priority: Major
>
> This ticket will provide a simple command line tool that will run a Streaming
> Expression from the command line and return the results as a delimited result
> set. This will allow Streaming Expressions to be used from the command line
> to extract data as well as load data into Solr.
>
>
> Sample syntax:
> {code:java}
> bin/expr zkhost file {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14673) Add command line tool for executing Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-14673:
--
Description:
This ticket will provide a simple command line tool that will run a Streaming
Expression from the command line and return the results as a delimited result
set. This will allow Streaming Expressions to be used from the command line to
extract data as well as load data into Solr.
Sample syntax:
{code:java}
bin/expr zkhost expr_file{code}
was:
This ticket will provide a simple command line tool that will run a Streaming
Expression from the command line and return the results as a delimited result
set. This will allow Streaming Expressions to be used from the command line to
extract data as well as load data into Solr.
Sample syntax:
{code:java}
bin/expr zkhost file {code}
> Add command line tool for executing Streaming Expressions
> -
>
> Key: SOLR-14673
> URL: https://issues.apache.org/jira/browse/SOLR-14673
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Priority: Major
>
> This ticket will provide a simple command line tool that will run a Streaming
> Expression from the command line and return the results as a delimited result
> set. This will allow Streaming Expressions to be used from the command line
> to extract data as well as load data into Solr.
>
>
> Sample syntax:
> {code:java}
> bin/expr zkhost expr_file{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14673) Add command line tool for executing Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-14673:
--
Description:
This ticket will provide a simple command line tool that will run a Streaming
Expression from the command line and return the results as a delimited result
set. This will allow Streaming Expressions to be used from the command line to
extract data as well as load data into Solr.
Sample syntax:
{code:java}
bin/expr collection@zkhost expr_file{code}
was:
This ticket will provide a simple command line tool that will run a Streaming
Expression from the command line and return the results as a delimited result
set. This will allow Streaming Expressions to be used from the command line to
extract data as well as load data into Solr.
Sample syntax:
{code:java}
bin/expr zkhost expr_file{code}
> Add command line tool for executing Streaming Expressions
> -
>
> Key: SOLR-14673
> URL: https://issues.apache.org/jira/browse/SOLR-14673
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Priority: Major
>
> This ticket will provide a simple command line tool that will run a Streaming
> Expression from the command line and return the results as a delimited result
> set. This will allow Streaming Expressions to be used from the command line
> to extract data as well as load data into Solr.
>
>
> Sample syntax:
> {code:java}
> bin/expr collection@zkhost expr_file{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14673) Add command line tool for executing Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-14673:
--
Description:
This ticket will provide a simple command line tool that will run a Streaming
Expression from the command line and return the results as a delimited result
set. This will allow Streaming Expressions to be used from the command line to
extract data as well as load data into Solr.
Sample syntax:
{code:java}
bin/expr zkhost expr_file{code}
This will run the expression in _expr_file_ with access to collections that
reside on the zkhost.
Output will be to standard out as tab delimited tuples.
was:
This ticket will provide a simple command line tool that will run a Streaming
Expression from the command line and return the results as a delimited result
set. This will allow Streaming Expressions to be used from the command line to
extract data as well as load data into Solr.
Sample syntax:
{code:java}
bin/expr collection@zkhost expr_file{code}
> Add command line tool for executing Streaming Expressions
> -
>
> Key: SOLR-14673
> URL: https://issues.apache.org/jira/browse/SOLR-14673
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Priority: Major
>
> This ticket will provide a simple command line tool that will run a Streaming
> Expression from the command line and return the results as a delimited result
> set. This will allow Streaming Expressions to be used from the command line
> to extract data as well as load data into Solr.
> Sample syntax:
> {code:java}
> bin/expr zkhost expr_file{code}
> This will run the expression in _expr_file_ with access to collections that
> reside on the zkhost.
> Output will be to standard out as tab delimited tuples.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14673) Add command line tool for executing Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein reassigned SOLR-14673:
-
Assignee: Joel Bernstein
> Add command line tool for executing Streaming Expressions
> -
>
> Key: SOLR-14673
> URL: https://issues.apache.org/jira/browse/SOLR-14673
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
>
> This ticket will provide a simple command line tool that will run a Streaming
> Expression from the command line and return the results as a delimited result
> set. This will allow Streaming Expressions to be used from the command line
> to extract data as well as load data into Solr.
> Sample syntax:
> {code:java}
> bin/expr zkhost expr_file{code}
> This will run the expression in _expr_file_ with access to collections that
> reside on the zkhost.
> Output will be to standard out as tab delimited tuples.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on pull request #1675: SOLR-14652: SolrCore should hold its own CoreDescriptor
madrob commented on pull request #1675: URL: https://github.com/apache/lucene-solr/pull/1675#issuecomment-661866720 Please give me until EOW to review this. Appreciate the patience, thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on pull request #1675: SOLR-14652: SolrCore should hold its own CoreDescriptor
dsmiley commented on pull request #1675: URL: https://github.com/apache/lucene-solr/pull/1675#issuecomment-661869359 > Please give me until EOW to review this. Appreciate the patience, thanks! Sure. You got me just in time :-) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] sigram commented on a change in pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
sigram commented on a change in pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#discussion_r458109976
##
File path: solr/core/src/java/org/apache/solr/cloud/gumi/Replica.java
##
@@ -0,0 +1,34 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+/**
+ * An instantiation (or one of the copies) of a given {@link Shard} of a given
{@link SolrCollection}.
+ * Objects of this type are returned by the Solr framework to the plugin, they
are not built by the plugin. When the
+ * plugin wants to add a replica it goes through {@link
WorkOrderFactory#createWorkOrderCreateReplica}).
+ * TODO is there an elegant way to have this type also used by the plugin to
add replicas? (insisting on elegant)
+ */
+public interface Replica {
+ Shard getShard();
+
+ ReplicaType getType();
Review comment:
We probably need ReplicaState here too, otherwise it will be difficult
to determine when movements are needed.
##
File path: solr/core/src/java/org/apache/solr/cloud/gumi/PropertyKeyFactory.java
##
@@ -0,0 +1,34 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+/**
+ * Factory used by the plugin to create property keys to request property
values from Solr
+ */
+public interface PropertyKeyFactory {
+ /**
+ * Returns a property key allowing to request the number of cores. There are
no parameters for this key.
+ */
+ CoresCountPropertyKey createCoreCountKey();
+
+ /**
+ * Returns a property key allowing to request the value of a system property
(sorry property used twice in two different
+ * contexts). The parameter is the name of the system property to retrieve.
+ */
+ SystemPropertyPropertyKey createSystemPropertyKey(String systemPropertyName);
Review comment:
We also need several node-level metrics, so maybe add a
MetricsPropertyKey?
##
File path:
solr/core/src/java/org/apache/solr/cloud/gumi/CreateCollectionRequest.java
##
@@ -0,0 +1,35 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+/**
+ * Request for creating a new collection with a given number of shards and
replication factor for various replica types.
+ *
+ * Note there is no need at this stage to allow the request to convey each
shard hash range for example, this can be handled
+ * by the Solr side implementation without needing the plugin to worry about
it.
+ *
+ */
+public interface CreateCollectionRequest extends Request {
+ String getCollectionName();
+
+ int getShardCount();
Review comment:
Users must be able to request specific shard names, not j
[GitHub] [lucene-solr] juanka588 commented on a change in pull request #1675: SOLR-14652: SolrCore should hold its own CoreDescriptor
juanka588 commented on a change in pull request #1675:
URL: https://github.com/apache/lucene-solr/pull/1675#discussion_r458117507
##
File path: solr/core/src/java/org/apache/solr/core/CoreContainer.java
##
@@ -1788,6 +1786,7 @@ public void unload(String name, boolean deleteIndexDir,
boolean deleteDataDir, b
}
public void rename(String name, String toName) {
+apiAssumeStandalone();
Review comment:
change java doc reflecting this change
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on pull request #1568: SOLR-14537 Improve performance of ExportWriter
atris commented on pull request #1568: URL: https://github.com/apache/lucene-solr/pull/1568#issuecomment-661903793 @sigram Whats the status of this PR? Is it completed? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14674) NPE when TimeAllowed exceeded with sorting
Daniel Lowe created SOLR-14674:
--
Summary: NPE when TimeAllowed exceeded with sorting
Key: SOLR-14674
URL: https://issues.apache.org/jira/browse/SOLR-14674
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.4.1
Reporter: Daniel Lowe
On Solr 8.4.1 I get a reproducible NPE when doing the type of query below, if
the time allowed is exceeded:
solr/mycollection/select?q=somefield:a*&sort=id asc&timeAllowed=10&fl=score
For the exception to occur the query must be a distributed query (doesn't occur
with distrib=false), a sort parameter must be specified and one of the fields
returned must be score.
{{I found a few other bug reports that might be the same issue:}}
{{[https://lucene.472066.n3.nabble.com/Null-pointer-exception-in-QueryComponent-MergeDds-method-td4460047.html]}}
[https://lucene.472066.n3.nabble.com/NPE-on-exceeding-timeAllowed-on-SOLR-8-1-1-td4453239.html]
The stack trace is:
{{java.lang.NullPointerException}}
{{at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:914)}}
{{at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:613)}}
{{at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:592)}}
{{at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:454)}}
{{at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211)}}
{{at org.apache.solr.core.SolrCore.execute(SolrCore.java:2596)}}
{{at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:799)}}
{{at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:578)}}
{{at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:419)}}
{{at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351)}}
Related to SOLR-7987
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162103#comment-17162103 ] Erick Erickson commented on LUCENE-9433: I updated the lucene/BUILD.md and pushed it to my repo. Didn't add another PR though. > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Items that may need to be addressed: > * -Testing with OpenJDK early access releases- > * Mavenizing > * Test speed (?) > * Update any mentions of ant in the ref guide > * Update Confluence, in particular "how to contribute" > * Update Jenkins to not try to run ant anything > * make an eclipse task (netbeans too?) > * various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle > * fix some relative links in javadocs which contain ant module names > * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, > and some in the README.md. This one should probably be its own JIRA since > it'll require quite a bit of verification... -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] romseygeek commented on pull request #1671: LUCENE-9427: Ensure unified highlighter considers all terms in fuzzy query.
romseygeek commented on pull request #1671: URL: https://github.com/apache/lucene-solr/pull/1671#issuecomment-661926498 Related: https://issues.apache.org/jira/browse/LUCENE-9274 I think ideally the fix would be https://issues.apache.org/jira/browse/LUCENE-9277, but this works as a stopgap. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9432) Use LinkedList instead of manual array re-sizing for better throughput.
[
https://issues.apache.org/jira/browse/LUCENE-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162123#comment-17162123
]
Mohammad Sadiq commented on LUCENE-9432:
Thanks for the guidance [~mikemccand] ! Here are the results of the
{{wikimediumall}} benchmark run 3 times:
On 20th July:
||Task||QPS baseline||StdDev||QPS my_modified_version||StdDev||Pct diff||
|Fuzzy2|32.38|(9.5%)|31.50|(10.6%)|-2.7% ( -20% - 19%)|
|PKLookup|113.09|(2.6%)|110.85|(2.2%)|-2.0% ( -6% - 2%)|
|HighTermDayOfYearSort|24.21|(16.2%)|23.80|(14.5%)|-1.7% ( -27% - 34%)|
|HighTermTitleBDVSort|33.47|(12.4%)|33.02|(11.2%)|-1.4% ( -22% - 25%)|
|BrowseDateTaxoFacets|1.01|(3.8%)|1.00|(3.1%)|-1.2% ( -7% - 5%)|
|BrowseDayOfYearTaxoFacets|1.01|(3.8%)|1.00|(3.2%)|-1.2% ( -7% - 5%)|
|Fuzzy1|43.79|(7.2%)|43.28|(6.7%)|-1.2% ( -14% - 13%)|
|BrowseMonthTaxoFacets|1.17|(4.2%)|1.16|(3.0%)|-1.0% ( -7% - 6%)|
|HighTermMonthSort|34.03|(12.2%)|33.70|(11.3%)|-1.0% ( -21% - 25%)|
|MedPhrase|164.90|(4.3%)|163.77|(3.9%)|-0.7% ( -8% - 7%)|
|Prefix3|90.78|(4.3%)|90.21|(4.1%)|-0.6% ( -8% - 8%)|
|LowSpanNear|5.08|(1.4%)|5.05|(1.4%)|-0.6% ( -3% - 2%)|
|HighSpanNear|9.81|(1.5%)|9.76|(1.5%)|-0.5% ( -3% - 2%)|
|LowPhrase|121.38|(4.6%)|120.86|(4.3%)|-0.4% ( -8% - 8%)|
|OrHighNotHigh|378.12|(5.6%)|376.54|(4.1%)|-0.4% ( -9% - 9%)|
|AndHighHigh|33.12|(4.0%)|33.01|(3.9%)|-0.3% ( -7% - 7%)|
|OrNotHighHigh|417.06|(4.6%)|415.77|(4.5%)|-0.3% ( -9% - 9%)|
|Wildcard|59.69|(6.2%)|59.53|(5.3%)|-0.3% ( -11% - 11%)|
|BrowseDayOfYearSSDVFacets|2.41|(0.7%)|2.40|(0.6%)|-0.2% ( -1% - 1%)|
|HighPhrase|74.80|(5.6%)|74.65|(4.5%)|-0.2% ( -9% - 10%)|
|HighIntervalsOrdered|8.73|(1.0%)|8.71|(1.1%)|-0.2% ( -2% - 1%)|
|OrNotHighMed|389.13|(6.1%)|388.55|(5.4%)|-0.2% ( -10% - 12%)|
|OrHighLow|225.27|(3.6%)|224.94|(4.0%)|-0.1% ( -7% - 7%)|
|LowSloppyPhrase|13.25|(2.6%)|13.23|(2.5%)|-0.1% ( -5% - 5%)|
|AndHighLow|235.49|(3.7%)|235.27|(3.8%)|-0.1% ( -7% - 7%)|
|HighSloppyPhrase|7.09|(3.6%)|7.08|(4.0%)|-0.1% ( -7% - 7%)|
|MedSloppyPhrase|8.58|(2.5%)|8.58|(2.6%)|-0.1% ( -5% - 5%)|
|BrowseMonthSSDVFacets|2.55|(0.6%)|2.54|(0.5%)|-0.1% ( -1% - 1%)|
|HighTerm|713.89|(4.4%)|714.99|(5.3%)|0.2% ( -9% - 10%)|
|IntNRQ|27.04|(1.7%)|27.09|(1.5%)|0.2% ( -2% - 3%)|
|Respell|22.90|(2.4%)|22.94|(2.2%)|0.2% ( -4% - 4%)|
|OrHighMed|24.29|(2.7%)|24.34|(3.0%)|0.2% ( -5% - 6%)|
|OrNotHighLow|396.35|(4.6%)|397.37|(3.8%)|0.3% ( -7% - 9%)|
|OrHighNotLow|406.17|(5.9%)|407.36|(4.8%)|0.3% ( -9% - 11%)|
|MedSpanNear|21.26|(1.9%)|21.33|(1.6%)|0.3% ( -3% - 3%)|
|MedTerm|956.05|(4.7%)|960.04|(6.0%)|0.4% ( -9% - 11%)|
|OrHighHigh|10.11|(2.3%)|10.15|(2.2%)|0.4% ( -4% - 5%)|
|AndHighMed|27.89|(4.2%)|28.01|(4.4%)|0.5% ( -7% - 9%)|
|LowTerm|902.95|(5.2%)|908.51|(5.4%)|0.6% ( -9% - 11%)|
|OrHighNotMed|444.60|(5.1%)|448.71|(5.6%)|0.9% ( -9% - 12%)|
On 21st July (no change in data or packages):
Run #1:
||Task||QPS baseline||StdDev||QPS my_modified_version||StdDev||Pct diff||
|HighTermDayOfYearSort|21.64|(11.8%)|20.86|(10.7%)|-3.6% ( -23% - 21%)|
|HighTermTitleBDVSort|54.94|(10.1%)|54.09|(10.4%)|-1.6% ( -20% - 21%)|
|HighTermMonthSort|46.27|(9.9%)|45.68|(10.0%)|-1.3% ( -19% - 20%)|
|PKLookup|113.80|(2.5%)|112.91|(2.8%)|-0.8% ( -5% - 4%)|
|HighSpanNear|8.57|(2.9%)|8.51|(3.3%)|-0.8% ( -6% - 5%)|
|OrHighLow|139.86|(4.0%)|139.06|(3.9%)|-0.6% ( -8% - 7%)|
|BrowseDayOfYearTaxoFacets|0.99|(2.4%)|0.99|(2.0%)|-0.5% ( -4% - 4%)|
|BrowseDateTaxoFacets|0.99|(2.3%)|0.99|(2.1%)|-0.5% ( -4% - 3%)|
|LowSloppyPhrase|15.72|(2.3%)|15.65|(2.3%)|-0.4% ( -4% - 4%)|
|MedSloppyPhrase|5.16|(4.6%)|5.14|(4.2%)|-0.4% ( -8% - 8%)|
|OrHighMed|50.78|(2.6%)|50.66|(2.9%)|-0.2% ( -5% - 5%)|
|HighPhrase|284.95|(3.5%)|284.33|(3.5%)|-0.2% ( -6% - 7%)|
|BrowseMonthTaxoFacets|1.15|(2.8%)|1.14|(3.5%)|-0.2% ( -6% - 6%)|
|Respell|22.40|(1.9%)|22.37|(2.0%)|-0.1% ( -3% - 3%)|
|LowTerm|1027.92|(4.0%)|1027.07|(3.6%)|-0.1% ( -7% - 7%)|
|BrowseDayOfYearSSDVFacets|2.41|(0.8%)|2.41|(0.8%)|-0.1% ( -1% - 1%)|
|OrHighHigh|13.69|(2.8%)|13.69|(2.6%)|-0.0% ( -5% - 5%)|
|HighSloppyPhrase|4.28|(4.3%)|4.28|(3.9%)|-0.0% ( -7% - 8%)|
|HighIntervalsOrdered|10.23|(1.5%)|10.23|(1.8%)|0.0% ( -3% - 3%)|
|IntNRQ|19.06|(0.9%)|19.07|(1.1%)|0.0% ( -1% - 2%)|
|Prefix3|87.35|(2.3%)|87.40|(2.2%)|0.0% ( -4% - 4%)|
|BrowseMonthSSDVFacets|2.55|(0.5%)|2.55|(0.8%)|0.1% ( -1% - 1%)|
|MedPhrase|228.30|(3.6%)|228.50|(2.8%)|0.1% ( -6% - 6%)|
|OrHighNotMed|543.34|(5.0%)|543.99|(4.3%)|0.1% ( -8% - 9%)|
|LowSpanNear|33.22|(2.3%)|33.28|(2.7%)|0.2% ( -4% - 5%)|
|MedSpanNear|117.67|(2.4%)|117.90|(3.0%)|0.2% ( -5% - 5%)|
|OrNotHighLow|293.14|(3.2%)|294.18|(4.5%)|0.4% ( -7% - 8%)|
|HighTerm|717.73|(3.1%)|720.38|(2.8%)|0.4% ( -5% - 6%)|
|OrNotHighMed|400.65|(4.5%)|402.47|(4.5%)|0.5% ( -8% - 9%)|
|OrHighNotHigh|384.09|(5.3%)|386.13|(3.5%)|0.5% ( -7% - 9%)|
|OrNotHighHigh|403.76|(3.5%)|406.05|(4.0%)|0.6% ( -6% - 8%)|
|Wildcard|48.12|(5.3%)|48.48|(5.2%)|0.7% ( -9% - 11%)|
|AndHighHigh|48.74|(2.6%)|49.11|(3.9%)|0.8% ( -5% - 7%)|
|Low
[jira] [Commented] (LUCENE-9432) Use LinkedList instead of manual array re-sizing for better throughput.
[
https://issues.apache.org/jira/browse/LUCENE-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162130#comment-17162130
]
Mohammad Sadiq commented on LUCENE-9432:
The benchmarks don't indicate a clear improvement. Note that this is with
{{LinkedList}}.
[~uschindler] Thanks for the recommendation of {{ArrayList}}. That was the
first thing I tried :), but in our internal benchmarks, it didn't show any
improvement, whereas {{LinkedList}} did. I'm trying out {{ArrayList}} to see if
there is any improvement in {{wikimediumall}}.
> Use LinkedList instead of manual array re-sizing for better throughput.
> ---
>
> Key: LUCENE-9432
> URL: https://issues.apache.org/jira/browse/LUCENE-9432
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Reporter: Mohammad Sadiq
>Priority: Minor
> Labels: patch-available, performance, pull-request-available
> Attachments: LUCENE-9432.patch
>
>
> I observed that using {{LinkedList}} instead of manually re-sizing and
> copying {{SegmentTermEnumFrame}}s improves red-line QPS. Does it make sense
> to include this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9432) Use LinkedList instead of manual array re-sizing for better throughput.
[
https://issues.apache.org/jira/browse/LUCENE-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162133#comment-17162133
]
Atri Sharma commented on LUCENE-9432:
-
[~mosadiq] Try with a larger data set (wikilarge*) just to make sure.
> Use LinkedList instead of manual array re-sizing for better throughput.
> ---
>
> Key: LUCENE-9432
> URL: https://issues.apache.org/jira/browse/LUCENE-9432
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Reporter: Mohammad Sadiq
>Priority: Minor
> Labels: patch-available, performance, pull-request-available
> Attachments: LUCENE-9432.patch
>
>
> I observed that using {{LinkedList}} instead of manually re-sizing and
> copying {{SegmentTermEnumFrame}}s improves red-line QPS. Does it make sense
> to include this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9432) Use LinkedList instead of manual array re-sizing for better throughput.
[
https://issues.apache.org/jira/browse/LUCENE-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162137#comment-17162137
]
Atri Sharma commented on LUCENE-9432:
-
Also, I like [~uschindler]'s idea of using the Deque interface – it definitely
will improve the readability if nothing else.
> Use LinkedList instead of manual array re-sizing for better throughput.
> ---
>
> Key: LUCENE-9432
> URL: https://issues.apache.org/jira/browse/LUCENE-9432
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Reporter: Mohammad Sadiq
>Priority: Minor
> Labels: patch-available, performance, pull-request-available
> Attachments: LUCENE-9432.patch
>
>
> I observed that using {{LinkedList}} instead of manually re-sizing and
> copying {{SegmentTermEnumFrame}}s improves red-line QPS. Does it make sense
> to include this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9432) Use LinkedList instead of manual array re-sizing for better throughput.
[
https://issues.apache.org/jira/browse/LUCENE-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162146#comment-17162146
]
Uwe Schindler commented on LUCENE-9432:
---
Hi,
the problematic part with linked list is two-kind:
- there is an index-based access to the list. This should be removed and
changed to getLast() or getFirst(), because index-based accesses in LinkedLists
always have a linear scan. If this is not a big slowdown here, it looks like
the list is small and does not grow much. In that case I tend to initialize the
ArrayList with a larger size
- LinkedList has a large object allocation and maintenance overhead (one small
object for every entry), while arrays or ArrayLists are a block, which is also
cache-friendly.
So, two suggestions:
- If LinkedList, then remove index-based access and replace by getLast() or
getFirst() (if possible). If that's not possible its the completely wrong type
of list - sorry. LinkedList also implements Deque, so lets use that interface
as datatype in code! This also prevents us from accidentally using the
index-based access: get(int)
- If we use Deque, we can alternatively use ArrayDeque instead of LinkedList
(it's just a replacement). Here we may think of a good initial size.
Uwe
> Use LinkedList instead of manual array re-sizing for better throughput.
> ---
>
> Key: LUCENE-9432
> URL: https://issues.apache.org/jira/browse/LUCENE-9432
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Reporter: Mohammad Sadiq
>Priority: Minor
> Labels: patch-available, performance, pull-request-available
> Attachments: LUCENE-9432.patch
>
>
> I observed that using {{LinkedList}} instead of manually re-sizing and
> copying {{SegmentTermEnumFrame}}s improves red-line QPS. Does it make sense
> to include this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9432) Use LinkedList instead of manual array re-sizing for better throughput.
[
https://issues.apache.org/jira/browse/LUCENE-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162146#comment-17162146
]
Uwe Schindler edited comment on LUCENE-9432 at 7/21/20, 4:23 PM:
-
Hi,
the problematic part with linked list is two-kind:
- there is an index-based access to the list. This should be removed and
changed to getLast() or getFirst(), because index-based accesses in LinkedLists
always have a linear scan. If this is not a big slowdown here, it looks like
the list is small and does not grow much. In that case I tend to initialize the
ArrayList with a larger size. If we iterate over the list from back-to-front or
front-to-back, you should use iterator, not get(int) using an index (code looks
like it iterates from back to front).
- LinkedList has a large object allocation and maintenance overhead (one small
object for every entry), while arrays or ArrayLists are a block, which is also
cache-friendly.
So, two suggestions:
- If LinkedList, then remove index-based access and replace by getLast() or
getFirst() (if possible). If that's not possible its the completely wrong type
of list - sorry. LinkedList also implements Deque, so lets use that interface
as datatype in code! This also prevents us from accidentally using the
index-based access: get(int)
- If we use Deque, we can alternatively use ArrayDeque instead of LinkedList
(it's just a replacement). Here we may think of a good initial size.
Uwe
was (Author: thetaphi):
Hi,
the problematic part with linked list is two-kind:
- there is an index-based access to the list. This should be removed and
changed to getLast() or getFirst(), because index-based accesses in LinkedLists
always have a linear scan. If this is not a big slowdown here, it looks like
the list is small and does not grow much. In that case I tend to initialize the
ArrayList with a larger size
- LinkedList has a large object allocation and maintenance overhead (one small
object for every entry), while arrays or ArrayLists are a block, which is also
cache-friendly.
So, two suggestions:
- If LinkedList, then remove index-based access and replace by getLast() or
getFirst() (if possible). If that's not possible its the completely wrong type
of list - sorry. LinkedList also implements Deque, so lets use that interface
as datatype in code! This also prevents us from accidentally using the
index-based access: get(int)
- If we use Deque, we can alternatively use ArrayDeque instead of LinkedList
(it's just a replacement). Here we may think of a good initial size.
Uwe
> Use LinkedList instead of manual array re-sizing for better throughput.
> ---
>
> Key: LUCENE-9432
> URL: https://issues.apache.org/jira/browse/LUCENE-9432
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Reporter: Mohammad Sadiq
>Priority: Minor
> Labels: patch-available, performance, pull-request-available
> Attachments: LUCENE-9432.patch
>
>
> I observed that using {{LinkedList}} instead of manually re-sizing and
> copying {{SegmentTermEnumFrame}}s improves red-line QPS. Does it make sense
> to include this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
murblanc commented on a change in pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#discussion_r458233991
##
File path: solr/core/src/java/org/apache/solr/cloud/gumi/PropertyKeyFactory.java
##
@@ -0,0 +1,34 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+/**
+ * Factory used by the plugin to create property keys to request property
values from Solr
+ */
+public interface PropertyKeyFactory {
+ /**
+ * Returns a property key allowing to request the number of cores. There are
no parameters for this key.
+ */
+ CoresCountPropertyKey createCoreCountKey();
+
+ /**
+ * Returns a property key allowing to request the value of a system property
(sorry property used twice in two different
+ * contexts). The parameter is the name of the system property to retrieve.
+ */
+ SystemPropertyPropertyKey createSystemPropertyKey(String systemPropertyName);
Review comment:
Sure, this is just the very initial drop to show the overall approach.
By no means complete! Actually I'll go through all the Collection API commands
as well as the Autoscaling tests to see what was used and needs to be added to
these interfaces.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14675) [SolrJ] Http2SolrClient async request through CloudHttp2SolrClient
Rishi Sankar created SOLR-14675: --- Summary: [SolrJ] Http2SolrClient async request through CloudHttp2SolrClient Key: SOLR-14675 URL: https://issues.apache.org/jira/browse/SOLR-14675 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Components: SolrJ Affects Versions: 8.7 Reporter: Rishi Sankar In Solr 8.7, org.apache.solr.client.solrj.impl.Http2SolrClient has an asyncRequest method which supports making async requests with a callback parameter. However, this method is only used internally by the MockingHttp2SolrClient and LBHttp2SolrClient. I'd like to contribute a method to the CloudHttp2SolrClient that allows for making an asynchronous request with a callback parameter that can be passed down to the Http2SolrClient asyncRequest call. I've been coordinating with [~dsmiley] about making this change. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14675) [SolrJ] Http2SolrClient async request through CloudHttp2SolrClient
[ https://issues.apache.org/jira/browse/SOLR-14675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rishi Sankar updated SOLR-14675: Issue Type: Improvement (was: New Feature) > [SolrJ] Http2SolrClient async request through CloudHttp2SolrClient > -- > > Key: SOLR-14675 > URL: https://issues.apache.org/jira/browse/SOLR-14675 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 8.7 >Reporter: Rishi Sankar >Priority: Minor > > In Solr 8.7, org.apache.solr.client.solrj.impl.Http2SolrClient has an > asyncRequest method which supports making async requests with a callback > parameter. However, this method is only used internally by the > MockingHttp2SolrClient and LBHttp2SolrClient. I'd like to contribute a method > to the CloudHttp2SolrClient that allows for making an asynchronous request > with a callback parameter that can be passed down to the Http2SolrClient > asyncRequest call. > I've been coordinating with [~dsmiley] about making this change. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9432) Use LinkedList instead of manual array re-sizing for better throughput.
[
https://issues.apache.org/jira/browse/LUCENE-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162174#comment-17162174
]
Atri Sharma commented on LUCENE-9432:
-
I think the first step is to rewrite the code with the Deque interface – it is
just more logical and readable. Post that, we can play around with the
underlying implementation (I am in favour of ArrayDeque).
> Use LinkedList instead of manual array re-sizing for better throughput.
> ---
>
> Key: LUCENE-9432
> URL: https://issues.apache.org/jira/browse/LUCENE-9432
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Reporter: Mohammad Sadiq
>Priority: Minor
> Labels: patch-available, performance, pull-request-available
> Attachments: LUCENE-9432.patch
>
>
> I observed that using {{LinkedList}} instead of manually re-sizing and
> copying {{SegmentTermEnumFrame}}s improves red-line QPS. Does it make sense
> to include this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jtibshirani commented on pull request #1671: LUCENE-9427: Ensure unified highlighter considers all terms in fuzzy query.
jtibshirani commented on pull request #1671: URL: https://github.com/apache/lucene-solr/pull/1671#issuecomment-661988556 Thanks @romseygeek for taking a look. What do you see as the next steps? Would it make sense to merge this, and I could look into LUCENE-9277 in a follow-up? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14675) [SolrJ] Http2SolrClient async request through CloudHttp2SolrClient
[ https://issues.apache.org/jira/browse/SOLR-14675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162290#comment-17162290 ] Rishi Sankar commented on SOLR-14675: - cc [~caomanhdat] > [SolrJ] Http2SolrClient async request through CloudHttp2SolrClient > -- > > Key: SOLR-14675 > URL: https://issues.apache.org/jira/browse/SOLR-14675 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 8.7 >Reporter: Rishi Sankar >Priority: Minor > > In Solr 8.7, org.apache.solr.client.solrj.impl.Http2SolrClient has an > asyncRequest method which supports making async requests with a callback > parameter. However, this method is only used internally by the > MockingHttp2SolrClient and LBHttp2SolrClient. I'd like to contribute a method > to the CloudHttp2SolrClient that allows for making an asynchronous request > with a callback parameter that can be passed down to the Http2SolrClient > asyncRequest call. > I've been coordinating with [~dsmiley] about making this change. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris opened a new pull request #1686: SOLR-13528: Implement Request Rate Limiters
atris opened a new pull request #1686: URL: https://github.com/apache/lucene-solr/pull/1686 This commit introduces two functionalities: request rate limiting and ability to identify requests based on type (indexing, search, admin). The default rate limiter rate limits query requests based on configurable parameters which can be set in web.xml. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on a change in pull request #1685: LUCENE-9433: Remove Ant support from trunk
madrob commented on a change in pull request #1685: URL: https://github.com/apache/lucene-solr/pull/1685#discussion_r458346227 ## File path: README.md ## @@ -40,48 +40,31 @@ comprehensive documentation, visit: (You do not need to do this if you downloaded a pre-built package) -### Building with Ant - -Lucene and Solr are built using [Apache Ant](http://ant.apache.org/). To build -Lucene and Solr, run: - -`ant compile` - -If you see an error about Ivy missing while invoking Ant (e.g., `.ant/lib does -not exist`), run `ant ivy-bootstrap` and retry. - -Sometimes you may face issues with Ivy (e.g., an incompletely downloaded artifact). -Cleaning up the Ivy cache and retrying is a workaround for most of such issues: - -`rm -rf ~/.ivy2/cache` - -The Solr server can then be packaged and prepared for startup by running the -following command from the `solr/` directory: - -`ant server` ### Building with Gradle -There is ongoing work (see [LUCENE-9077](https://issues.apache.org/jira/browse/LUCENE-9077)) -to switch the legacy ant-based build system to [gradle](https://gradle.org/). -Please give it a try! - -At the moment of writing, the gradle build requires precisely Java 11 -(it may or may not work with newer Java versions). +As of 9.0, Lucene/Solr uses [Gradle](https://gradle.org/) as the build +system. Installatcion instructions [here](https://gradle.org/install/). +Ant build support has been removed. To build Lucene and Solr, run (`./` can be omitted on Windows): `./gradlew assemble` -The command above also packages a full distribution of Solr server; the + +The command above packages a full distribution of Solr server; the package can be located at: `solr/packaging/build/solr-*` Note that the gradle build does not create or copy binaries throughout the -source repository (like ant build does) so you need to switch to the +source repository (like ant build did) by default so you need to switch to the Review comment: Do we want to remove this reference to ant build too? ## File path: lucene/BUILD.md ## @@ -2,78 +2,72 @@ ## Basic steps: - 0. Install OpenJDK 11 (or greater), Ant 1.8.2+, Ivy 2.2.0 - 1. Download Lucene from Apache and unpack it - 2. Connect to the top-level of your Lucene installation + 0. Install OpenJDK 11 (or greater), Gradle 6.4.1 Review comment: Same question about install. ## File path: README.md ## @@ -40,48 +40,31 @@ comprehensive documentation, visit: (You do not need to do this if you downloaded a pre-built package) -### Building with Ant - -Lucene and Solr are built using [Apache Ant](http://ant.apache.org/). To build -Lucene and Solr, run: - -`ant compile` - -If you see an error about Ivy missing while invoking Ant (e.g., `.ant/lib does -not exist`), run `ant ivy-bootstrap` and retry. - -Sometimes you may face issues with Ivy (e.g., an incompletely downloaded artifact). -Cleaning up the Ivy cache and retrying is a workaround for most of such issues: - -`rm -rf ~/.ivy2/cache` - -The Solr server can then be packaged and prepared for startup by running the -following command from the `solr/` directory: - -`ant server` ### Building with Gradle -There is ongoing work (see [LUCENE-9077](https://issues.apache.org/jira/browse/LUCENE-9077)) -to switch the legacy ant-based build system to [gradle](https://gradle.org/). -Please give it a try! - -At the moment of writing, the gradle build requires precisely Java 11 -(it may or may not work with newer Java versions). +As of 9.0, Lucene/Solr uses [Gradle](https://gradle.org/) as the build +system. Installatcion instructions [here](https://gradle.org/install/). Review comment: s/Installatcion/Installation Do we need to install this at all? I thought we use the wrapper. ## File path: solr/README.md ## @@ -163,30 +163,22 @@ Instructions for Building Apache Solr from Source folder included on your command path. To test this, issue a "java -version" command from your shell (command prompt) and verify that the Java version is 11 or later. -2. Download the Apache Ant binary distribution (1.8.2+) from - http://ant.apache.org/ You will need Ant installed and the $ANT_HOME/bin (Windows: - %ANT_HOME%\bin) folder included on your command path. To test this, issue a - "ant -version" command from your shell (command prompt) and verify that Ant is - available. - - You will also need to install Apache Ivy binary distribution (2.2.0) from - http://ant.apache.org/ivy/ and place ivy-2.2.0.jar file in ~/.ant/lib -- if you skip - this step, the Solr build system will offer to do it for you. +2. Install Gradle, see https://gradle.org/ The current version is 6.4.1. Installation Review comment: Same question ## File path: lucene/BUILD.md ## @@ -2,78 +2,72 @@ ## Basic steps: - 0. Install OpenJDK 11 (or greater), Ant 1.8.2+, Ivy 2.2.0 - 1. Download Lucen
[GitHub] [lucene-solr] atris commented on pull request #1686: SOLR-13528: Implement Request Rate Limiters
atris commented on pull request #1686: URL: https://github.com/apache/lucene-solr/pull/1686#issuecomment-662073876 @anshumg @madrob @sigram @ErickErickson Please take a look This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14649) Package manager should use SHA512, not SHA1
[ https://issues.apache.org/jira/browse/SOLR-14649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-14649: Description: Due to a massive oversight, we only support SHA1 based package signing. We should immediately switch to SHA512. Post that, all existing packages must be re-signed with SHA512. (was: Due to a massive oversight, we only support SHA1 based package signing. We should immediately switch to SHA512. Post that, all existing packages must be re-signed with SHA512. I'll propose this for a 8.6.1 breakfix release.) > Package manager should use SHA512, not SHA1 > --- > > Key: SOLR-14649 > URL: https://issues.apache.org/jira/browse/SOLR-14649 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Major > > Due to a massive oversight, we only support SHA1 based package signing. We > should immediately switch to SHA512. Post that, all existing packages must be > re-signed with SHA512. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14649) Package manager should use SHA512, not SHA1
[ https://issues.apache.org/jira/browse/SOLR-14649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-14649: Priority: Critical (was: Major) > Package manager should use SHA512, not SHA1 > --- > > Key: SOLR-14649 > URL: https://issues.apache.org/jira/browse/SOLR-14649 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Critical > Fix For: 8.7 > > > Due to a massive oversight, we only support SHA1 based package signing. We > should immediately switch to SHA512. Post that, all existing packages must be > re-signed with SHA512. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14649) Package manager should use SHA512, not SHA1
[ https://issues.apache.org/jira/browse/SOLR-14649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-14649: Fix Version/s: 8.7 > Package manager should use SHA512, not SHA1 > --- > > Key: SOLR-14649 > URL: https://issues.apache.org/jira/browse/SOLR-14649 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.7 > > > Due to a massive oversight, we only support SHA1 based package signing. We > should immediately switch to SHA512. Post that, all existing packages must be > re-signed with SHA512. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162394#comment-17162394
]
Mark Robert Miller commented on SOLR-14636:
---
This starts to give an idea of what a serial solr core test run should look
like:
https://www.dropbox.com/s/veutr8k1fuhu6mv/solr-core-serial-test.mp4?dl=0
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> {color:#de350b}NOTE: Just entered a period of likely instability as I clear
> out the new room of zombies.{color}
> *tests***:
> * *core*: {color:#00875a}*solid*{color} with *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*solid*{color} with {color:#de350b}*ignores*{color}
> * *test-framework*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14383) Fix indexing-nested-documents.adoc XML/JSON examples to be accurate, consistent, and clear
[
https://issues.apache.org/jira/browse/SOLR-14383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-14383:
--
Attachment: SOLR-14383.patch
Assignee: Chris M. Hostetter
Status: Open (was: Open)
I've started down the road to completely revamping this page (and the
assocaited sections of other pages that link in/out) with the goal of having a
good consistent example (in both json, xml, and solrj) showing (deeply) nested
docs that have "type" info, and pushing the older style "anonymous" nested docs
out of the main example and into it's own section at the bottom of the page --
i can't think of any practical reason to "showcase" sending hierarchical
documents in both formats _in the same request_.
there are still a lot of nocommits about stuff that needs more cleanup
(notably: the xml/solrj example blocks are just placeholders until i polish up
the query sections to be sure i don't need/want to change the example docs to
make the query examples more interestion) but
I'd appreciate some feedback from folks who have worked on all of this stuff
recently -- ie: [~dsmiley], [~moshebla], [~mkhl] -- as to wether they think
this is moving in the right direction ... before i go too deep down the rabbit
hole.
> Fix indexing-nested-documents.adoc XML/JSON examples to be accurate,
> consistent, and clear
> --
>
> Key: SOLR-14383
> URL: https://issues.apache.org/jira/browse/SOLR-14383
> Project: Solr
> Issue Type: Sub-task
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-14383.patch
>
>
> As reported on solr-user@lucene by Peter Pimley...
> {noformat}
> The page "Indexing Nested Documents" has an XML example showing two
> different ways of adding nested documents:
> https://lucene.apache.org/solr/guide/8_5/indexing-nested-documents.html#xml-examples
> The text says:
> "It illustrates two styles of adding child documents: the first is
> associated via a field "comment" (preferred), and the second is done
> in the classic way now referred to as an "anonymous" or "unlabelled"
> child document."
> However in the XML directly below there is no field named "comment".
> There is one named "content" and another named "comments" (plural),
> but no field named "comment". In fact, looking at the Json example
> immediately below, I wonder if the XML element currently named
> "content" should be named "comments", and what is currently marked
> "comments" should be "content"?
> Secondly, in the Json example it says:
> "The labelled relationship here is one child document but could have
> been wrapped in array brackets."
> However in the actual Json, the parent document (ID=1) with a labelled
> relationship has two child documents (IDs 2 and 3), and they are
> already in array brackets.
> {noformat}
> * The 2 examples (XML and JSON) should be updated to contains *structurally*
> identical content, (ie: same number of documents, with same field values, and
> same hierarchical relationships) to focus on demonstrating the syntax
> differences (ie: things like the special {{\_childDocuments\_}} key in json)
> * The paragraphs describing the examples should be updated to:
> ** refer to the correct field names -- since both "comments" and "contents"
> fields exist in the examples, it's impossible for novice users to even
> udnerstand where th "typo" might be in the descriptions (I'm pretty
> knowledgeable about Solr and even i'm second guessing myself as to what the
> intent in these paragraphs are)
> ** refer to documents by {{"id"}} value, not just descriptors like "first"
> and "second"
> * it might be worth considering rewriting this section to use "callouts":
> https://asciidoctor.org/docs/user-manual/#callouts -- similar to how we use
> them in other sections like this:
> https://lucene.apache.org/solr/guide/8_5/uploading-data-with-index-handlers.html#sending-json-update-commands
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9437) Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible
[ https://issues.apache.org/jira/browse/LUCENE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankur updated LUCENE-9437: -- Attachment: (was: LUCENE-9437.patch) > Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly > accessible > - > > Key: LUCENE-9437 > URL: https://issues.apache.org/jira/browse/LUCENE-9437 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 8.6 >Reporter: Ankur >Priority: Trivial > Attachments: LUCENE-9437.patch > > > Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is > set to 'protected'. This prevents the method from being used outside this > class in a setting where BinaryDocValues reader is instantiated outside the > class and binary payload containing ordinals still needs to be decoded. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9437) Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible
[ https://issues.apache.org/jira/browse/LUCENE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankur updated LUCENE-9437: -- Attachment: LUCENE-9437.patch > Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly > accessible > - > > Key: LUCENE-9437 > URL: https://issues.apache.org/jira/browse/LUCENE-9437 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 8.6 >Reporter: Ankur >Priority: Trivial > Attachments: LUCENE-9437.patch > > > Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is > set to 'protected'. This prevents the method from being used outside this > class in a setting where BinaryDocValues reader is instantiated outside the > class and binary payload containing ordinals still needs to be decoded. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9437) Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible
[ https://issues.apache.org/jira/browse/LUCENE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankur updated LUCENE-9437: -- Status: Open (was: Patch Available) > Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly > accessible > - > > Key: LUCENE-9437 > URL: https://issues.apache.org/jira/browse/LUCENE-9437 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 8.6 >Reporter: Ankur >Priority: Trivial > Attachments: LUCENE-9437.patch > > > Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is > set to 'protected'. This prevents the method from being used outside this > class in a setting where BinaryDocValues reader is instantiated outside the > class and binary payload containing ordinals still needs to be decoded. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9437) Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible
[ https://issues.apache.org/jira/browse/LUCENE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankur updated LUCENE-9437: -- Status: Patch Available (was: Open) > Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly > accessible > - > > Key: LUCENE-9437 > URL: https://issues.apache.org/jira/browse/LUCENE-9437 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 8.6 >Reporter: Ankur >Priority: Trivial > Attachments: LUCENE-9437.patch > > > Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is > set to 'protected'. This prevents the method from being used outside this > class in a setting where BinaryDocValues reader is instantiated outside the > class and binary payload containing ordinals still needs to be decoded. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9437) Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible
[ https://issues.apache.org/jira/browse/LUCENE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162422#comment-17162422 ] Ankur commented on LUCENE-9437: --- Thanks [~mikemccand], I updated the patch fixing javadoc comments as suggested. > Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly > accessible > - > > Key: LUCENE-9437 > URL: https://issues.apache.org/jira/browse/LUCENE-9437 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 8.6 >Reporter: Ankur >Priority: Trivial > Attachments: LUCENE-9437.patch > > > Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is > set to 'protected'. This prevents the method from being used outside this > class in a setting where BinaryDocValues reader is instantiated outside the > class and binary payload containing ordinals still needs to be decoded. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9437) Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible
[
https://issues.apache.org/jira/browse/LUCENE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162506#comment-17162506
]
Lucene/Solr QA commented on LUCENE-9437:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
22s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
13s{color} | {color:red} facet in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 13s{color}
| {color:red} facet in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Release audit (RAT) {color} | {color:red}
0m 13s{color} | {color:red} facet in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Check forbidden APIs {color} | {color:red}
0m 13s{color} | {color:red} facet in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Validate source patterns {color} |
{color:red} 0m 13s{color} | {color:red} facet in the patch failed. {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 4s{color}
| {color:red} facet in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 0m 48s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-9437 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13008123/LUCENE-9437.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-108-generic #109-Ubuntu SMP Fri Jun 19
11:33:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 8ebf2d0b218 |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| compile |
https://builds.apache.org/job/PreCommit-LUCENE-Build/286/artifact/out/patch-compile-lucene_facet.txt
|
| javac |
https://builds.apache.org/job/PreCommit-LUCENE-Build/286/artifact/out/patch-compile-lucene_facet.txt
|
| Release audit (RAT) |
https://builds.apache.org/job/PreCommit-LUCENE-Build/286/artifact/out/patch-compile-lucene_facet.txt
|
| Check forbidden APIs |
https://builds.apache.org/job/PreCommit-LUCENE-Build/286/artifact/out/patch-compile-lucene_facet.txt
|
| Validate source patterns |
https://builds.apache.org/job/PreCommit-LUCENE-Build/286/artifact/out/patch-compile-lucene_facet.txt
|
| unit |
https://builds.apache.org/job/PreCommit-LUCENE-Build/286/artifact/out/patch-unit-lucene_facet.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-LUCENE-Build/286/testReport/ |
| modules | C: lucene/facet U: lucene/facet |
| Console output |
https://builds.apache.org/job/PreCommit-LUCENE-Build/286/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly
> accessible
> -
>
> Key: LUCENE-9437
> URL: https://issues.apache.org/jira/browse/LUCENE-9437
> Project: Lucene - Core
> Issue Type: Improvement
>Affects Versions: 8.6
>Reporter: Ankur
>Priority: Trivial
> Attachments: LUCENE-9437.patch
>
>
> Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is
> set to 'protected'. This prevents the method from being used outside this
> class in a setting where BinaryDocValues reader is instantiated outside the
> class and binary payload containing ordinals still needs to be decoded.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
