[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205277#comment-17205277
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
I believe [this
failure|https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/4533/consoleFull]
is also related to the changes here:
{noformat}
[junit4] 2> 11557 ERROR (qtp351699759-119) [n:127.0.0.1:35307_solr ]
o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Error
CREATEing SolrCore 'collection1_shard1_replica_n1': Unable to create core
[collection1_shard1_replica_n1] Caused by: org.apache.solr.schema.IndexSchema$1
cannot be cast to org.apache.solr.core.SolrResourceLoader
[junit4] 2>at
org.apache.solr.core.CoreContainer.create(CoreContainer.java:1318)
[junit4] 2>at
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:95)
[junit4] 2>at
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:367)
[junit4] 2>at
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:397)
[junit4] 2>at
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:181)
[junit4] 2>at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
[junit4] 2>at
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
[junit4] 2>at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
[junit4] 2>at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
[junit4] 2>at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
[junit4] 2>at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
[junit4] 2>at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
[junit4] 2>at
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:166)
[junit4] 2>at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
[junit4] 2>at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
[junit4] 2>at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
[junit4] 2>at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
[junit4] 2>at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
[junit4] 2>at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
[junit4] 2>at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
[junit4] 2>at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
[junit4] 2>at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
[junit4] 2>at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
[junit4] 2>at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
[junit4] 2>at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
[junit4] 2>at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
[junit4] 2>at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
[junit4] 2>at
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:717)
[junit4] 2>at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
[junit4] 2>at
org.eclipse.jetty.server.Server.handle(Server.java:500)
[junit4] 2>at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
[junit4] 2>at
org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
[junit4] 2>at
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
[junit4] 2>at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
[junit4] 2>at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
[junit4] 2>at
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
[junit4] 2>at
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:543)
[junit4] 2>at
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:398)
[junit4] 2>at
org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:161)
[junit4]
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1932: Reuse crypto keys in reference impl
noblepaul commented on a change in pull request #1932: URL: https://github.com/apache/lucene-solr/pull/1932#discussion_r497984715 ## File path: solr/test-framework/src/java/org/apache/solr/SolrTestCase.java ## @@ -124,6 +126,17 @@ protected volatile static PerThreadExecService testExecutor; + private static final CryptoKeys.RSAKeyPair reusedKeys = new CryptoKeys.RSAKeyPair(); Review comment: This is for just testcase 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-14408) Refactor MoreLikeThisHandler Implementation
[
https://issues.apache.org/jira/browse/SOLR-14408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205234#comment-17205234
]
David Smiley commented on SOLR-14408:
-
I found {{org.apache.lucene.util.QueryBuilder.TermAndBoost}} :-)I just
guessed what I would name this thing, and I guessed right. There's a similar
one inside SynonymQuery. Perhaps Lucene ought to have a utility class for
it... or not because it's so simple so just have it be an inner class to the
functionality it's related to. I think I would prefer that instead of a
generic one -- thus put as an inner class of MoreLikeThisHelper. That's my
opinion, any way.
> Refactor MoreLikeThisHandler Implementation
> ---
>
> Key: SOLR-14408
> URL: https://issues.apache.org/jira/browse/SOLR-14408
> Project: Solr
> Issue Type: Improvement
> Components: MoreLikeThis
>Reporter: Nazerke Seidan
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The main goal of this refactoring is for readability and accessibility of
> MoreLikeThisHandler class. Current MoreLikeThisHandler class consists of two
> static subclasses and accessing them later in MoreLikeThisComponent. I
> propose to have them as separate public classes.
> cc: [~abenedetti], as you have had the recent commit for MLT, what do you
> think about this? Anyway, the code is ready for review.
>
>
>
--
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 #1905: LUCENE-9488 Release with Gradle Part 2
madrob commented on pull request #1905: URL: https://github.com/apache/lucene-solr/pull/1905#issuecomment-701674748 Dawid, it took me a few tries of going through your comments and other examples in the code but I think it finally dawned on me what you meant as the proper way to do it. Each task can export its own outputs as an artifact, that's the piece that was missing in my mental model. Please take another look? There's another piece where the Luke log4j dependency was causing a duplicate entry error in the archives... not sure if you were getting the same error or not. Otherwise the output zip looks pretty close to the real thing from 8x 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] markrmiller commented on a change in pull request #1932: Reuse crypto keys in reference impl
markrmiller commented on a change in pull request #1932:
URL: https://github.com/apache/lucene-solr/pull/1932#discussion_r497827861
##
File path: solr/test-framework/src/java/org/apache/solr/SolrTestCase.java
##
@@ -225,7 +238,7 @@ public static void setDefaultConfigDirSysPropIfNotSet()
throws Exception {
System.setProperty("solr.clustering.enabled", "false");
System.setProperty("solr.peerSync.useRangeVersions",
String.valueOf(random().nextBoolean()));
System.setProperty("zookeeper.nio.directBufferBytes", Integer.toString(32
* 1024 * 2));
-System.setProperty("solr.disablePublicKeyHandler", "true");
+enableReuseOfCryptoKeys();
if (!TEST_NIGHTLY) {
Review comment:
Let's enable reuse here instead.
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] markrmiller commented on a change in pull request #1932: Reuse crypto keys in reference impl
markrmiller commented on a change in pull request #1932:
URL: https://github.com/apache/lucene-solr/pull/1932#discussion_r497827172
##
File path: solr/test-framework/src/java/org/apache/solr/SolrTestCase.java
##
@@ -279,7 +292,6 @@ public static void setDefaultConfigDirSysPropIfNotSet()
throws Exception {
System.setProperty("solr.http2solrclient.maxpool.size", "12");
System.setProperty("solr.http2solrclient.pool.keepalive", "1500");
Review comment:
Let's enable reuse here instead.
##
File path: solr/test-framework/src/java/org/apache/solr/SolrTestCase.java
##
@@ -225,7 +238,7 @@ public static void setDefaultConfigDirSysPropIfNotSet()
throws Exception {
System.setProperty("solr.clustering.enabled", "false");
System.setProperty("solr.peerSync.useRangeVersions",
String.valueOf(random().nextBoolean()));
System.setProperty("zookeeper.nio.directBufferBytes", Integer.toString(32
* 1024 * 2));
-System.setProperty("solr.disablePublicKeyHandler", "true");
+enableReuseOfCryptoKeys();
Review comment:
Looks like I had this reversed. We should likely enable reuse below in
the non Nightly run and disable for the closer to prod Nightly run.
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-14904) Don't use documentCache for large result sets
[ https://issues.apache.org/jira/browse/SOLR-14904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205047#comment-17205047 ] David Smiley commented on SOLR-14904: - I'm thinking for a threshold use the smaller of documentCache.getMaxSize and queryResultMaxDocsCached, considering the possibility of a -1 for either (unsupported or unspecified) and use Integer.MAX_VALUE. I'd rather not introduce yet another threshold configuration for minutia like this, and I think this threshold algorithm seems safe/conservative. What we have today (no threshold) has been there for all of Solr's existence. Also, if you're specifying cursorMark beyond the first page, then we shouldn't consult the documentCache either. > Don't use documentCache for large result sets > - > > Key: SOLR-14904 > URL: https://issues.apache.org/jira/browse/SOLR-14904 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > > Some users ask Solr to return many documents (high rows param), even though > this is an anti-pattern. Sometimes there is some sense to it, and even Solr > itself will do it in some cases like "bin/solr export" and perhaps some > streaming-expressions cases. If there is a documentCache, these queries have > a tendency to completely thrash it -- dump it and fill it with poor cache > candidates. I've even seen the cache's existence for such queries become a > bottleneck of the query -- granted for the now old LRUCache and in a > particularly high abuse-case. > I propose that if the number of documents to be returned is above some > fraction of the documentCache's size limit, then don't use the documentCache > at all. Maybe half size is sufficient? Or quarter-size? Maybe at least > queryWindowSize big (thus at least 20 typically)? I see in solrconfig a > queryResultMaxDocsCached option used for the queryResultCache but it could be > made to apply to populating the documentCache as well. Code default is > infinite but the default and most configs set to 200. -- 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-14908) solr-8.6.2/contrib/clustering/README.txt contains reference rot.
[ https://issues.apache.org/jira/browse/SOLR-14908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205033#comment-17205033 ] Cassandra Targett commented on SOLR-14908: -- It just needs ".html" at the end of the URL. > solr-8.6.2/contrib/clustering/README.txt contains reference rot. > > > Key: SOLR-14908 > URL: https://issues.apache.org/jira/browse/SOLR-14908 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.6.2 >Reporter: Rainer Gnan >Priority: Trivial > Labels: documentation > > [https://lucene.apache.org/solr/guide/result-clustering] leads to "The > requested URL was not found on this server.". -- 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-14908) solr-8.6.2/contrib/clustering/README.txt contains reference rot.
[ https://issues.apache.org/jira/browse/SOLR-14908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-14908: - Component/s: documentation > solr-8.6.2/contrib/clustering/README.txt contains reference rot. > > > Key: SOLR-14908 > URL: https://issues.apache.org/jira/browse/SOLR-14908 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.6.2 >Reporter: Rainer Gnan >Priority: Trivial > Labels: documentation > > [https://lucene.apache.org/solr/guide/result-clustering] leads to "The > requested URL was not found on this server.". -- 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-14904) Don't use documentCache for large result sets
[ https://issues.apache.org/jira/browse/SOLR-14904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley reassigned SOLR-14904: --- Assignee: David Smiley > Don't use documentCache for large result sets > - > > Key: SOLR-14904 > URL: https://issues.apache.org/jira/browse/SOLR-14904 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > > Some users ask Solr to return many documents (high rows param), even though > this is an anti-pattern. Sometimes there is some sense to it, and even Solr > itself will do it in some cases like "bin/solr export" and perhaps some > streaming-expressions cases. If there is a documentCache, these queries have > a tendency to completely thrash it -- dump it and fill it with poor cache > candidates. I've even seen the cache's existence for such queries become a > bottleneck of the query -- granted for the now old LRUCache and in a > particularly high abuse-case. > I propose that if the number of documents to be returned is above some > fraction of the documentCache's size limit, then don't use the documentCache > at all. Maybe half size is sufficient? Or quarter-size? Maybe at least > queryWindowSize big (thus at least 20 typically)? I see in solrconfig a > queryResultMaxDocsCached option used for the queryResultCache but it could be > made to apply to populating the documentCache as well. Code default is > infinite but the default and most configs set to 200. -- 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-14908) solr-8.6.2/contrib/clustering/README.txt contains reference rot.
Rainer Gnan created SOLR-14908: -- Summary: solr-8.6.2/contrib/clustering/README.txt contains reference rot. Key: SOLR-14908 URL: https://issues.apache.org/jira/browse/SOLR-14908 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 8.6.2 Reporter: Rainer Gnan [https://lucene.apache.org/solr/guide/result-clustering] leads to "The requested URL was not found on this server.". -- 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] dweiss commented on a change in pull request #1929: LUCENE-9548: Apache repository publishing
dweiss commented on a change in pull request #1929:
URL: https://github.com/apache/lucene-solr/pull/1929#discussion_r497754262
##
File path: gradle/maven/defaults-maven.gradle
##
@@ -102,29 +123,74 @@ configure(subprojects.findAll { it.path in
rootProject.published }) { prj ->
gradle.projectsEvaluated {
publishing {
def configurePom = {
- name = "Apache Solr/Lucene (${project.name})"
+ if (project.path.startsWith(":solr")) {
+name = "Apache Solr (module: ${project.name})"
+description = name
+url = 'https://lucene.apache.org/solr/'
+ } else {
+name = "Apache Lucene (module: ${project.name})"
+description = name
+url = 'https://lucene.apache.org/'
+ }
+
licenses {
license {
name = 'Apache 2'
url = 'http://www.apache.org/licenses/LICENSE-2.0.txt'
}
}
-}
-publications {
- // JARS and sources, no javadocs (for local inspection only).
- jars(MavenPublication) {
-from components.java
-groupId = project.group
-artifactId = project.archivesBaseName
+ inceptionYear = "2000"
-artifact sourcesJar
+ issueManagement {
+system = "JIRA"
+url = "https://issues.apache.org/jira/browse/LUCENE;
Review comment:
All of it should be project-dependent, really... But yes -- feel free to
commit a patch.
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] NazerkeBS commented on a change in pull request #1935: SOLR-14905: Update commons-io version to 2.8.0
NazerkeBS commented on a change in pull request #1935: URL: https://github.com/apache/lucene-solr/pull/1935#discussion_r497742834 ## File path: lucene/ivy-versions.properties ## @@ -54,8 +54,8 @@ com.sun.jersey.version = 1.19 /commons-cli/commons-cli = 1.4 /commons-codec/commons-codec = 1.13 /commons-collections/commons-collections = 3.2.2 -/commons-io/commons-io = 2.6 -# necessary to run test or embedded Zookeeper as of 3.6.1 +/commons-io/commons-io = 2.8.0 +# necessary to run test or embedded Zookeeper as of 3.common-build.xml6.1 Review comment: thanks @dsmiley, indeed it was a mistake 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 #1929: LUCENE-9548: Apache repository publishing
madrob commented on a change in pull request #1929:
URL: https://github.com/apache/lucene-solr/pull/1929#discussion_r497720643
##
File path: gradle/maven/defaults-maven.gradle
##
@@ -102,29 +123,74 @@ configure(subprojects.findAll { it.path in
rootProject.published }) { prj ->
gradle.projectsEvaluated {
publishing {
def configurePom = {
- name = "Apache Solr/Lucene (${project.name})"
+ if (project.path.startsWith(":solr")) {
+name = "Apache Solr (module: ${project.name})"
+description = name
+url = 'https://lucene.apache.org/solr/'
+ } else {
+name = "Apache Lucene (module: ${project.name})"
+description = name
+url = 'https://lucene.apache.org/'
+ }
+
licenses {
license {
name = 'Apache 2'
url = 'http://www.apache.org/licenses/LICENSE-2.0.txt'
}
}
-}
-publications {
- // JARS and sources, no javadocs (for local inspection only).
- jars(MavenPublication) {
-from components.java
-groupId = project.group
-artifactId = project.archivesBaseName
+ inceptionYear = "2000"
-artifact sourcesJar
+ issueManagement {
+system = "JIRA"
+url = "https://issues.apache.org/jira/browse/LUCENE;
Review comment:
This should be split by project?
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 #1932: Reuse crypto keys in reference impl
madrob commented on a change in pull request #1932: URL: https://github.com/apache/lucene-solr/pull/1932#discussion_r497719525 ## File path: solr/test-framework/src/java/org/apache/solr/SolrTestCase.java ## @@ -124,6 +126,17 @@ protected volatile static PerThreadExecService testExecutor; + private static final CryptoKeys.RSAKeyPair reusedKeys = new CryptoKeys.RSAKeyPair(); Review comment: Why not use the key-pair that's already on disk? See https://github.com/apache/lucene-solr/blob/master/solr/test-framework/src/java/org/apache/solr/SolrTestCaseJ4.java#L289-L290 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 #1932: Reuse crypto keys in reference impl
madrob commented on a change in pull request #1932:
URL: https://github.com/apache/lucene-solr/pull/1932#discussion_r497719279
##
File path: solr/core/src/java/org/apache/solr/security/PublicKeyHandler.java
##
@@ -32,18 +32,22 @@
public class PublicKeyHandler extends RequestHandlerBase {
public static final String PATH = "/admin/info/key";
+ //This is an optimization for tests only
+ public static volatile CryptoKeys.RSAKeyPair REUSABLE_KEYPAIR ;
Review comment:
Why not use the key-pair that's already on disk? See
https://github.com/apache/lucene-solr/blob/master/solr/test-framework/src/java/org/apache/solr/SolrTestCaseJ4.java#L289-L290
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-14123) autoAddReplicas is not reliable when multiple nodes go down.
[ https://issues.apache.org/jira/browse/SOLR-14123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204943#comment-17204943 ] David Smiley commented on SOLR-14123: - [~ab] I suspect this issue can be closed because the autoScaling system was removed in 9. Can you confirm? > autoAddReplicas is not reliable when multiple nodes go down. > > > Key: SOLR-14123 > URL: https://issues.apache.org/jira/browse/SOLR-14123 > Project: Solr > Issue Type: Bug > Components: AutoScaling >Affects Versions: 8.3 >Reporter: David Hunt >Priority: Major > Labels: autoscale > > I started noticing problems in our production environment with indexing being > blocked due to a minimum replication factor not being met. We have > autoAddReplicas triggers in place to add replicas when nodes our lost but it > doesn't seem to correctly add all replicas that have been lost when nodes are > lost. I’ve been able to reproduce this behavior consistently in a development > environment. > Repro: > # Setup a 10 node SolrCloud cluster. > # Create autoAddReplicas to trigger on nodeLost with waitFor set to 10 > minutes. > # Create 15 collections with 2 shards and 4 replicas. > # Kill 3 Solr nodes. > # 15 minutes later kill 1 more Solr node. > Results: > Monitor your shards/replicas. You’ll see some replicas added to make up for > the lost replicas but not all. An hour later many shards are still missing > replicas. > Expected: > All lost replicas should be added on the 6 remaining healthy nodes. -- 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-9444) Need an API to easily fetch facet labels for a field in a document
[ https://issues.apache.org/jira/browse/LUCENE-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204908#comment-17204908 ] ASF subversion and git services commented on LUCENE-9444: - Commit cc341292d2f2dd4bd0a6ccbd379424d8c2f23644 in lucene-solr's branch refs/heads/branch_8x from goankur [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cc34129 ] LUCENE-9444: Improve test coverage for TaxonomyFacetLabels (#1928) Co-authored-by: Ankur Goel > Need an API to easily fetch facet labels for a field in a document > -- > > Key: LUCENE-9444 > URL: https://issues.apache.org/jira/browse/LUCENE-9444 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/facet >Affects Versions: 8.6 >Reporter: Ankur >Priority: Major > Labels: facet > Fix For: master (9.0), 8.7 > > Attachments: LUCENE-9444.patch, LUCENE-9444.patch, > LUCENE-9444.v2.patch > > Time Spent: 5h 10m > Remaining Estimate: 0h > > A facet field may be included in the list of fields whose values are to be > returned for each hit. > In order to get the facet labels for each hit we need to > # Create an instance of _DocValuesOrdinalsReader_ and invoke > _getReader(LeafReaderContext context)_ method to obtain an instance of > _OrdinalsSegmentReader()_ > # _OrdinalsSegmentReader.get(int docID, IntsRef ordinals)_ method is then > used to fetch and decode the binary payload in the document's BinaryDocValues > field. This provides the ordinals that refer to facet labels in the > taxonomy.** > # Lastly TaxonomyReader.getPath(ord) is used to fetch the labels to be > returned. > > Ideally there should be a simple API - *String[] getLabels(docId)* that hides > all the above details and gives us the string labels. This can be part of > *TaxonomyFacets* but that's just one idea. > I am opening this issue to get community feedback and suggestions. > -- 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-9444) Need an API to easily fetch facet labels for a field in a document
[ https://issues.apache.org/jira/browse/LUCENE-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204906#comment-17204906 ] ASF subversion and git services commented on LUCENE-9444: - Commit 2e2161b0e09808b1856c746a6748875c395b855e in lucene-solr's branch refs/heads/master from goankur [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2e2161b ] LUCENE-9444: Improve test coverage for TaxonomyFacetLabels (#1928) Co-authored-by: Ankur Goel > Need an API to easily fetch facet labels for a field in a document > -- > > Key: LUCENE-9444 > URL: https://issues.apache.org/jira/browse/LUCENE-9444 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/facet >Affects Versions: 8.6 >Reporter: Ankur >Priority: Major > Labels: facet > Fix For: master (9.0), 8.7 > > Attachments: LUCENE-9444.patch, LUCENE-9444.patch, > LUCENE-9444.v2.patch > > Time Spent: 5h 10m > Remaining Estimate: 0h > > A facet field may be included in the list of fields whose values are to be > returned for each hit. > In order to get the facet labels for each hit we need to > # Create an instance of _DocValuesOrdinalsReader_ and invoke > _getReader(LeafReaderContext context)_ method to obtain an instance of > _OrdinalsSegmentReader()_ > # _OrdinalsSegmentReader.get(int docID, IntsRef ordinals)_ method is then > used to fetch and decode the binary payload in the document's BinaryDocValues > field. This provides the ordinals that refer to facet labels in the > taxonomy.** > # Lastly TaxonomyReader.getPath(ord) is used to fetch the labels to be > returned. > > Ideally there should be a simple API - *String[] getLabels(docId)* that hides > all the above details and gives us the string labels. This can be part of > *TaxonomyFacets* but that's just one idea. > I am opening this issue to get community feedback and suggestions. > -- 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] mikemccand merged pull request #1928: LUCENE-9444: Improve test coverage for TaxonomyFacetLabels
mikemccand merged pull request #1928: URL: https://github.com/apache/lucene-solr/pull/1928 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-14907) Support single file upload/overwrite in configSet API
Houston Putman created SOLR-14907: - Summary: Support single file upload/overwrite in configSet API Key: SOLR-14907 URL: https://issues.apache.org/jira/browse/SOLR-14907 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: configset-api Reporter: Houston Putman After SOLR-10391 was implemented, users are now able to overwrite existing configSets using the configSet API. However the files uploaded are still required to be zipped and indexed from the base configSet path in ZK. Users might want to just update a single file, such as a synonyms list, and not have to tar it up first. The proposed solution is to add parameters to the UPLOAD configSet action, to allow this single-file use case. This would utilize the protections already provided by the API, such as maintaining the trustiness of configSets being modified. This feature is part of the solution to replace managed resources, which is planned to be deprecated and removed by 9.0 (SOLR-14766). -- 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] (SOLR-14906) solr-core depends on restlet 2.4.3 that is missing from Maven repo
[ https://issues.apache.org/jira/browse/SOLR-14906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved SOLR-14906. Resolution: Won't Fix These dependencies are in a different Maven repository, you need to add it to your maven or gradle configs. See here: https://restlet.talend.com/documentation/user-guide/2.4/introduction/getting-started/maven > solr-core depends on restlet 2.4.3 that is missing from Maven repo > -- > > Key: SOLR-14906 > URL: https://issues.apache.org/jira/browse/SOLR-14906 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Krzysztof Debski >Priority: Major > > [https://repo.spring.io/plugins-release/org/restlet/jee/org.restlet/] does > not have version 2.4.3 > solr-core 8.6.2 depends on that version > The Maven Central does not have Restlet at all. > The direct link to Restlet repository, however, works: > https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.jar -- 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-14906) solr-core depends on restlet 2.4.3 that is missing from Maven repo
[ https://issues.apache.org/jira/browse/SOLR-14906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krzysztof Debski updated SOLR-14906: Description: [https://repo.spring.io/plugins-release/org/restlet/jee/org.restlet/] does not have version 2.4.3 solr-core 8.6.2 depends on that version The Maven Central does not have Restlet at all. The direct link to Restlet repository, however, works: https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.jar was: [https://repo.spring.io/plugins-release/org/restlet/jee/org.restlet/] does not have version 2.4.3 solr-core 8.6.2 depends on that version The Maven Central does not have Restlet at all. > solr-core depends on restlet 2.4.3 that is missing from Maven repo > -- > > Key: SOLR-14906 > URL: https://issues.apache.org/jira/browse/SOLR-14906 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Krzysztof Debski >Priority: Major > > [https://repo.spring.io/plugins-release/org/restlet/jee/org.restlet/] does > not have version 2.4.3 > solr-core 8.6.2 depends on that version > The Maven Central does not have Restlet at all. > The direct link to Restlet repository, however, works: > https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.jar -- 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-14906) solr-core depends on restlet 2.4.3 that is missing from Maven repo
[ https://issues.apache.org/jira/browse/SOLR-14906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krzysztof Debski updated SOLR-14906: Description: [https://repo.spring.io/plugins-release/org/restlet/jee/org.restlet/] does not have version 2.4.3 solr-core 8.6.2 depends on that version The Maven Central does not have Restlet at all. was: [https://repo.spring.io/plugins-release/org/restlet/jee/org.restlet/] does not have version 2.4.3 solr-core 8.6.2 depends on that version > solr-core depends on restlet 2.4.3 that is missing from Maven repo > -- > > Key: SOLR-14906 > URL: https://issues.apache.org/jira/browse/SOLR-14906 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Krzysztof Debski >Priority: Major > > [https://repo.spring.io/plugins-release/org/restlet/jee/org.restlet/] does > not have version 2.4.3 > solr-core 8.6.2 depends on that version > The Maven Central does not have Restlet at all. -- 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] dweiss commented on pull request #1899: Adding dev-docs around the use of Git Worktree.
dweiss commented on pull request #1899: URL: https://github.com/apache/lucene-solr/pull/1899#issuecomment-701483688 help/ are plain text files that are also converted to gradle tasks. I wouldn't want them to be converted to adoc because then we'd have to parse them somehow. To me help/ is really low-level stuff related to build and tooling/ dev-docs/ seem to be higher-level process related stuff? This is the way I see it. 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-14906) solr-core depends on restlet 2.4.3 that is missing from Maven repo
[ https://issues.apache.org/jira/browse/SOLR-14906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krzysztof Debski updated SOLR-14906: Summary: solr-core depends on restlet 2.4.3 that is missing from Maven repo (was: solr-core depends on restlet 2.4.3 that is missing in Maven repo) > solr-core depends on restlet 2.4.3 that is missing from Maven repo > -- > > Key: SOLR-14906 > URL: https://issues.apache.org/jira/browse/SOLR-14906 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Krzysztof Debski >Priority: Major > > [https://repo.spring.io/plugins-release/org/restlet/jee/org.restlet/] does > not have version 2.4.3 > solr-core 8.6.2 depends on that version -- 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-14906) solr-core depends on restlet 2.4.3 that is missing in Maven repo
Krzysztof Debski created SOLR-14906: --- Summary: solr-core depends on restlet 2.4.3 that is missing in Maven repo Key: SOLR-14906 URL: https://issues.apache.org/jira/browse/SOLR-14906 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Krzysztof Debski [https://repo.spring.io/plugins-release/org/restlet/jee/org.restlet/] does not have version 2.4.3 solr-core 8.6.2 depends on that version -- 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] dsmiley commented on a change in pull request #1935: SOLR-14905: Update commons-io version to 2.8.0
dsmiley commented on a change in pull request #1935: URL: https://github.com/apache/lucene-solr/pull/1935#discussion_r497617859 ## File path: lucene/ivy-versions.properties ## @@ -54,8 +54,8 @@ com.sun.jersey.version = 1.19 /commons-cli/commons-cli = 1.4 /commons-codec/commons-codec = 1.13 /commons-collections/commons-collections = 3.2.2 -/commons-io/commons-io = 2.6 -# necessary to run test or embedded Zookeeper as of 3.6.1 +/commons-io/commons-io = 2.8.0 +# necessary to run test or embedded Zookeeper as of 3.common-build.xml6.1 Review comment: a mistake? 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] NazerkeBS commented on pull request #1934: SOLR-14905: Update commons-io version to 2.8.0
NazerkeBS commented on pull request #1934: URL: https://github.com/apache/lucene-solr/pull/1934#issuecomment-701459344 @bruno-roustant, the second PR for backporting this change to 8x: https://github.com/apache/lucene-solr/pull/1935 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] NazerkeBS opened a new pull request #1935: SOLR-14905: Update commons-io version to 2.8.0
NazerkeBS opened a new pull request #1935: URL: https://github.com/apache/lucene-solr/pull/1935 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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-14749) Provide a clean API for cluster-level event processing
[
https://issues.apache.org/jira/browse/SOLR-14749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204769#comment-17204769
]
Noble Paul commented on SOLR-14749:
---
[~ab] please do not make backward incompatible changes without proper
discussions
> Provide a clean API for cluster-level event processing
> --
>
> Key: SOLR-14749
> URL: https://issues.apache.org/jira/browse/SOLR-14749
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
> Time Spent: 13h 40m
> Remaining Estimate: 0h
>
> This is a companion issue to SOLR-14613 and it aims at providing a clean,
> strongly typed API for the functionality formerly known as "triggers" - that
> is, a component for generating cluster-level events corresponding to changes
> in the cluster state, and a pluggable API for processing these events.
> The 8x triggers have been removed so this functionality is currently missing
> in 9.0. However, this functionality is crucial for implementing the automatic
> collection repair and re-balancing as the cluster state changes (nodes going
> down / up, becoming overloaded / unused / decommissioned, etc).
> For this reason we need this API and a default implementation of triggers
> that at least can perform automatic collection repair (maintaining the
> desired replication factor in presence of live node changes).
> As before, the actual changes to the collections will be executed using
> existing CollectionAdmin API, which in turn may use the placement plugins
> from SOLR-14613.
> h3. Division of responsibility
> * built-in Solr components (non-pluggable):
> ** cluster state monitoring and event generation,
> ** simple scheduler to periodically generate scheduled events
> * plugins:
> ** automatic collection repair on {{nodeLost}} events (provided by default)
> ** re-balancing of replicas (periodic or on {{nodeAdded}} events)
> ** reporting (eg. requesting additional node provisioning)
> ** scheduled maintenance (eg. removing inactive shards after split)
> h3. Other considerations
> These plugins (unlike the placement plugins) need to execute on one
> designated node in the cluster. Currently the easiest way to implement this
> is to run them on the Overseer leader node.
--
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] dsmiley commented on pull request #1899: Adding dev-docs around the use of Git Worktree.
dsmiley commented on pull request #1899: URL: https://github.com/apache/lucene-solr/pull/1899#issuecomment-701424468 Oh wait... this is confusing -- help/ and dev-docs/. I went looking for this doc just now and looked in the wrong place (help/). Any opinions @dweiss 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] noblepaul commented on a change in pull request #1758: SOLR-14749: Provide a clean API for cluster-level event processing, Initial draft.
noblepaul commented on a change in pull request #1758:
URL: https://github.com/apache/lucene-solr/pull/1758#discussion_r497515320
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/ContainerPluginsApi.java
##
@@ -64,15 +64,15 @@ public ContainerPluginsApi(CoreContainer coreContainer) {
public class Read {
@EndPoint(method = METHOD.GET,
-path = "/cluster/plugin",
+path = "/cluster/plugins",
Review comment:
We can , but that doesn't mean we should. This is just a cosmetic
change. Adds no value to user but causes enormous pain to the user. We just
make people not upgrade at all
I'm -1 on doing a breaking 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] NazerkeBS commented on pull request #1934: SOLR-14905: Update commons-io version to 2.8.0
NazerkeBS commented on pull request #1934: URL: https://github.com/apache/lucene-solr/pull/1934#issuecomment-701393720 I will backport this change to 8x with new PR. 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] ErickErickson commented on pull request #1934: SOLR-14905: Update commons-io version to 2.8.0
ErickErickson commented on pull request #1934: URL: https://github.com/apache/lucene-solr/pull/1934#issuecomment-701392535 I don't insist on backporting to 8x, just making sure it's on people's radar if people want to backport... 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] jpountz commented on pull request #1912: LUCENE-9535: Try to do larger flushes.
jpountz commented on pull request #1912: URL: https://github.com/apache/lucene-solr/pull/1912#issuecomment-701391295 I shot in the middle by still using a list rather than a true PQ but trying to keep it mostly ordered in order to make it more likely to poll one of the larger DWPTs. The number of flushes is a bit higher than the previous version of the patch (219 vs. 216) but still lower than current master (224-226). 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] bruno-roustant commented on pull request #1934: SOLR-14905: Update commons-io version to 2.8.0
bruno-roustant commented on pull request #1934: URL: https://github.com/apache/lucene-solr/pull/1934#issuecomment-701386113 Good point Erick. I think the plan was mainly to upgrade master, but that would be nice to also upgrade 8x. @NazerkeBS would you like to create a second PR (separate from this one) for 8x? Otherwise I'll do it. 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] ErickErickson commented on pull request #1934: SOLR-14905: Update commons-io version to 2.8.0
ErickErickson commented on pull request #1934: URL: https://github.com/apache/lucene-solr/pull/1934#issuecomment-701382688 This will not update 8x. We switched to Gradle for master only, backporting to a different build system partway through the 8x code line didn't seem wise. On 8x, you need to change lucene/ivy-versions.properties and run at least "ant jar-checksums" along with running precommit and the full test suite... 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-14905) Update commons-io version to 2.8.0 due to security vulnerability
[
https://issues.apache.org/jira/browse/SOLR-14905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204715#comment-17204715
]
Bruno Roustant commented on SOLR-14905:
---
Thanks Nazerke. I'm testing your PR on my side also.
> Update commons-io version to 2.8.0 due to security vulnerability
>
>
> Key: SOLR-14905
> URL: https://issues.apache.org/jira/browse/SOLR-14905
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Affects Versions: 8.6.2
>Reporter: Nazerke Seidan
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{commons-io}} (version 2.6) package is vulnerable to Path Traversal. The
> {{getPrefixLength}} method in {{FilenameUtils.class}} improperly verifies the
> hostname value received from user input before processing client requests.
> The issue has been fixed in 2.7 onward:
> (https://issues.apache.org/jira/browse/IO-556,
> https://issues.apache.org/jira/browse/IO-559)
--
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-14905) Update commons-io version to 2.8.0 due to security vulnerability
[
https://issues.apache.org/jira/browse/SOLR-14905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204700#comment-17204700
]
David Smiley commented on SOLR-14905:
-
Thanks. Judging from your PR... assuming tests pass (diid you run them?), it
appears binary compatible. Apparently there was one minor source compatibility
change in a test.
> Update commons-io version to 2.8.0 due to security vulnerability
>
>
> Key: SOLR-14905
> URL: https://issues.apache.org/jira/browse/SOLR-14905
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Affects Versions: 8.6.2
>Reporter: Nazerke Seidan
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{commons-io}} (version 2.6) package is vulnerable to Path Traversal. The
> {{getPrefixLength}} method in {{FilenameUtils.class}} improperly verifies the
> hostname value received from user input before processing client requests.
> The issue has been fixed in 2.7 onward:
> (https://issues.apache.org/jira/browse/IO-556,
> https://issues.apache.org/jira/browse/IO-559)
--
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-9550) Upgrade Gradle to version 6.6.1
[ https://issues.apache.org/jira/browse/LUCENE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-9550. -- Fix Version/s: 8.7 Resolution: Fixed > Upgrade Gradle to version 6.6.1 > --- > > Key: LUCENE-9550 > URL: https://issues.apache.org/jira/browse/LUCENE-9550 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Fix For: 8.7 > > Time Spent: 20m > Remaining Estimate: 0h > > We're currently on 6.4.1. -- 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] NazerkeBS opened a new pull request #1934: SOLR-14905: Update commons-io version to 2.8.0
NazerkeBS opened a new pull request #1934: URL: https://github.com/apache/lucene-solr/pull/1934 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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 #1740: LUCENE-9458: WDGF and WDF should tie-break by endOffset
dsmiley commented on pull request #1740: URL: https://github.com/apache/lucene-solr/pull/1740#issuecomment-701351121 @jimczi I dunno if you want to look at this again but I plan to commit within the next day for 8.7. 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-14905) Update commons-io version to 2.8.0 due to security vulnerability
Nazerke Seidan created SOLR-14905:
-
Summary: Update commons-io version to 2.8.0 due to security
vulnerability
Key: SOLR-14905
URL: https://issues.apache.org/jira/browse/SOLR-14905
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: security
Affects Versions: 8.6.2
Reporter: Nazerke Seidan
The {{commons-io}} (version 2.6) package is vulnerable to Path Traversal. The
{{getPrefixLength}} method in {{FilenameUtils.class}} improperly verifies the
hostname value received from user input before processing client requests.
The issue has been fixed in 2.7 onward:
(https://issues.apache.org/jira/browse/IO-556,
https://issues.apache.org/jira/browse/IO-559)
--
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-9550) Upgrade Gradle to version 6.6.1
[ https://issues.apache.org/jira/browse/LUCENE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204598#comment-17204598 ] Dawid Weiss commented on LUCENE-9550: - Thanks Adrien. If something pops up, we'll create a follow-up issue. > Upgrade Gradle to version 6.6.1 > --- > > Key: LUCENE-9550 > URL: https://issues.apache.org/jira/browse/LUCENE-9550 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > We're currently on 6.4.1. -- 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-9550) Upgrade Gradle to version 6.6.1
[ https://issues.apache.org/jira/browse/LUCENE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204596#comment-17204596 ] ASF subversion and git services commented on LUCENE-9550: - Commit f8b7a605622f05e288cc9775f3e6c57d14753344 in lucene-solr's branch refs/heads/master from Adrien Grand [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f8b7a60 ] LUCENE-9550: Upgrade to Gradle 6.6.1. (#1933) > Upgrade Gradle to version 6.6.1 > --- > > Key: LUCENE-9550 > URL: https://issues.apache.org/jira/browse/LUCENE-9550 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > We're currently on 6.4.1. -- 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] jpountz merged pull request #1933: LUCENE-9550: Upgrade to Gradle 6.6.1.
jpountz merged pull request #1933: URL: https://github.com/apache/lucene-solr/pull/1933 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-9550) Upgrade Gradle to version 6.6.1
[
https://issues.apache.org/jira/browse/LUCENE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204594#comment-17204594
]
Adrien Grand commented on LUCENE-9550:
--
No Gradle warning, here's the output I got:
{code}
$ ./gradlew check
> Task :solr:contrib:analysis-extras:compileJava
Note:
/home/jpountz/src/lucene-solr/solr/contrib/analysis-extras/src/java/org/apache/solr/schema/ICUCollationField.java
uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :solr:test-framework:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :solr:core:ecjLintMain
invalid Class-Path header in manifest of jar file:
/home/jpountz/.gradle/caches/modules-2/files-2.1/org.restlet.jee/org.restlet.ext.servlet/2.4.3/5e805b9c6c07cd21958288805451236895316f56/org.restlet.ext.servlet-2.4.3.jar
> Task :solr:contrib:langid:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :solr:contrib:clustering:compileJava
Note:
/home/jpountz/src/lucene-solr/solr/contrib/clustering/src/java/org/apache/solr/handler/clustering/carrot2/CarrotClusteringEngine.java
uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :solr:contrib:analysis-extras:compileTestJava
Note:
/home/jpountz/src/lucene-solr/solr/contrib/analysis-extras/src/test/org/apache/solr/schema/TestICUCollationField.java
uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :solr:contrib:extraction:compileJava
Note:
/home/jpountz/src/lucene-solr/solr/contrib/extraction/src/java/org/apache/solr/handler/extraction/ExtractingDocumentLoader.java
uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :randomizationInfo
Running tests with randomization seed: tests.seed=6E227691F6AA1A4F
> Task :solr:contrib:ltr:ecjLintTest
invalid Class-Path header in manifest of jar file:
/home/jpountz/.gradle/caches/modules-2/files-2.1/org.restlet.jee/org.restlet.ext.servlet/2.4.3/5e805b9c6c07cd21958288805451236895316f56/org.restlet.ext.servlet-2.4.3.jar
> Task :solr:contrib:analytics:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :solr:contrib:prometheus-exporter:compileTestJava
Note:
/home/jpountz/src/lucene-solr/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/exporter/SolrExporterTestBase.java
uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :solr:core:ecjLintTest
invalid Class-Path header in manifest of jar file:
/home/jpountz/.gradle/caches/modules-2/files-2.1/org.restlet.jee/org.restlet.ext.servlet/2.4.3/5e805b9c6c07cd21958288805451236895316f56/org.restlet.ext.servlet-2.4.3.jar
> Task :solr:solrj:ecjLintTest
invalid Class-Path header in manifest of jar file:
/home/jpountz/.gradle/caches/modules-2/files-2.1/org.restlet.jee/org.restlet.ext.servlet/2.4.3/5e805b9c6c07cd21958288805451236895316f56/org.restlet.ext.servlet-2.4.3.jar
> Task :lucene:demo:test
:lucene:demo:test (SUCCESS): 15 test(s)
> Task :solr:contrib:analytics:compileTestJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :solr:solrj:compileTestJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :lucene:classification:test
:lucene:classification:test (SUCCESS): 43 test(s), 1 skipped
> Task :lucene:benchmark:test
:lucene:benchmark:test (SUCCESS): 90 test(s)
> Task :lucene:codecs:test
:lucene:codecs:test (SUCCESS): 547 test(s), 58 skipped
> Task :solr:core:compileTestJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :lucene:backward-codecs:test
:lucene:backward-codecs:test (SUCCESS): 165 test(s), 20 skipped
> Task :lucene:expressions:test
:lucene:expressions:test (SUCCESS): 111 test(s)
> Task :lucene:grouping:test
:lucene:grouping:test (SUCCESS): 44 test(s)
> Task :lucene:join:test
:lucene:join:test (SUCCESS): 47 test(s)
> Task :lucene:memory:test
:lucene:memory:test (SUCCESS): 31 test(s)
> Task :lucene:highlighter:test
:lucene:highlighter:test (SUCCESS): 698 test(s)
> Task :lucene:facet:test
:lucene:facet:test (SUCCESS): 176 test(s), 2 skipped
> Task :lucene:luke:test
:lucene:luke:test (SUCCESS): 97 test(s)
> Task :lucene:misc:test
:lucene:misc:test (SUCCESS): 149 test(s), 4 skipped
> Task :lucene:monitor:test
:lucene:monitor:test (SUCCESS): 171 test(s), 1 skipped
> Task :lucene:queryparser:test
:lucene:queryparser:test (SUCCESS): 486 test(s), 1 skipped
> Task :lucene:queries:test
:lucene:queries:test (SUCCESS): 224 test(s), 1 skipped
> Task
[jira] [Commented] (LUCENE-9550) Upgrade Gradle to version 6.6.1
[ https://issues.apache.org/jira/browse/LUCENE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204578#comment-17204578 ] Dawid Weiss commented on LUCENE-9550: - Looks good to me, Adrien. If you can eyeball the output and see if there are any API warnings that'd be good. I should create a checklist of tasks to run upon gradle upgrade but the top-level 'gradlew check' should be fine for now. > Upgrade Gradle to version 6.6.1 > --- > > Key: LUCENE-9550 > URL: https://issues.apache.org/jira/browse/LUCENE-9550 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > We're currently on 6.4.1. -- 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-9551) Upgrade gradle wrapper to v6.6.1
[ https://issues.apache.org/jira/browse/LUCENE-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-9551. - Resolution: Duplicate Dupl. of LUCENE-9550 > Upgrade gradle wrapper to v6.6.1 > > > Key: LUCENE-9551 > URL: https://issues.apache.org/jira/browse/LUCENE-9551 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > -- 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-4510) when a test's heart beats it should also throw up (dump stack of all threads)
[ https://issues.apache.org/jira/browse/LUCENE-4510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204574#comment-17204574 ] Uwe Schindler commented on LUCENE-4510: --- To all: jstack PID (using the version from the used test runner jdk) works best on Linux, Windows, Darwin: - it prints to your local console and not to stderr of test runner, so result can be piped to file - works most of the time, unless jvm is stuck. But then it has one setting more, it can enforce a stack trace halting the whole JVM. It won't work all the time, but that's more than kill -9 without any trace. > when a test's heart beats it should also throw up (dump stack of all threads) > - > > Key: LUCENE-4510 > URL: https://issues.apache.org/jira/browse/LUCENE-4510 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Dawid Weiss >Priority: Major > > We've had numerous cases where tests were hung but the "operator" of that > particular Jenkins instance struggles to properly get a stack dump for all > threads and eg accidentally kills the process instead (rather awful that the > same powerful tool "kill" can be used to get stack traces and to destroy the > process...). > Is there some way the test infra could do this for us, eg when it prints the > HEARTBEAT message? -- 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] jpountz opened a new pull request #1933: LUCENE-9550: Upgrade to Gradle 6.6.1.
jpountz opened a new pull request #1933: URL: https://github.com/apache/lucene-solr/pull/1933 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] (LUCENE-9551) Upgrade gradle wrapper to v6.6.1
Dawid Weiss created LUCENE-9551: --- Summary: Upgrade gradle wrapper to v6.6.1 Key: LUCENE-9551 URL: https://issues.apache.org/jira/browse/LUCENE-9551 Project: Lucene - Core Issue Type: 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] [Created] (LUCENE-9550) Upgrade Gradle to version 6.6.1
Adrien Grand created LUCENE-9550: Summary: Upgrade Gradle to version 6.6.1 Key: LUCENE-9550 URL: https://issues.apache.org/jira/browse/LUCENE-9550 Project: Lucene - Core Issue Type: Task Reporter: Adrien Grand We're currently on 6.4.1. -- 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-4510) when a test's heart beats it should also throw up (dump stack of all threads)
[ https://issues.apache.org/jira/browse/LUCENE-4510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204566#comment-17204566 ] Dawid Weiss commented on LUCENE-4510: - Doesn't work on Windows. :P > when a test's heart beats it should also throw up (dump stack of all threads) > - > > Key: LUCENE-4510 > URL: https://issues.apache.org/jira/browse/LUCENE-4510 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Dawid Weiss >Priority: Major > > We've had numerous cases where tests were hung but the "operator" of that > particular Jenkins instance struggles to properly get a stack dump for all > threads and eg accidentally kills the process instead (rather awful that the > same powerful tool "kill" can be used to get stack traces and to destroy the > process...). > Is there some way the test infra could do this for us, eg when it prints the > HEARTBEAT message? -- 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-9541) BitSetConjunctionDISI doesn't advance based on its components
[ https://issues.apache.org/jira/browse/LUCENE-9541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204564#comment-17204564 ] Adrien Grand commented on LUCENE-9541: -- In my opinion this is a bug in how ConjunctionDISI was used, not a bug in BitSetConjunctionDISI. Conjunction iterators maintain the invariant that between two calls to nextDoc or advance, all sub iterators are on the same doc ID. If we advance one of the subs without making ConjunctionDISI aware of it, then we break this invariant. We found this with BitSetConjunctionDISI but this would also be a problem with ConjunctionDISI. To take your example of a and b both matching [0,1], if you create a ConjunctionDISI over both iterators and a is picked as the lead, then advance b to 1 and finally call nextDoc() on the ConjunctionDISI, then it will first call nextDoc() on a, which returns 0, and then advance(0) on b which is illegal since it's illegal to call advance with a target that is less than or equal to the current doc ID. > BitSetConjunctionDISI doesn't advance based on its components > - > > Key: LUCENE-9541 > URL: https://issues.apache.org/jira/browse/LUCENE-9541 > Project: Lucene - Core > Issue Type: Bug >Reporter: Mayya Sharipova >Priority: Minor > > Not completely sure if this is a bug. > BitSetConjuctionDISI advances based on its lead – DocIdSetIterator iterator, > and doesn't consider that its another component – BitSetIterator may have > already advanced passed a certain doc. This may result in duplicate documents. > For example if BitSetConjuctionDISI _disi_ is composed of DocIdSetIterator > _a_ of docs [0,1] and BitSetIterator _b_ of docs [0,1]. Doing `b.nextDoc()` > we are collecting doc0, doing `disi.nextDoc` we again collecting the same > doc0. > It seems that other conjunction iterators don't have this behaviour, if we > are advancing any of their component pass a certain document, the whole > conjunction iterator will also be advanced pass this document. > > This behaviour was exposed in this > [PR|https://github.com/apache/lucene-solr/pull/1903]. > -- 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-9533) Consider switching to javacc21
[ https://issues.apache.org/jira/browse/LUCENE-9533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204554#comment-17204554 ] Uwe Schindler commented on LUCENE-9533: --- No success on that one? > Consider switching to javacc21 > -- > > Key: LUCENE-9533 > URL: https://issues.apache.org/jira/browse/LUCENE-9533 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Priority: Minor > > There is an actively maintained interesting "fork", here: > https://github.com/javacc21/javacc21 > I didn't look at what it generates but the list of features is impressive and > the quality of current javacc-generated code is... well, it looks like 1999. > It'd be interesting to look into it and assess if it's worth switching to. -- 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-4510) when a test's heart beats it should also throw up (dump stack of all threads)
[ https://issues.apache.org/jira/browse/LUCENE-4510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204552#comment-17204552 ] Robert Muir commented on LUCENE-4510: - signals can work, but maybe you have to send it signal 9 sometimes :) > when a test's heart beats it should also throw up (dump stack of all threads) > - > > Key: LUCENE-4510 > URL: https://issues.apache.org/jira/browse/LUCENE-4510 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Dawid Weiss >Priority: Major > > We've had numerous cases where tests were hung but the "operator" of that > particular Jenkins instance struggles to properly get a stack dump for all > threads and eg accidentally kills the process instead (rather awful that the > same powerful tool "kill" can be used to get stack traces and to destroy the > process...). > Is there some way the test infra could do this for us, eg when it prints the > HEARTBEAT message? -- 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-9549) gradle "Reproduce with" line doesn't fully quote all args
[
https://issues.apache.org/jira/browse/LUCENE-9549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss resolved LUCENE-9549.
-
Fix Version/s: master (9.0)
Resolution: Fixed
I added command line quoting via ANT's utility method. Should work in 99% of
cases. The remaining 1% accounts for escaping rules of special characters
between platforms and shells - I don't think there is a way to do it properly
to cover all the cases.
> gradle "Reproduce with" line doesn't fully quote all args
> --
>
> Key: LUCENE-9549
> URL: https://issues.apache.org/jira/browse/LUCENE-9549
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Chris M. Hostetter
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0)
>
>
> Recent jenkins build include the following outpu...
> {noformat}
> Build Log:
> [...truncated 1849 lines...]
> ERROR: The following test(s) have failed:
> - org.apache.solr.handler.JsonLoaderTest.testAddBigIntegerValueToTrieField
> (:solr:core)
> Test output:
> /home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.ha
> ndler.JsonLoaderTest.txt
> Reproduce with: gradlew :solr:core:test --tests
> "org.apache.solr.handler.JsonLoaderTest" -Ptests.jvms=6
> -Ptests.haltonfailure=false -Ptests.jvmargs=-XX:+UseCompressedOops
> -XX:+UseSerialGC -Ptests.seed=B65FB0896CCB43ED -Ptests.multiplier=3
> -Ptests.badapples=false -Ptests.file.encoding=US-ASCII
> {noformat}
> Attempting to run that command as written produces the following output...
> {noformat}
> FAILURE: Build failed with an exception.
> * What went wrong:
> Problem configuring task :solr:core:test from command line.
> > Unknown command-line option '-X'.
> {noformat}
> The explanation of that error is that {{\-XX:+UseSerialGC}} is suppose to be
> part of the {{\-Ptests.jvmargs}} param.
> Ideally the gradle Reproduce with line should have looked like...
> {noformat}
> Reproduce with: gradlew :solr:core:test --tests
> "org.apache.solr.handler.JsonLoaderTest" -Ptests.jvms=6
> -Ptests.haltonfailure=false -Ptests.jvmargs='-XX:+UseCompressedOops
> -XX:+UseSerialGC' -Ptests.seed=B65FB0896CCB43ED -Ptests.multiplier=3
> -Ptests.badapples=false -Ptests.file.encoding=US-ASCII
> {noformat}
--
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-9549) gradle "Reproduce with" line doesn't fully quote all args
[
https://issues.apache.org/jira/browse/LUCENE-9549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204527#comment-17204527
]
ASF subversion and git services commented on LUCENE-9549:
-
Commit 9bfaca0606968ed970d9d12d871f977e2655765b in lucene-solr's branch
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9bfaca0 ]
LUCENE-9549: add command-line quotes for 'reproduce with'.
> gradle "Reproduce with" line doesn't fully quote all args
> --
>
> Key: LUCENE-9549
> URL: https://issues.apache.org/jira/browse/LUCENE-9549
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Chris M. Hostetter
>Assignee: Dawid Weiss
>Priority: Major
>
> Recent jenkins build include the following outpu...
> {noformat}
> Build Log:
> [...truncated 1849 lines...]
> ERROR: The following test(s) have failed:
> - org.apache.solr.handler.JsonLoaderTest.testAddBigIntegerValueToTrieField
> (:solr:core)
> Test output:
> /home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.ha
> ndler.JsonLoaderTest.txt
> Reproduce with: gradlew :solr:core:test --tests
> "org.apache.solr.handler.JsonLoaderTest" -Ptests.jvms=6
> -Ptests.haltonfailure=false -Ptests.jvmargs=-XX:+UseCompressedOops
> -XX:+UseSerialGC -Ptests.seed=B65FB0896CCB43ED -Ptests.multiplier=3
> -Ptests.badapples=false -Ptests.file.encoding=US-ASCII
> {noformat}
> Attempting to run that command as written produces the following output...
> {noformat}
> FAILURE: Build failed with an exception.
> * What went wrong:
> Problem configuring task :solr:core:test from command line.
> > Unknown command-line option '-X'.
> {noformat}
> The explanation of that error is that {{\-XX:+UseSerialGC}} is suppose to be
> part of the {{\-Ptests.jvmargs}} param.
> Ideally the gradle Reproduce with line should have looked like...
> {noformat}
> Reproduce with: gradlew :solr:core:test --tests
> "org.apache.solr.handler.JsonLoaderTest" -Ptests.jvms=6
> -Ptests.haltonfailure=false -Ptests.jvmargs='-XX:+UseCompressedOops
> -XX:+UseSerialGC' -Ptests.seed=B65FB0896CCB43ED -Ptests.multiplier=3
> -Ptests.badapples=false -Ptests.file.encoding=US-ASCII
> {noformat}
--
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-9548) Publish master (9.x) snapshots to https://repository.apache.org
[ https://issues.apache.org/jira/browse/LUCENE-9548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204522#comment-17204522 ] Dawid Weiss commented on LUCENE-9548: - Sent a question to Infra, they must have encountered this before. > Publish master (9.x) snapshots to https://repository.apache.org > --- > > Key: LUCENE-9548 > URL: https://issues.apache.org/jira/browse/LUCENE-9548 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We should start publishing snapshot JARs to Apache repositories. I'm not sure > how to set it all up with gradle but maybe there are other Apache projects > that use gradle and we could peek at their config? Mostly it's about signing > artifacts (how to pass credentials for signing) and setting up Nexus > deployment repository. -- 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] (LUCENE-9533) Consider switching to javacc21
[ https://issues.apache.org/jira/browse/LUCENE-9533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss reassigned LUCENE-9533: --- Assignee: (was: Dawid Weiss) > Consider switching to javacc21 > -- > > Key: LUCENE-9533 > URL: https://issues.apache.org/jira/browse/LUCENE-9533 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Priority: Minor > > There is an actively maintained interesting "fork", here: > https://github.com/javacc21/javacc21 > I didn't look at what it generates but the list of features is impressive and > the quality of current javacc-generated code is... well, it looks like 1999. > It'd be interesting to look into it and assess if it's worth switching to. -- 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-9533) Consider switching to javacc21
[ https://issues.apache.org/jira/browse/LUCENE-9533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-9533. - Resolution: Won't Fix > Consider switching to javacc21 > -- > > Key: LUCENE-9533 > URL: https://issues.apache.org/jira/browse/LUCENE-9533 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > > There is an actively maintained interesting "fork", here: > https://github.com/javacc21/javacc21 > I didn't look at what it generates but the list of features is impressive and > the quality of current javacc-generated code is... well, it looks like 1999. > It'd be interesting to look into it and assess if it's worth switching to. -- 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-4510) when a test's heart beats it should also throw up (dump stack of all threads)
[ https://issues.apache.org/jira/browse/LUCENE-4510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204490#comment-17204490 ] Dawid Weiss commented on LUCENE-4510: - Even a signal doesn't always work, sadly. I think we will need to roll out a custom test runner (or modify the one in gradle) eventually because of the inability to collect early internal JVM logs and security auditing. These are fun things to work on. You need to invent a time-stretching appliance in that basement of yours, Mike, then I'll be happy to do it. :) > when a test's heart beats it should also throw up (dump stack of all threads) > - > > Key: LUCENE-4510 > URL: https://issues.apache.org/jira/browse/LUCENE-4510 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Dawid Weiss >Priority: Major > > We've had numerous cases where tests were hung but the "operator" of that > particular Jenkins instance struggles to properly get a stack dump for all > threads and eg accidentally kills the process instead (rather awful that the > same powerful tool "kill" can be used to get stack traces and to destroy the > process...). > Is there some way the test infra could do this for us, eg when it prints the > HEARTBEAT message? -- 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
