[JENKINS-EA] Lucene-Solr-BadApples-8.x-Linux (64bit/jdk-12-ea+shipilev-fastdebug) - Build # 22 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-8.x-Linux/22/ Java: 64bit/jdk-12-ea+shipilev-fastdebug -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC No tests ran. Build Log: [...truncated 14 lines...] ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://gitbox.apache.org/repos/asf/lucene-solr.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:904) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1144) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1175) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1816) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Caused by: hudson.plugins.git.GitException: org.eclipse.jgit.api.errors.TransportException: https://gitbox.apache.org/repos/asf/lucene-solr.git: cannot open git-upload-pack at org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:628) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:902) ... 11 more Caused by: org.eclipse.jgit.api.errors.TransportException: https://gitbox.apache.org/repos/asf/lucene-solr.git: cannot open git-upload-pack at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:254) at org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:626) ... 12 more Caused by: org.eclipse.jgit.errors.TransportException: https://gitbox.apache.org/repos/asf/lucene-solr.git: cannot open git-upload-pack at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:600) at org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:362) at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:138) at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:124) at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1271) at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:243) ... 13 more Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:210) at java.net.SocketInputStream.read(SocketInputStream.java:141) at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) at sun.security.ssl.InputRecord.read(InputRecord.java:503) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:347) at org.eclipse.jgit.transport.http.JDKHttpConnection.getResponseCode(JDKHttpConnection.java:115) at org.eclipse.jgit.util.HttpSupport.response(HttpSupport.java:207) at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:514) ... 18 more ERROR: Error fetching remote repo 'origin' Retrying after 10 seconds No credentials specified Fetching changes from the remote Git repository Cleaning workspace ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://gitbox.apache.org/repos/asf/lucene-solr.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:904) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1144) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1175) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at
[JENKINS] Solr-reference-guide-8.x - Build # 1111 - Failure
Build: https://builds.apache.org/job/Solr-reference-guide-8.x// Log: Started by timer [EnvInject] - Loading node environment variables. Building remotely on websites1 (git-websites svn-websites) in workspace /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x No credentials specified > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 Fetching upstream changes from https://gitbox.apache.org/repos/asf/lucene-solr.git > git --version # timeout=10 > git fetch --tags --progress > https://gitbox.apache.org/repos/asf/lucene-solr.git > +refs/heads/*:refs/remotes/origin/* ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://gitbox.apache.org/repos/asf/lucene-solr.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1810) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress https://gitbox.apache.org/repos/asf/lucene-solr.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: stderr: fatal: unable to access 'https://gitbox.apache.org/repos/asf/lucene-solr.git/': gnutls_handshake() failed: Error in the pull function. at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2042) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1761) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:72) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:442) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93) at java.lang.Thread.run(Thread.java:748) Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from 37.48.69.226/37.48.69.226:45760 at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at hudson.remoting.Channel.call(Channel.java:955) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146) at sun.reflect.GeneratedMethodAccessor845.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132) at com.sun.proxy.$Proxy115.execute(Unknown Source) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) at
[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777688#comment-16777688
]
Karl Wright commented on LUCENE-8696:
-
Since we've eliminated the computation of the solid's example intersection
points, that basically leaves numerical factors as the only potential cause.
Let's examine this further.
In the case of GeoPaths on the WGS84 globe, path intersection points are
described by "circles", which are in fact just planes that are picked so as to
connect the path segments together, as described above. But, each plane with
two adjoining segments is selected based on FOUR surface points, not three.
That means that there is a gap between one of the points and the actual
endpoint circle.
When we compute membership in the path, we exclude points in that gap from
membership. This is done by considering the path segment end planes as
delimiters of membership for both the endpoint "circles" as well as the
segments. But, those segment end planes are not considered when determining
intersection, because they are "interior" to the path. This means that it is
possible for getRelationship() to miss an intersection with the path edge if
the "gap" is large enough and everything lines up perfectly, and thus
"CONTAINS" is reported where "OVERLAPS" would be the actual correct answer.
It should be possible to see if our test case would be resolved by considering
path segment end edges. A simple trial code change should be sufficient to
know. Then the question becomes how to prevent spurious intersections? We
could just permit them (it's allowed in the contract), or we could make more
significant changes to path representation, for better accuracy. Stay tuned.
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 5066 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5066/ Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseG1GC No tests ran. Build Log: [...truncated 16 lines...] ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://gitbox.apache.org/repos/asf/lucene-solr.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:904) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1144) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1175) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1816) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Caused by: hudson.plugins.git.GitException: org.eclipse.jgit.api.errors.TransportException: https://gitbox.apache.org/repos/asf/lucene-solr.git: cannot open git-upload-pack at org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:628) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:161) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:154) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to MacOSX VBOX at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at hudson.remoting.Channel.call(Channel.java:957) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146) at sun.reflect.GeneratedMethodAccessor786.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132) at com.sun.proxy.$Proxy85.execute(Unknown Source) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:902) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1144) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1175) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1816) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Caused by: org.eclipse.jgit.api.errors.TransportException: https://gitbox.apache.org/repos/asf/lucene-solr.git: cannot open git-upload-pack at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:254) at org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:626) ... 10 more Caused by: org.eclipse.jgit.errors.TransportException: https://gitbox.apache.org/repos/asf/lucene-solr.git: cannot open git-upload-pack at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:600) at org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:362) at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:138) at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:124) at
[jira] [Updated] (SOLR-13242) RegexReplaceProcessorFactory not making accurate replacement
[
https://issues.apache.org/jira/browse/SOLR-13242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edwin Yeo Zheng Lin updated SOLR-13242:
---
Description:
We are using the RegexReplaceProcessorFactory, and have tried with all of the
following configurations in solrconfig.xml:
content
(\s*\r?\n)\{2,}
true
content
([ \s]*\r?\n)\{2,}
true
content
(\s*\n)\{2,}
true
content
(\n\s*)\{2,}
true
The regex pattern of (\s*\r?\n)\{2,}, ([ \s]*\r?\n)\{2,}, (\s*\n)\{2,} and
(\n\s*)\{2,} are working perfectly in [regex101.com|http://regex101.com/], in
which all the \n will be replaced by only two
However, in Solr, there are cases (in Example 2 and 3 below) that has four
in a row. This should not be the case, as we have already set it to replace by
two regardless of how many \n are there in a row.
*Example 1: The sentence that the above regex pattern is working correctly*
*Original content in EML [file:*|file://%2A/]
Dear Sir,
I am terminating
*Original content:* Dear Sir, \n\n \n \n\n I am terminating
*Index content:* Dear Sir, I am terminating
*Example 2: The sentence that the above regex pattern is partially working (as
you can see, instead of 2 , there are 4 )*
*Original content in EML [file:*|file://%2A/]
_exalted_
_Psalm 89:17_
3 Choa Chu Kang Avenue 4
*Original content:* exalted \n \n\n Psalm 89:17 \n\n \n\n 3 Choa Chu
Kang Avenue 4, Singapore
*Index content:* exalted Psalm 89:17 3 Choa Chu
Kang Avenue 4, Singapore
*Example 3: The sentence that the above regex pattern is partially working (as
you can see, instead of 2 , there are 4 )*
*Original content in EML [file:*|file://%2A/]
[http://www.concordpri.moe.edu.sg/]
On Tue, Dec 18, 2018 at 10:07 AM
*Original content:* [http://www.concordpri.moe.edu.sg/] \n\n \n\n \n \n\n
\n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n\n \n\n\n On Tue, Dec 18, 2018 at
10:07 AM
*Index content:* [http://www.concordpri.moe.edu.sg/] On
Tue, Dec 18, 2018 at 10:07 AM
was:
We are using the RegexReplaceProcessorFactory, and have tried with all of the
following configurations in solrconfig.xml:
content
(\s*\r?\n)\{2,}
true
content
([ \t]*\r?\n)\{2,}
true
content
(\s*\n)\{2,}
true
content
(\n\s*)\{2,}
true
The regex pattern of (\s*\r?\n)\{2,}, ([ \t]*\r?\n)\{2,}, (\s*\n)\{2,} and
(\n\s*)\{2,} are working perfectly in [regex101.com|http://regex101.com/], in
which all the \n will be replaced by only two
However, in Solr, there are cases (in Example 2 and 3 below) that has four
in a row. This should not be the case, as we have already set it to replace by
two regardless of how many \n are there in a row.
*Example 1: The sentence that the above regex pattern is working correctly*
*Original content in EML [file:*|file://%2A/]
Dear Sir,
I am terminating
*Original content:* Dear Sir, \n\n \n \n\n I am terminating
*Index content:* Dear Sir, I am terminating
*Example 2: The sentence that the above regex pattern is partially working (as
you can see, instead of 2 , there are 4 )*
*Original content in EML [file:*|file://%2A/]
_exalted_
_Psalm 89:17_
3 Choa Chu Kang Avenue 4
*Original content:* exalted \n \n\n Psalm 89:17 \n\n \n\n 3 Choa Chu
Kang Avenue 4, Singapore
*Index content:* exalted Psalm 89:17 3 Choa Chu
Kang Avenue 4, Singapore
*Example 3: The sentence that the above regex pattern is partially working (as
you can see, instead of 2 , there are 4 )*
*Original content in EML [file:*|file://%2A/]
[http://www.concordpri.moe.edu.sg/]
On Tue, Dec 18, 2018 at 10:07 AM
*Original content:* [http://www.concordpri.moe.edu.sg/] \n\n \n\n \n \n\n
\n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n\n \n\n\n On Tue, Dec 18, 2018 at
10:07 AM
*Index content:* [http://www.concordpri.moe.edu.sg/] On
Tue, Dec 18, 2018 at 10:07 AM
> RegexReplaceProcessorFactory not making accurate replacement
>
>
> Key: SOLR-13242
> URL: https://issues.apache.org/jira/browse/SOLR-13242
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6, 7.7
>Reporter: Edwin Yeo Zheng Lin
>Priority: Major
> Labels: regex, solr
>
> We are using the RegexReplaceProcessorFactory, and have tried with all of the
> following configurations in solrconfig.xml:
>
>
> content
> (\s*\r?\n)\{2,}
>
> true
>
>
> content
> ([ \s]*\r?\n)\{2,}
>
> true
>
>
> content
> (\s*\n)\{2,}
>
> true
[JENKINS-EA] Lucene-Solr-BadApples-7.x-Linux (64bit/jdk-13-ea+8) - Build # 167 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/167/ Java: 64bit/jdk-13-ea+8 -XX:-UseCompressedOops -XX:+UseG1GC 8 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.OverseerTest Error Message: SOLR-11606: ByteBuddy used by Mockito is not working with this JVM version. Stack Trace: org.junit.AssumptionViolatedException: SOLR-11606: ByteBuddy used by Mockito is not working with this JVM version. at __randomizedtesting.SeedInfo.seed([4176461D6FDC8CE]:0) at com.carrotsearch.randomizedtesting.RandomizedTest.assumeNoException(RandomizedTest.java:742) at org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:362) at org.apache.solr.cloud.OverseerTest.beforeClass(OverseerTest.java:284) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:878) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:835) Caused by: java.lang.IllegalArgumentException: Unknown Java version: 13 at net.bytebuddy.ClassFileVersion.ofJavaVersion(ClassFileVersion.java:210) at net.bytebuddy.ClassFileVersion$VersionLocator$ForJava9CapableVm.locate(ClassFileVersion.java:462) at net.bytebuddy.ClassFileVersion.ofThisVm(ClassFileVersion.java:223) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:360) ... 24 more FAILED: junit.framework.TestSuite.org.apache.solr.cloud.OverseerTest Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([4176461D6FDC8CE]:0) at org.apache.solr.cloud.OverseerTest.afterClass(OverseerTest.java:307) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:901) at
[jira] [Commented] (SOLR-13156) Limiting field facet with certain terms via {!terms} not taking into account sorting
[
https://issues.apache.org/jira/browse/SOLR-13156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777682#comment-16777682
]
superman369 commented on SOLR-13156:
@[~mkhludnev],Thanks for your reply! I am looking forward to it！
> Limiting field facet with certain terms via {!terms} not taking into account
> sorting
>
>
> Key: SOLR-13156
> URL: https://issues.apache.org/jira/browse/SOLR-13156
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Reporter: Konstantin Perikov
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 7.7, 8.0, master (9.0)
>
> Attachments: SOLR-13156.patch, SOLR-13156.patch
>
>
> When I'm doing limiting facet keys with \{!terms} it doesn't take into
> account sorting.
> First query not limiting the facet keys:
> {{facet.field=title=count=on=*:*}}
> Response as expected:
> {{"facet_counts":\{ "facet_queries":{}, "facet_fields":\{ "title":[
> "book2",3, "book1",2, "book3",1]}, "facet_ranges":{}, "facet_intervals":{},
> "facet_heatmaps":{}
>
> When doing it with limiting:
> {{facet.field=\{!terms=Book3,Book2,Book1}title=count=on=*:*}}
> I'm getting the exact order of how I list terms:
> {{"facet_counts":\{ "facet_queries":{}, "facet_fields":\{ "title":[
> "Book3",1, "Book2",3, "Book1",2]}, "facet_ranges":{}, "facet_intervals":{},
> "facet_heatmaps":{}
> I've looked at the code, and it's clearly an issue there:
>
> org.apache.solr.request.SimpleFacets#getListedTermCounts
>
> {{for (String term : terms) {}}
> {{ int count = searcher.numDocs(ft.getFieldQuery(null, sf, term),
> parsed.docs);}}
> {{ res.add(term, count);}}
> {{}}}
>
> it's just basically iterating over terms and don't do any sorting at all.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-8.x-Windows (64bit/jdk-12-ea+32) - Build # 58 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/58/ Java: 64bit/jdk-12-ea+32 -XX:+UseCompressedOops -XX:+UseG1GC No tests ran. Build Log: [...truncated 14 lines...] ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://gitbox.apache.org/repos/asf/lucene-solr.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:904) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1144) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1175) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1816) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Caused by: hudson.plugins.git.GitException: org.eclipse.jgit.api.errors.TransportException: https://gitbox.apache.org/repos/asf/lucene-solr.git: cannot open git-upload-pack at org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:628) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:161) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:154) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to Windows VBOX at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at hudson.remoting.Channel.call(Channel.java:957) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146) at sun.reflect.GeneratedMethodAccessor786.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132) at com.sun.proxy.$Proxy85.execute(Unknown Source) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:902) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1144) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1175) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1816) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Caused by: org.eclipse.jgit.api.errors.TransportException: https://gitbox.apache.org/repos/asf/lucene-solr.git: cannot open git-upload-pack at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:254) at org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:626) ... 10 more Caused by: org.eclipse.jgit.errors.TransportException: https://gitbox.apache.org/repos/asf/lucene-solr.git: cannot open git-upload-pack at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:600) at org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:362) at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:138) at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:124) at
[jira] [Commented] (SOLR-13156) Limiting field facet with certain terms via {!terms} not taking into account sorting
[
https://issues.apache.org/jira/browse/SOLR-13156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777674#comment-16777674
]
Mikhail Khludnev commented on SOLR-13156:
-
bq. but facet.limit, facet.offset does not work. What's wrong?
No one promise they will. They deserve a separate issue, patches are welcome.
> Limiting field facet with certain terms via {!terms} not taking into account
> sorting
>
>
> Key: SOLR-13156
> URL: https://issues.apache.org/jira/browse/SOLR-13156
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Reporter: Konstantin Perikov
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 7.7, 8.0, master (9.0)
>
> Attachments: SOLR-13156.patch, SOLR-13156.patch
>
>
> When I'm doing limiting facet keys with \{!terms} it doesn't take into
> account sorting.
> First query not limiting the facet keys:
> {{facet.field=title=count=on=*:*}}
> Response as expected:
> {{"facet_counts":\{ "facet_queries":{}, "facet_fields":\{ "title":[
> "book2",3, "book1",2, "book3",1]}, "facet_ranges":{}, "facet_intervals":{},
> "facet_heatmaps":{}
>
> When doing it with limiting:
> {{facet.field=\{!terms=Book3,Book2,Book1}title=count=on=*:*}}
> I'm getting the exact order of how I list terms:
> {{"facet_counts":\{ "facet_queries":{}, "facet_fields":\{ "title":[
> "Book3",1, "Book2",3, "Book1",2]}, "facet_ranges":{}, "facet_intervals":{},
> "facet_heatmaps":{}
> I've looked at the code, and it's clearly an issue there:
>
> org.apache.solr.request.SimpleFacets#getListedTermCounts
>
> {{for (String term : terms) {}}
> {{ int count = searcher.numDocs(ft.getFieldQuery(null, sf, term),
> parsed.docs);}}
> {{ res.add(term, count);}}
> {{}}}
>
> it's just basically iterating over terms and don't do any sorting at all.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13227) Remove slow other-range checks from RangeFacetProcessor
[ https://issues.apache.org/jira/browse/SOLR-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777672#comment-16777672 ] Mikhail Khludnev commented on SOLR-13227: - Thanks. I'll take care. > Remove slow other-range checks from RangeFacetProcessor > --- > > Key: SOLR-13227 > URL: https://issues.apache.org/jira/browse/SOLR-13227 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: faceting >Affects Versions: 7.5, 8.0, master (9.0) >Reporter: Nikolay Khitrin >Assignee: Mikhail Khludnev >Priority: Major > Attachments: SOLR-13227.patch, SOLR-13227.patch, profiler.png > > > RangeFacetProcessor.getFacetRangeCountsDocValues is checking every range name > over FacetParams.FacetRangeOther enum via catching IllegalArgumentException > from valueOf, rethrowing it as SolrException and picking a branch based on > the presence of last one. > It is very slow due to enormous cost of failed Enum.valueOf. > Also RangeFacetRequest.FacetRange already have a field with parsed > FacetRangeOther value for special ranges or null for ordinary ones. > Replacing this with simple null check leads to huge performance boost here. > In real case with a lot of intervals (~2000) whole QTime is reduced from > 300ms to 50ms by this patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776899#comment-16776899
]
Karl Wright edited comment on LUCENE-8696 at 2/26/19 7:24 AM:
--
Reviewing the solid, and what the edge points *should* be:
minx, maxx: -0.7731590077686981, 1.0011188539924791
miny, maxy: 0.9519964046486451, 1.0011188539924791
minz, maxz: -0.9977622932859775, 0.9977599768255027
The minz/maxz planes might touch the world at the poles, but probably don't.
The maxx plane might touch the world at the max X pole.
The minx plane definitely slices the world, so it should generate at least one
point.
The maxy plane might touch the world at the max Y pole.
The miny plane slices the world, so it should generate at least one point.
This is the debugging output:
{code}
[junit4] 2> notableMinXPoints=[] notableMaxXPoints=[] notableMinYPoints=[]
notableMaxYPoints=[] notableMinZPoints=[] notableMaxZPoints=[]
[junit4] 2> minXEdges=[] maxXEdges=[] minYEdges=[[X=0.0,
Y=0.9519964046486451, Z=-0.30870622678085735]] maxYEdges=[[X=-0.0,
Y=1.0011188539924791, Z=0.0]] minZEdges=[] maxZEdges=[]
{code}
"Notable points" are places where the plane intersections also intersect the
world. There are none of these, as expected.
The planes that intersect the world are minY and maxY. We do *not* see
intersections for minX, though, and we expected to. That's got to be
researched to figure out why. It may be because the intersection is actually
outside the solid bounds as determined by the Y plane.
So the question becomes whether the line (-0.7731590077686981,
0.9519964046486451, t) ever can go through the world? We can surely determine
that by picking value 0, and computing the distance to the origin:
sqrt(x^2 + y^2 + 0) = 1.2264061340998847885343642874005, which is indeed off
the surface. So the points look reasonable.
was (Author: kwri...@metacarta.com):
Reviewing the solid, and what the edge points *should* be:
minx, maxx: -0.7731590077686981, 1.0011188539924791
miny, maxy: 0.9519964046486451, 1.0011188539924791
minz, maxz: -0.9977622932859775, 0.9977599768255027
The minz/maxz planes might touch the world at the poles, but probably don't.
The maxx plane might touch the world at the max X pole.
The minx plane definitely slices the world, so it should generate at least one
point.
The maxy plane might touch the world at the max Y pole.
The miny plane slices the world, so it should generate at least one point.
This is the debugging output:
{code}
[junit4] 2> notableMinXPoints=[] notableMaxXPoints=[] notableMinYPoints=[]
notableMaxYPoints=[] notableMinZPoints=[] notableMaxZPoints=[]
[junit4] 2> minXEdges=[] maxXEdges=[] minYEdges=[[X=0.0,
Y=0.9519964046486451, Z=-0.30870622678085735]] maxYEdges=[[X=-0.0,
Y=1.0011188539924791, Z=0.0]] minZEdges=[] maxZEdges=[]
{code}
"Notable points" are places where the plane intersections also intersect the
world. There are none of these, as expected.
The planes that intersect the world are minY and maxY. We do *not* see
intersections for minX, though, and we expected to. That's got to be
researched to figure out why. It may be because the intersection is actually
outside the solid bounds as determined by the Y plane.
Out of time for the moment though.
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
[jira] [Updated] (SOLR-13242) RegexReplaceProcessorFactory not making accurate replacement
[
https://issues.apache.org/jira/browse/SOLR-13242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edwin Yeo Zheng Lin updated SOLR-13242:
---
Description:
We are using the RegexReplaceProcessorFactory, and have tried with all of the
following configurations in solrconfig.xml:
content
(\s*\r?\n)\{2,}
true
content
([ \t]*\r?\n)\{2,}
true
content
(\s*\n)\{2,}
true
content
(\n\s*)\{2,}
true
The regex pattern of (\s*\r?\n)\{2,}, ([ \t]*\r?\n)\{2,}, (\s*\n)\{2,} and
(\n\s*)\{2,} are working perfectly in [regex101.com|http://regex101.com/], in
which all the \n will be replaced by only two
However, in Solr, there are cases (in Example 2 and 3 below) that has four
in a row. This should not be the case, as we have already set it to replace by
two regardless of how many \n are there in a row.
*Example 1: The sentence that the above regex pattern is working correctly*
*Original content in EML [file:*|file://%2A/]
Dear Sir,
I am terminating
*Original content:* Dear Sir, \n\n \n \n\n I am terminating
*Index content:* Dear Sir, I am terminating
*Example 2: The sentence that the above regex pattern is partially working (as
you can see, instead of 2 , there are 4 )*
*Original content in EML [file:*|file://%2A/]
_exalted_
_Psalm 89:17_
3 Choa Chu Kang Avenue 4
*Original content:* exalted \n \n\n Psalm 89:17 \n\n \n\n 3 Choa Chu
Kang Avenue 4, Singapore
*Index content:* exalted Psalm 89:17 3 Choa Chu
Kang Avenue 4, Singapore
*Example 3: The sentence that the above regex pattern is partially working (as
you can see, instead of 2 , there are 4 )*
*Original content in EML [file:*|file://%2A/]
[http://www.concordpri.moe.edu.sg/]
On Tue, Dec 18, 2018 at 10:07 AM
*Original content:* [http://www.concordpri.moe.edu.sg/] \n\n \n\n \n \n\n
\n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n\n \n\n\n On Tue, Dec 18, 2018 at
10:07 AM
*Index content:* [http://www.concordpri.moe.edu.sg/] On
Tue, Dec 18, 2018 at 10:07 AM
was:
We are using the RegexReplaceProcessorFactory, and have tried with all of the
following configurations in solrconfig.xml:
content
([ \t]*\r?\n)\{2,}
true
content
(\s*\n)\{2,}
true
content
(\n\s*)\{2,}
true
The regex pattern of ([ \t]*\r?\n)\{2,}, (\s*\n)\{2,} and (\n\s*)\{2,} are
working perfectly in [regex101.com|http://regex101.com/], in which all the \n
will be replaced by only two
However, in Solr, there are cases (in Example 2 and 3 below) that has four
in a row. This should not be the case, as we have already set it to replace by
two regardless of how many \n are there in a row.
*Example 1: The sentence that the above regex pattern is working correctly*
*Original content in EML [file:*|file://%2A/]
Dear Sir,
I am terminating
*Original content:* Dear Sir, \n\n \n \n\n I am terminating
*Index content:* Dear Sir, I am terminating
*Example 2: The sentence that the above regex pattern is partially working (as
you can see, instead of 2 , there are 4 )*
*Original content in EML [file:*|file://%2A/]
_exalted_
_Psalm 89:17_
3 Choa Chu Kang Avenue 4
*Original content:* exalted \n \n\n Psalm 89:17 \n\n \n\n 3 Choa Chu
Kang Avenue 4, Singapore
*Index content:* exalted Psalm 89:17 3 Choa Chu
Kang Avenue 4, Singapore
*Example 3: The sentence that the above regex pattern is partially working (as
you can see, instead of 2 , there are 4 )*
*Original content in EML [file:*|file://%2A/]
[http://www.concordpri.moe.edu.sg/]
On Tue, Dec 18, 2018 at 10:07 AM
*Original content:* [http://www.concordpri.moe.edu.sg/] \n\n \n\n \n \n\n
\n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n\n \n\n\n On Tue, Dec 18, 2018 at
10:07 AM
*Index content:* [http://www.concordpri.moe.edu.sg/] On
Tue, Dec 18, 2018 at 10:07 AM
> RegexReplaceProcessorFactory not making accurate replacement
>
>
> Key: SOLR-13242
> URL: https://issues.apache.org/jira/browse/SOLR-13242
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6, 7.7
>Reporter: Edwin Yeo Zheng Lin
>Priority: Major
> Labels: regex, solr
>
> We are using the RegexReplaceProcessorFactory, and have tried with all of the
> following configurations in solrconfig.xml:
>
>
> content
> (\s*\r?\n)\{2,}
>
> true
>
>
> content
> ([ \t]*\r?\n)\{2,}
>
> true
>
>
> content
> (\s*\n)\{2,}
>
> true
>
>
> content
> (\n\s*)\{2,}
>
> true
>
>
> The regex
[JENKINS] Lucene-Solr-BadApples-master-Linux (32bit/jdk1.8.0_172) - Build # 168 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/168/ Java: 32bit/jdk1.8.0_172 -server -XX:+UseSerialGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.search.TestStandardQParsers Error Message: 1 thread leaked from SUITE scope at org.apache.solr.search.TestStandardQParsers: 1) Thread[id=14, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-TestStandardQParsers] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.search.TestStandardQParsers: 1) Thread[id=14, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-TestStandardQParsers] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([BE2549A11F0DC7A0]:0) FAILED: junit.framework.TestSuite.org.apache.solr.search.TestStandardQParsers Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=14, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-TestStandardQParsers] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=14, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-TestStandardQParsers] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([BE2549A11F0DC7A0]:0) FAILED: junit.framework.TestSuite.org.apache.solr.search.TestStandardQParsers Error Message: 1 thread leaked from SUITE scope at org.apache.solr.search.TestStandardQParsers: 1) Thread[id=14, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-TestStandardQParsers] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159)
[JENKINS] Solr-reference-guide-master - Build # 14037 - Failure
Build: https://builds.apache.org/job/Solr-reference-guide-master/14037/ Log: Started by timer [EnvInject] - Loading node environment variables. Building remotely on websites1 (git-websites svn-websites) in workspace /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master No credentials specified > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 Fetching upstream changes from https://gitbox.apache.org/repos/asf/lucene-solr.git > git --version # timeout=10 > git fetch --tags --progress > https://gitbox.apache.org/repos/asf/lucene-solr.git > +refs/heads/*:refs/remotes/origin/* ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://gitbox.apache.org/repos/asf/lucene-solr.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1810) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress https://gitbox.apache.org/repos/asf/lucene-solr.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: stderr: fatal: unable to access 'https://gitbox.apache.org/repos/asf/lucene-solr.git/': gnutls_handshake() failed: Error in the pull function. at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2042) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1761) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:72) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:442) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93) at java.lang.Thread.run(Thread.java:748) Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from 37.48.69.226/37.48.69.226:45760 at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at hudson.remoting.Channel.call(Channel.java:955) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146) at sun.reflect.GeneratedMethodAccessor845.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132) at com.sun.proxy.$Proxy115.execute(Unknown Source) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from defaulting to async logging
[ https://issues.apache.org/jira/browse/SOLR-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777620#comment-16777620 ] Erick Erickson commented on SOLR-13268: --- H2. On a very quick look at failing tests, every one of them extends LuceneTestCase. I admit I only looked at 4-5 recent failures, but still intriguing. Still, requiring that Solr tests derive from SolrTestCaseJ4 due to a poorly understood issue with log4j smells, really badly... It does seem like a fat clue though. > Clean up any test failures resulting from defaulting to async logging > - > > Key: SOLR-13268 > URL: https://issues.apache.org/jira/browse/SOLR-13268 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13268.patch > > Time Spent: 40m > Remaining Estimate: 0h > > This is a catch-all for test failures due to the async logging changes. So > far, the I see a couple failures on JDK13 only. I'll collect a "starter set" > here, these are likely systemic, once the root cause is found/fixed, then > others are likely fixed as well. > JDK13: > ant test -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV > -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8 > ant test -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk > -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from defaulting to async logging
[ https://issues.apache.org/jira/browse/SOLR-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777613#comment-16777613 ] Erick Erickson commented on SOLR-13268: --- Hmmm, SolrTestCaseJ4 has a LoggerFactory.getLogger in it. If the first test case extends SolrTestCaseJ4 rather than LuceneTestCase, then that would be consistent with your theory. So maybe my initial fixes where I added the shutdown to SolrTestCaseJ4 then extended from SolrTestCaseJ4 rather than LuceneTestCase was coincidental and that extending that class _also_ defined a logger which was the thing that actually made the difference. Making all Solr test cases extend SolrTestCaseJ4 seems overkill, but perhaps there's something we could add to LuceneTestCase? I'm thinking that the shutdown process would be sensitive to a logger being defined (or not). But I admit I have no idea _how_ to make that happen. But that would give the Lucene devs heartburn, Lucene doesn't use logging. H2. Is it really that onerous to require that test cases extend SolrTestCaseJ4 rather than LuceneTestCase? > Clean up any test failures resulting from defaulting to async logging > - > > Key: SOLR-13268 > URL: https://issues.apache.org/jira/browse/SOLR-13268 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13268.patch > > Time Spent: 40m > Remaining Estimate: 0h > > This is a catch-all for test failures due to the async logging changes. So > far, the I see a couple failures on JDK13 only. I'll collect a "starter set" > here, these are likely systemic, once the root cause is found/fixed, then > others are likely fixed as well. > JDK13: > ant test -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV > -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8 > ant test -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk > -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] dsmiley commented on a change in pull request #549: WIP:SOLR-13129
dsmiley commented on a change in pull request #549: WIP:SOLR-13129 URL: https://github.com/apache/lucene-solr/pull/549#discussion_r260127695 ## File path: solr/solr-ref-guide/src/other-parsers.adoc ## @@ -24,7 +24,7 @@ Many of these parsers are expressed the same way as <>. +There are two query parsers that support block joins. These parsers allow indexing and searching for relational content that has been <>. Review comment: I think we should link to the indexed side page because we're talking about that. This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] dsmiley commented on a change in pull request #549: WIP:SOLR-13129
dsmiley commented on a change in pull request #549: WIP:SOLR-13129 URL: https://github.com/apache/lucene-solr/pull/549#discussion_r260127485 ## File path: solr/solr-ref-guide/src/searching-nested-documents.adoc ## @@ -0,0 +1,202 @@ += Searching Nested Child Documents +// 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. + +This section exposes potential techniques which can be used for searching deeply nested documents, Review comment: With a split content (index & search), I think it's quite important to link to each other. So here at the start we need to link back to the indexing side. On the index side page, somehow link to the search side -- perhaps at the start of that page too. This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] dsmiley commented on a change in pull request #549: WIP:SOLR-13129
dsmiley commented on a change in pull request #549: WIP:SOLR-13129 URL: https://github.com/apache/lucene-solr/pull/549#discussion_r260127323 ## File path: solr/solr-ref-guide/src/searching.adoc ## @@ -27,7 +27,8 @@ realtime-get, + exporting-result-sets, + parallel-sql-interface, + - analytics + analytics, + Review comment: You've placed this new page at the end here but it feels more important than that. Any way I have no real suggestion here on where to place it; there are _many_ pages under Search and there isn't much of an organization. This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] dsmiley commented on a change in pull request #549: WIP:SOLR-13129
dsmiley commented on a change in pull request #549: WIP:SOLR-13129 URL: https://github.com/apache/lucene-solr/pull/549#discussion_r260126333 ## File path: solr/solr-ref-guide/src/index.adoc ## @@ -1,5 +1,5 @@ = Apache Solr Reference Guide -:page-children: about-this-guide, getting-started, deployment-and-operations, using-the-solr-administration-user-interface, documents-fields-and-schema-design, understanding-analyzers-tokenizers-and-filters, indexing-and-basic-data-operations, searching, nested-documents, streaming-expressions, solrcloud, legacy-scaling-and-distribution, the-well-configured-solr-instance, monitoring-solr, securing-solr, client-apis, further-assistance, solr-glossary, errata, how-to-contribute +:page-children: about-this-guide, getting-started, deployment-and-operations, using-the-solr-administration-user-interface, documents-fields-and-schema-design, understanding-analyzers-tokenizers-and-filters, indexing-and-basic-data-operations, searching, indexing-nested-documents, streaming-expressions, solrcloud, legacy-scaling-and-distribution, the-well-configured-solr-instance, monitoring-solr, securing-solr, client-apis, further-assistance, solr-glossary, errata, how-to-contribute Review comment: No; this shouldn't be top-level. the indexing one would go _under_ "indexing-and-basic-data-operations" (and thus on that page). This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk1.8.0_172) - Build # 206 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/206/ Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=4987, name=Lucene Merge Thread #1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=4987, name=Lucene Merge Thread #1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at __randomizedtesting.SeedInfo.seed([87F61387FC4F479B:FA22C5D52B32A63]:0) Caused by: org.apache.lucene.index.MergePolicy$MergeException: java.lang.IllegalStateException: this writer hit an unrecoverable error; cannot complete merge at __randomizedtesting.SeedInfo.seed([87F61387FC4F479B]:0) at org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:704) at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:684) Caused by: java.lang.IllegalStateException: this writer hit an unrecoverable error; cannot complete merge at org.apache.lucene.index.IndexWriter.commitMerge(IndexWriter.java:3877) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4615) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:4054) at org.apache.solr.update.SolrIndexWriter.merge(SolrIndexWriter.java:196) at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:625) at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:662) Caused by: java.lang.OutOfMemoryError: Java heap space at org.apache.lucene.util.bkd.HeapPointWriter.(HeapPointWriter.java:40) at org.apache.lucene.util.bkd.BKDWriter.(BKDWriter.java:184) at org.apache.lucene.codecs.lucene60.Lucene60PointsWriter.writeField(Lucene60PointsWriter.java:101) at org.apache.lucene.codecs.asserting.AssertingPointsFormat$AssertingPointsWriter.writeField(AssertingPointsFormat.java:137) at org.apache.lucene.index.PointValuesWriter.flush(PointValuesWriter.java:188) at org.apache.lucene.index.DefaultIndexingChain.writePoints(DefaultIndexingChain.java:217) at org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:143) at org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:469) at org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:554) at org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:719) at org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:3197) at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3442) at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3407) at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:677) at org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:102) at org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:68) at org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalCommit(DistributedUpdateProcessor.java:2027) at org.apache.solr.update.processor.DistributedUpdateProcessor.processCommit(DistributedUpdateProcessor.java:1974) at org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processCommit(LogUpdateProcessorFactory.java:160) at org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandlerUtils.java:69) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:62) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2565) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:164) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) Build Log: [...truncated 13177
[JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 31 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/31/ No tests ran. Build Log: [...truncated 23468 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2477 links (2023 relative) to 3301 anchors in 249 files [echo] Validated Links & Anchors via: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked [untar] Expanding: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/solr-8.1.0.tgz into /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure:
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-10.0.1) - Build # 1005 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/1005/ Java: 64bit/jdk-10.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC 4 tests failed. FAILED: org.apache.solr.cloud.ActionThrottleTest.testBasics Error Message: 986ms Stack Trace: java.lang.AssertionError: 986ms at __randomizedtesting.SeedInfo.seed([BCDE1A72CD7A5427:8106B45EF5940A57]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.solr.cloud.ActionThrottleTest.testBasics(ActionThrottleTest.java:87) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.solr.cloud.LeaderTragicEventTest.test Error Message: Failed while waiting for active collection Timeout waiting to see state for collection=collection1 :null Live Nodes: [127.0.0.1:62240_solr, 127.0.0.1:62243_solr] Last available state: null Stack Trace: java.lang.RuntimeException: Failed while waiting for active collection Timeout waiting to see state for
[GitHub] dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
URL: https://github.com/apache/lucene-solr/pull/581#discussion_r260060558
##
File path:
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/MultiTermHighlighting.java
##
@@ -17,180 +17,124 @@
package org.apache.lucene.search.uhighlight;
import java.util.ArrayList;
-import java.util.Arrays;
-import java.util.Collection;
import java.util.List;
-import java.util.function.Function;
import java.util.function.Predicate;
+import java.util.function.Supplier;
-import org.apache.lucene.queries.function.FunctionScoreQuery;
-import org.apache.lucene.search.AutomatonQuery;
import org.apache.lucene.search.BooleanClause;
-import org.apache.lucene.search.BooleanQuery;
-import org.apache.lucene.search.BoostQuery;
-import org.apache.lucene.search.ConstantScoreQuery;
-import org.apache.lucene.search.DisjunctionMaxQuery;
-import org.apache.lucene.search.FuzzyQuery;
import org.apache.lucene.search.Query;
-import org.apache.lucene.search.spans.SpanBoostQuery;
-import org.apache.lucene.search.spans.SpanMultiTermQueryWrapper;
-import org.apache.lucene.search.spans.SpanNearQuery;
-import org.apache.lucene.search.spans.SpanNotQuery;
-import org.apache.lucene.search.spans.SpanOrQuery;
-import org.apache.lucene.search.spans.SpanPositionCheckQuery;
+import org.apache.lucene.search.QueryVisitor;
+import org.apache.lucene.search.spans.SpanQuery;
import org.apache.lucene.util.UnicodeUtil;
import org.apache.lucene.util.automaton.Automata;
import org.apache.lucene.util.automaton.Automaton;
import org.apache.lucene.util.automaton.ByteRunAutomaton;
import org.apache.lucene.util.automaton.CharacterRunAutomaton;
-import org.apache.lucene.util.automaton.LevenshteinAutomata;
import org.apache.lucene.util.automaton.Operations;
/**
* Support for highlighting multi-term queries.
*
* @lucene.internal
*/
-class MultiTermHighlighting {
+final class MultiTermHighlighting {
private MultiTermHighlighting() {
}
/**
* Extracts MultiTermQueries that match the provided field predicate.
* Returns equivalent automata that will match terms.
*/
- public static CharacterRunAutomaton[] extractAutomata(Query query,
-Predicate
fieldMatcher,
-boolean lookInSpan,
-Function> preRewriteFunc) {
-// TODO Lucene needs a Query visitor API! LUCENE-3041
-
-List list = new ArrayList<>();
-Collection customSubQueries = preRewriteFunc.apply(query);
-if (customSubQueries != null) {
- for (Query sub : customSubQueries) {
-list.addAll(Arrays.asList(extractAutomata(sub, fieldMatcher,
lookInSpan, preRewriteFunc)));
- }
-} else if (query instanceof BooleanQuery) {
- for (BooleanClause clause : (BooleanQuery) query) {
-if (!clause.isProhibited()) {
- list.addAll(Arrays.asList(extractAutomata(clause.getQuery(),
fieldMatcher, lookInSpan, preRewriteFunc)));
-}
- }
-} else if (query instanceof ConstantScoreQuery) {
- list.addAll(Arrays.asList(extractAutomata(((ConstantScoreQuery)
query).getQuery(), fieldMatcher, lookInSpan,
- preRewriteFunc)));
-} else if (query instanceof BoostQuery) {
- list.addAll(Arrays.asList(extractAutomata(((BoostQuery)
query).getQuery(), fieldMatcher, lookInSpan,
- preRewriteFunc)));
-} else if (query instanceof FunctionScoreQuery) {
- list.addAll(Arrays.asList(extractAutomata(((FunctionScoreQuery)
query).getWrappedQuery(), fieldMatcher,
- lookInSpan, preRewriteFunc)));
-} else if (query instanceof DisjunctionMaxQuery) {
- for (Query sub : ((DisjunctionMaxQuery) query).getDisjuncts()) {
-list.addAll(Arrays.asList(extractAutomata(sub, fieldMatcher,
lookInSpan, preRewriteFunc)));
- }
-} else if (lookInSpan && query instanceof SpanOrQuery) {
- for (Query sub : ((SpanOrQuery) query).getClauses()) {
-list.addAll(Arrays.asList(extractAutomata(sub, fieldMatcher,
lookInSpan, preRewriteFunc)));
+ static CharacterRunAutomaton[] extractAutomata(Query query,
Predicate fieldMatcher, boolean lookInSpan) {
+
+AutomataCollector collector = new AutomataCollector(fieldMatcher,
lookInSpan);
+query.visit(collector);
+return collector.runAutomata.toArray(new CharacterRunAutomaton[0]);
+ }
+
+ private static class AutomataCollector extends QueryVisitor {
+
+List runAutomata = new ArrayList<>();
+final boolean lookInSpan;
+final Predicate fieldMatcher;
+
+private AutomataCollector(Predicate fieldMatcher, boolean
lookInSpan) {
+ this.lookInSpan = lookInSpan;
+ this.fieldMatcher = fieldMatcher;
+}
+
+@Override
+public QueryVisitor getSubVisitor(BooleanClause.Occur occur, Query parent)
{
+ if (lookInSpan == false && parent
[GitHub] dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
URL: https://github.com/apache/lucene-solr/pull/581#discussion_r260057814
##
File path: lucene/core/src/java/org/apache/lucene/search/AutomatonQuery.java
##
@@ -151,7 +151,12 @@ public String toString(String field) {
buffer.append("}");
return buffer.toString();
}
-
+
+ @Override
+ public void visit(QueryVisitor visitor) {
+visitor.matchesAutomaton(this, field, automatonIsBinary, () -> automaton);
Review comment:
maybe method reference to getAutomaton instead?
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
URL: https://github.com/apache/lucene-solr/pull/581#discussion_r260057419
##
File path: lucene/core/src/java/org/apache/lucene/search/TermInSetQuery.java
##
@@ -135,6 +138,20 @@ private boolean equalsTo(TermInSetQuery other) {
termData.equals(other.termData);
}
+ @Override
+ public void visit(QueryVisitor visitor) {
+visitor.matchesAutomaton(this, field, true, this::toAutomaton);
Review comment:
maybe comment as to why this approach is taken vs looping through the terms.
I assume it's kind of a hint that avoids highlighting. BTW may want to put a
comment to https://issues.apache.org/jira/browse/LUCENE-3893 which is kinda
related and re-enforces the notion of TermInSetQuery as AutomatonQuery
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
URL: https://github.com/apache/lucene-solr/pull/581#discussion_r260121391
##
File path: lucene/core/src/test/org/apache/lucene/search/TestQueryVisitor.java
##
@@ -0,0 +1,226 @@
+/*
+ * 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.lucene.search;
+
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.Comparator;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+
+import org.apache.lucene.index.Term;
+import org.apache.lucene.search.spans.SpanNearQuery;
+import org.apache.lucene.search.spans.SpanQuery;
+import org.apache.lucene.search.spans.SpanTermQuery;
+import org.apache.lucene.util.LuceneTestCase;
+
+import static org.hamcrest.CoreMatchers.equalTo;
+
+public class TestQueryVisitor extends LuceneTestCase {
+
+ private static final Query query = new BooleanQuery.Builder()
Review comment:
Can you show a BoostQuery wrapping a BooleanQuery that has a BoostQuery
around a TermQuery :-). Your test below would then be able to show you can do
the inherited multiplication.
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
URL: https://github.com/apache/lucene-solr/pull/581#discussion_r260058172
##
File path: lucene/core/src/java/org/apache/lucene/search/FuzzyTermsEnum.java
##
@@ -152,6 +142,47 @@ public FuzzyTermsEnum(Terms terms, AttributeSource atts,
Term term,
bottomTerm = maxBoostAtt.getCompetitiveTerm();
bottomChanged(null);
}
+
+ /**
+ * Builds an Automaton to match a fuzzy term
+ * @param textthe term to match
+ * @param prefixLengthlength of a required common prefix
+ * @param transpositions {@code true} if transpositions should count as a
single edit
+ * @param maxEditsthe maximum edit distance of matching terms
+ * @return
+ */
+ public static Automaton buildAutomaton(String text, int prefixLength,
boolean transpositions, int maxEdits) {
Review comment:
Very nice; I like this. Perhaps add comment saying wether it's "isBinary"
true/false.
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
URL: https://github.com/apache/lucene-solr/pull/581#discussion_r260116012
##
File path:
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/MultiTermHighlighting.java
##
@@ -17,180 +17,124 @@
package org.apache.lucene.search.uhighlight;
import java.util.ArrayList;
-import java.util.Arrays;
-import java.util.Collection;
import java.util.List;
-import java.util.function.Function;
import java.util.function.Predicate;
+import java.util.function.Supplier;
-import org.apache.lucene.queries.function.FunctionScoreQuery;
-import org.apache.lucene.search.AutomatonQuery;
import org.apache.lucene.search.BooleanClause;
-import org.apache.lucene.search.BooleanQuery;
-import org.apache.lucene.search.BoostQuery;
-import org.apache.lucene.search.ConstantScoreQuery;
-import org.apache.lucene.search.DisjunctionMaxQuery;
-import org.apache.lucene.search.FuzzyQuery;
import org.apache.lucene.search.Query;
-import org.apache.lucene.search.spans.SpanBoostQuery;
-import org.apache.lucene.search.spans.SpanMultiTermQueryWrapper;
-import org.apache.lucene.search.spans.SpanNearQuery;
-import org.apache.lucene.search.spans.SpanNotQuery;
-import org.apache.lucene.search.spans.SpanOrQuery;
-import org.apache.lucene.search.spans.SpanPositionCheckQuery;
+import org.apache.lucene.search.QueryVisitor;
+import org.apache.lucene.search.spans.SpanQuery;
import org.apache.lucene.util.UnicodeUtil;
import org.apache.lucene.util.automaton.Automata;
import org.apache.lucene.util.automaton.Automaton;
import org.apache.lucene.util.automaton.ByteRunAutomaton;
import org.apache.lucene.util.automaton.CharacterRunAutomaton;
-import org.apache.lucene.util.automaton.LevenshteinAutomata;
import org.apache.lucene.util.automaton.Operations;
/**
* Support for highlighting multi-term queries.
*
* @lucene.internal
*/
-class MultiTermHighlighting {
+final class MultiTermHighlighting {
private MultiTermHighlighting() {
}
/**
* Extracts MultiTermQueries that match the provided field predicate.
* Returns equivalent automata that will match terms.
*/
- public static CharacterRunAutomaton[] extractAutomata(Query query,
Review comment:
I see preRewriteFunc has been dropped. I suppose it is now obsolete given
it's primary purpose was to help traverse custom queries. There is a
corresponding part of UnifiedHighlighter where it can be removed.
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
URL: https://github.com/apache/lucene-solr/pull/581#discussion_r260114630
##
File path:
lucene/sandbox/src/java/org/apache/lucene/search/intervals/IntervalQuery.java
##
@@ -147,7 +153,7 @@ public IntervalWeight(Query query, float boost, ScoreMode
scoreMode) {
@Override
public void extractTerms(Set terms) {
Review comment:
I think they are strongly linked, and it's helping drive the effort. Why
separate?
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
dsmiley commented on a change in pull request #581: LUCENE-3041: QueryVisitor
URL: https://github.com/apache/lucene-solr/pull/581#discussion_r260054891
##
File path: lucene/core/src/java/org/apache/lucene/search/QueryVisitor.java
##
@@ -0,0 +1,87 @@
+/*
+ * 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.lucene.search;
+
+import java.util.Set;
+import java.util.function.Supplier;
+
+import org.apache.lucene.index.Term;
+import org.apache.lucene.util.automaton.Automaton;
+
+/**
+ * Allows recursion through a query tree
+ *
+ * @see Query#visit(QueryVisitor)
+ */
+public abstract class QueryVisitor {
+
+ /**
+ * Called by leaf queries that match on a specific term
+ *
+ * @param term the term the query will match on
+ */
+ public void matchesTerm(Term term) { }
+
+ /**
+ * Called by leaf queries that match terms against an Automaton
+ * @param query the leaf query
+ * @param field the field to match against
+ * @param isBinary{@code true} if the Automaton is built to
match against byte[] rather than char[]
+ * @param automatonSupplier a supplier for the built Automaton
+ */
+ public void matchesAutomaton(Query query, String field, boolean isBinary,
Supplier automatonSupplier) {}
Review comment:
The "isBinary" flag is unfortunate; it seems like the Automaton ought to
retain this bit of metadata. It's easy to overlook:
https://issues.apache.org/jira/browse/LUCENE-7719
@jpountz what do you think?
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13156) Limiting field facet with certain terms via {!terms} not taking into account sorting
[
https://issues.apache.org/jira/browse/SOLR-13156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777556#comment-16777556
]
superman369 edited comment on SOLR-13156 at 2/26/19 4:03 AM:
-
h4. @[~mkhludnev], I do a test in solr7.7. Limiting field facet with certain
terms via \{!terms} is work use facet.sort=count, but facet.limit,
facet.offset does not work. What's wrong?
h4. for example:
h4.
facet.field=\{!terms='1453,1452,1248'}location.authorIds=true=1=1,
facet result
h4. "location.authorIds" has 3 items. I think it should have one item.
Could you help me? Thank you very much!
was (Author: superman369):
h4. [~mkhludnev], I do a test in solr7.7. Limiting field facet with certain
terms via \{!terms} is work use facet.sort=count, but facet.limit,
facet.offset does not work. What's wrong?
h4. for example:
h4.
facet.field=\{!terms='1453,1452,1248'}location.authorIds=true=1=1,
facet result
h4. "location.authorIds" has 3 items. I think it should have one item.
Could you help me? Thank you very much!
> Limiting field facet with certain terms via {!terms} not taking into account
> sorting
>
>
> Key: SOLR-13156
> URL: https://issues.apache.org/jira/browse/SOLR-13156
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Reporter: Konstantin Perikov
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 7.7, 8.0, master (9.0)
>
> Attachments: SOLR-13156.patch, SOLR-13156.patch
>
>
> When I'm doing limiting facet keys with \{!terms} it doesn't take into
> account sorting.
> First query not limiting the facet keys:
> {{facet.field=title=count=on=*:*}}
> Response as expected:
> {{"facet_counts":\{ "facet_queries":{}, "facet_fields":\{ "title":[
> "book2",3, "book1",2, "book3",1]}, "facet_ranges":{}, "facet_intervals":{},
> "facet_heatmaps":{}
>
> When doing it with limiting:
> {{facet.field=\{!terms=Book3,Book2,Book1}title=count=on=*:*}}
> I'm getting the exact order of how I list terms:
> {{"facet_counts":\{ "facet_queries":{}, "facet_fields":\{ "title":[
> "Book3",1, "Book2",3, "Book1",2]}, "facet_ranges":{}, "facet_intervals":{},
> "facet_heatmaps":{}
> I've looked at the code, and it's clearly an issue there:
>
> org.apache.solr.request.SimpleFacets#getListedTermCounts
>
> {{for (String term : terms) {}}
> {{ int count = searcher.numDocs(ft.getFieldQuery(null, sf, term),
> parsed.docs);}}
> {{ res.add(term, count);}}
> {{}}}
>
> it's just basically iterating over terms and don't do any sorting at all.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13156) Limiting field facet with certain terms via {!terms} not taking into account sorting
[
https://issues.apache.org/jira/browse/SOLR-13156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777556#comment-16777556
]
superman369 commented on SOLR-13156:
h4. [~mkhludnev], I do a test in solr7.7. Limiting field facet with certain
terms via \{!terms} is work use facet.sort=count, but facet.limit,
facet.offset does not work. What's wrong?
h4. for example:
h4.
facet.field=\{!terms='1453,1452,1248'}location.authorIds=true=1=1,
facet result
h4. "location.authorIds" has 3 items. I think it should have one item.
Could you help me? Thank you very much!
> Limiting field facet with certain terms via {!terms} not taking into account
> sorting
>
>
> Key: SOLR-13156
> URL: https://issues.apache.org/jira/browse/SOLR-13156
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Reporter: Konstantin Perikov
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 7.7, 8.0, master (9.0)
>
> Attachments: SOLR-13156.patch, SOLR-13156.patch
>
>
> When I'm doing limiting facet keys with \{!terms} it doesn't take into
> account sorting.
> First query not limiting the facet keys:
> {{facet.field=title=count=on=*:*}}
> Response as expected:
> {{"facet_counts":\{ "facet_queries":{}, "facet_fields":\{ "title":[
> "book2",3, "book1",2, "book3",1]}, "facet_ranges":{}, "facet_intervals":{},
> "facet_heatmaps":{}
>
> When doing it with limiting:
> {{facet.field=\{!terms=Book3,Book2,Book1}title=count=on=*:*}}
> I'm getting the exact order of how I list terms:
> {{"facet_counts":\{ "facet_queries":{}, "facet_fields":\{ "title":[
> "Book3",1, "Book2",3, "Book1",2]}, "facet_ranges":{}, "facet_intervals":{},
> "facet_heatmaps":{}
> I've looked at the code, and it's clearly an issue there:
>
> org.apache.solr.request.SimpleFacets#getListedTermCounts
>
> {{for (String term : terms) {}}
> {{ int count = searcher.numDocs(ft.getFieldQuery(null, sf, term),
> parsed.docs);}}
> {{ res.add(term, count);}}
> {{}}}
>
> it's just basically iterating over terms and don't do any sorting at all.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13242) RegexReplaceProcessorFactory not making accurate replacement
[
https://issues.apache.org/jira/browse/SOLR-13242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edwin Yeo Zheng Lin updated SOLR-13242:
---
Description:
We are using the RegexReplaceProcessorFactory, and have tried with all of the
following configurations in solrconfig.xml:
content
([ \t]*\r?\n)\{2,}
true
content
(\s*\n)\{2,}
true
content
(\n\s*)\{2,}
true
The regex pattern of ([ \t]*\r?\n)\{2,}, (\s*\n)\{2,} and (\n\s*)\{2,} are
working perfectly in [regex101.com|http://regex101.com/], in which all the \n
will be replaced by only two
However, in Solr, there are cases (in Example 2 and 3 below) that has four
in a row. This should not be the case, as we have already set it to replace by
two regardless of how many \n are there in a row.
*Example 1: The sentence that the above regex pattern is working correctly*
*Original content in EML [file:*|file://%2A/]
Dear Sir,
I am terminating
*Original content:* Dear Sir, \n\n \n \n\n I am terminating
*Index content:* Dear Sir, I am terminating
*Example 2: The sentence that the above regex pattern is partially working (as
you can see, instead of 2 , there are 4 )*
*Original content in EML [file:*|file://%2A/]
_exalted_
_Psalm 89:17_
3 Choa Chu Kang Avenue 4
*Original content:* exalted \n \n\n Psalm 89:17 \n\n \n\n 3 Choa Chu
Kang Avenue 4, Singapore
*Index content:* exalted Psalm 89:17 3 Choa Chu
Kang Avenue 4, Singapore
*Example 3: The sentence that the above regex pattern is partially working (as
you can see, instead of 2 , there are 4 )*
*Original content in EML [file:*|file://%2A/]
[http://www.concordpri.moe.edu.sg/]
On Tue, Dec 18, 2018 at 10:07 AM
*Original content:* [http://www.concordpri.moe.edu.sg/] \n\n \n\n \n \n\n
\n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n\n \n\n\n On Tue, Dec 18, 2018 at
10:07 AM
*Index content:* [http://www.concordpri.moe.edu.sg/] On
Tue, Dec 18, 2018 at 10:07 AM
was:
We are using the RegexReplaceProcessorFactory, and have tried with both of the
following configurations:
content
(\s*\n)\{2,}
content
(\n\s*)\{2,}
The regex pattern of (\s*\n)\{2,} and (\n\s*)\{2,} are working perfectly in
[regex101.com|http://regex101.com/], in which all the \n will be replaced by
only two
However, in Solr, there are cases (in Example 2 and 3 below) that has four
in a row. This should not be the case, as we have already set it to replace by
two regardless of how many \n are there in a row.
*Example 1: The sentence that the above regex pattern is working correctly*
*Original content in EML [file:*|file://%2A/]
Dear Sir,
I am terminating
*Original content:* Dear Sir, \n\n \n \n\n I am terminating
*Index content:* Dear Sir, I am terminating
*Example 2: The sentence that the above regex pattern is partially working (as
you can see, instead of 2 , there are 4 )*
*Original content in EML [file:*|file://%2A/]
_exalted_
_Psalm 89:17_
3 Choa Chu Kang Avenue 4
*Original content:* exalted \n \n\n Psalm 89:17 \n\n \n\n 3 Choa Chu
Kang Avenue 4, Singapore
*Index content:* exalted Psalm 89:17 3 Choa Chu
Kang Avenue 4, Singapore
*Example 3: The sentence that the above regex pattern is partially working (as
you can see, instead of 2 , there are 4 )*
*Original content in EML [file:*|file://%2A/]
[http://www.concordpri.moe.edu.sg/]
On Tue, Dec 18, 2018 at 10:07 AM
*Original content:* [http://www.concordpri.moe.edu.sg/] \n\n \n\n \n \n\n
\n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n\n \n\n\n On Tue, Dec 18, 2018 at
10:07 AM
*Index content:* [http://www.concordpri.moe.edu.sg/] On
Tue, Dec 18, 2018 at 10:07 AM
> RegexReplaceProcessorFactory not making accurate replacement
>
>
> Key: SOLR-13242
> URL: https://issues.apache.org/jira/browse/SOLR-13242
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6, 7.7
>Reporter: Edwin Yeo Zheng Lin
>Priority: Major
> Labels: regex, solr
>
> We are using the RegexReplaceProcessorFactory, and have tried with all of the
> following configurations in solrconfig.xml:
>
>
> content
> ([ \t]*\r?\n)\{2,}
>
> true
>
>
>
> content
> (\s*\n)\{2,}
>
> true
>
>
>
> content
> (\n\s*)\{2,}
>
> true
>
>
> The regex pattern of ([ \t]*\r?\n)\{2,}, (\s*\n)\{2,} and (\n\s*)\{2,} are
> working perfectly in [regex101.com|http://regex101.com/], in which all the \n
> will be replaced by only two
> However, in Solr, there are cases (in Example 2 and 3
[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-12-ea+shipilev-fastdebug) - Build # 3582 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/3582/ Java: 64bit/jdk-12-ea+shipilev-fastdebug -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testSearchRate Error Message: The trigger did not start in time Stack Trace: java.lang.AssertionError: The trigger did not start in time at __randomizedtesting.SeedInfo.seed([A13AF2A7B45074BC:FC72EC2E7B96D2F3]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testSearchRate(TestSimTriggerIntegration.java:1370) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:835) Build Log: [...truncated 14559 lines...] [junit4] Suite: org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration [junit4] 2> 2177452 INFO (SUITE-TestSimTriggerIntegration-seed#[A13AF2A7B45074BC]-worker) []
[JENKINS] Lucene-Solr-SmokeRelease-8.0 - Build # 7 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.0/7/ No tests ran. Build Log: [...truncated 23465 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2465 links (2020 relative) to 3283 anchors in 248 files [echo] Validated Links & Anchors via: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/solr/build/solr.tgz.unpacked [untar] Expanding: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/solr/package/solr-8.0.0.tgz into /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.0/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings ::
[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 30 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/30/ 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.api.collections.ShardSplitTest Error Message: 10 threads leaked from SUITE scope at org.apache.solr.cloud.api.collections.ShardSplitTest: 1) Thread[id=141724, name=qtp1742779890-141724, state=TIMED_WAITING, group=TGRP-ShardSplitTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:392) at org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:656) at org.eclipse.jetty.util.thread.QueuedThreadPool.access$800(QueuedThreadPool.java:46) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:720) at java.lang.Thread.run(Thread.java:748)2) Thread[id=141726, name=qtp1742779890-141726, state=TIMED_WAITING, group=TGRP-ShardSplitTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:392) at org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:656) at org.eclipse.jetty.util.thread.QueuedThreadPool.access$800(QueuedThreadPool.java:46) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:720) at java.lang.Thread.run(Thread.java:748)3) Thread[id=141616, name=qtp1742779890-141616, state=TIMED_WAITING, group=TGRP-ShardSplitTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:392) at org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:656) at org.eclipse.jetty.util.thread.QueuedThreadPool.access$800(QueuedThreadPool.java:46) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:720) at java.lang.Thread.run(Thread.java:748)4) Thread[id=141617, name=Scheduler-2079810312, state=TIMED_WAITING, group=TGRP-ShardSplitTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)5) Thread[id=141610, name=qtp1742779890-141610, state=RUNNABLE, group=TGRP-ShardSplitTest] at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.select(ManagedSelector.java:423) at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:360) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produceTask(EatWhatYouKill.java:357) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:181) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132) at org.eclipse.jetty.io.ManagedSelector$$Lambda$34/855287984.run(Unknown Source) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
[jira] [Commented] (SOLR-12809) Upgrading to a more recent Java (JDK 11?)
[ https://issues.apache.org/jira/browse/SOLR-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777425#comment-16777425 ] Aleck Kulabukhov commented on SOLR-12809: - So is it already decided to recommend OpenJDK for Lucene/Solr? If so, can we can make it official? > Upgrading to a more recent Java (JDK 11?) > - > > Key: SOLR-12809 > URL: https://issues.apache.org/jira/browse/SOLR-12809 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Priority: Major > > JDK 8 will be EOL early next year (except for "premier support"). JDK 9, 10 > and 11 all have issues for Solr and Lucene IIUC. > Also IIUC Oracle will start requiring commercial licenses for 11. > This Jira is to discuss what we want to do going forward. Among the topics: > * Skip straight to 11, skipping 9 and 10? If so how to resolve current > issues? > * How much emphasis on OpenJDK .vs. Oracle's version > * What to do about dependencies that don't work (for whatever reason) with > the version of Java we go with? > * ??? > This may turn into an umbrella Jira with sub-tasks of course. Since JDK 11 > has had a GA release, I'd also like to have a record of where the current > issues are to refer people to. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 51 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/51/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 6 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.search.TestSolrCoreParser Error Message: 1 thread leaked from SUITE scope at org.apache.solr.search.TestSolrCoreParser: 1) Thread[id=12, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-TestSolrCoreParser] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.search.TestSolrCoreParser: 1) Thread[id=12, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-TestSolrCoreParser] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([1385A6FD46415A7F]:0) FAILED: junit.framework.TestSuite.org.apache.solr.search.TestSolrCoreParser Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=12, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-TestSolrCoreParser] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=12, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-TestSolrCoreParser] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([1385A6FD46415A7F]:0) FAILED: junit.framework.TestSuite.org.apache.solr.search.TestSolrCoreParser Error Message: 1 thread leaked from SUITE scope at org.apache.solr.search.TestSolrCoreParser: 1) Thread[id=12, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-TestSolrCoreParser] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at
[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from defaulting to async logging
[
https://issues.apache.org/jira/browse/SOLR-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777391#comment-16777391
]
Kevin Risden commented on SOLR-13268:
-
My guess is the only way this reproduces is if the FIRST test in the test JVM,
doesn't have "LoggerFactory.getLogger(", then there will be a failure. All the
failures I've seen lately have been very early in the test runs.
> Clean up any test failures resulting from defaulting to async logging
> -
>
> Key: SOLR-13268
> URL: https://issues.apache.org/jira/browse/SOLR-13268
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13268.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This is a catch-all for test failures due to the async logging changes. So
> far, the I see a couple failures on JDK13 only. I'll collect a "starter set"
> here, these are likely systemic, once the root cause is found/fixed, then
> others are likely fixed as well.
> JDK13:
> ant test -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV
> -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ant test -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk
> -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from defaulting to async logging
[ https://issues.apache.org/jira/browse/SOLR-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777383#comment-16777383 ] Kevin Risden commented on SOLR-13268: - [~erickerickson] so I played around with this a bit and I don't understand what I am seeing... * BufferStoreTest reproduces with the above seed * BufferStoreTest changed to extend SolrTestCaseJ4 - test passes * So I played around with SolrTestCaseJ4 ** If you comment out the entire file - seed fails (as expected) ** Comment out EVERYTHING except for *** private static final Logger log = LoggerFactory.getLogger(MethodHandles.lookup().lookupClass()); *** Test passes * Revert changes and make only the following change to BufferStoreTest: ** Add "private static final Logger log = LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());" So basically if there is a LoggerFactory.getLogger, the test passes. Otherwise there is an issue with thread hanging. I checked IgnoreLargeDocumentProcessorFactoryTest, and it doesn't extend SolrTestCaseJ4 and doesn't call LoggerFactory. I don't think adding "private static final Logger log = LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());" to tests is the correct answer but it definitely is an interesting finding. > Clean up any test failures resulting from defaulting to async logging > - > > Key: SOLR-13268 > URL: https://issues.apache.org/jira/browse/SOLR-13268 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13268.patch > > Time Spent: 40m > Remaining Estimate: 0h > > This is a catch-all for test failures due to the async logging changes. So > far, the I see a couple failures on JDK13 only. I'll collect a "starter set" > here, these are likely systemic, once the root cause is found/fixed, then > others are likely fixed as well. > JDK13: > ant test -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV > -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8 > ant test -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk > -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 33 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/33/ 1 tests failed. FAILED: org.apache.solr.schema.TestCloudSchemaless.test Error Message: Timeout occurred while waiting response from server at: http://127.0.0.1:40644/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: http://127.0.0.1:40644/collection1 at __randomizedtesting.SeedInfo.seed([B95183B4B5C94F8F:3105BC6E1B352277]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:661) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:256) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:504) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:479) at org.apache.solr.schema.TestCloudSchemaless.test(TestCloudSchemaless.java:116) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 1049 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/1049/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
4 tests failed.
FAILED:
junit.framework.TestSuite.org.apache.solr.cloud.TestMiniSolrCloudClusterSSL
Error Message:
28 threads leaked from SUITE scope at
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL: 1) Thread[id=17497,
name=Scheduler-2022859843, state=TIMED_WAITING,
group=TGRP-TestMiniSolrCloudClusterSSL] at sun.misc.Unsafe.park(Native
Method) at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)2) Thread[id=17467,
name=qtp483621424-17467-acceptor-0@48f609de-ServerConnector@32e66104{SSL,[ssl,
http/1.1]}{127.0.0.1:34731}, state=RUNNABLE,
group=TGRP-TestMiniSolrCloudClusterSSL] at
sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) at
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)
at
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)
at
org.eclipse.jetty.server.ServerConnector.accept(ServerConnector.java:385)
at
org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:648)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
at java.lang.Thread.run(Thread.java:748)3) Thread[id=17484,
name=qtp929601253-17484, state=TIMED_WAITING,
group=TGRP-TestMiniSolrCloudClusterSSL] at sun.misc.Unsafe.park(Native
Method) at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at
org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:392)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:656)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.access$800(QueuedThreadPool.java:46)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:720)
at java.lang.Thread.run(Thread.java:748)4) Thread[id=17466,
name=qtp483621424-17466, state=RUNNABLE,
group=TGRP-TestMiniSolrCloudClusterSSL] at
sun.nio.ch.DevPollArrayWrapper.poll0(Native Method) at
sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223) at
sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:98) at
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) at
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) at
org.eclipse.jetty.io.ManagedSelector$SelectorProducer.select(ManagedSelector.java:423)
at
org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:360)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produceTask(EatWhatYouKill.java:357)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:181)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)
at
org.eclipse.jetty.io.ManagedSelector$$Lambda$35/27573197.run(Unknown Source)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
at java.lang.Thread.run(Thread.java:748)5) Thread[id=17476,
name=qtp1068264180-17476-acceptor-0@6b0cb2ad-ServerConnector@e35b330{SSL,[ssl,
http/1.1]}{127.0.0.1:62698}, state=RUNNABLE,
group=TGRP-TestMiniSolrCloudClusterSSL] at
sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) at
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)
at
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)
at
org.eclipse.jetty.server.ServerConnector.accept(ServerConnector.java:385)
at
[jira] [Commented] (SOLR-13227) Remove slow other-range checks from RangeFacetProcessor
[ https://issues.apache.org/jira/browse/SOLR-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777338#comment-16777338 ] Shalin Shekhar Mangar commented on SOLR-13227: -- +1 LGTM too. > Remove slow other-range checks from RangeFacetProcessor > --- > > Key: SOLR-13227 > URL: https://issues.apache.org/jira/browse/SOLR-13227 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: faceting >Affects Versions: 7.5, 8.0, master (9.0) >Reporter: Nikolay Khitrin >Assignee: Mikhail Khludnev >Priority: Major > Attachments: SOLR-13227.patch, SOLR-13227.patch, profiler.png > > > RangeFacetProcessor.getFacetRangeCountsDocValues is checking every range name > over FacetParams.FacetRangeOther enum via catching IllegalArgumentException > from valueOf, rethrowing it as SolrException and picking a branch based on > the presence of last one. > It is very slow due to enormous cost of failed Enum.valueOf. > Also RangeFacetRequest.FacetRange already have a field with parsed > FacetRangeOther value for special ranges or null for ordinary ones. > Replacing this with simple null check leads to huge performance boost here. > In real case with a lot of intervals (~2000) whole QTime is reduced from > 300ms to 50ms by this patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13074) MoveReplicaHDFSTest leaks threads, falls into an endless loop, logging like crazy
[
https://issues.apache.org/jira/browse/SOLR-13074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777313#comment-16777313
]
Kevin Risden commented on SOLR-13074:
-
Uploaded a new patch that should fix the compilation errors.
> MoveReplicaHDFSTest leaks threads, falls into an endless loop, logging like
> crazy
> -
>
> Key: SOLR-13074
> URL: https://issues.apache.org/jira/browse/SOLR-13074
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Hadoop Integration
>Reporter: Dawid Weiss
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-13074.patch, SOLR-13074.patch
>
>
> This reproduces for me, always (Linux box):
> {code}
> ant test -Dtestcase=MoveReplicaHDFSTest -Dtests.seed=DC1CE772C445A55D
> -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.locale=fr
> -Dtests.timezone=Australia/Tasmania -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
> {code}
> It's the bug in Hadoop I discusse in SOLR-13060 -- one of the threads falls
> into an endless loop when terminated (interrupted). Perhaps we should close
> something cleanly and don't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13227) Remove slow other-range checks from RangeFacetProcessor
[ https://issues.apache.org/jira/browse/SOLR-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777295#comment-16777295 ] Tomás Fernández Löbbe commented on SOLR-13227: -- +1. change LGTM > Remove slow other-range checks from RangeFacetProcessor > --- > > Key: SOLR-13227 > URL: https://issues.apache.org/jira/browse/SOLR-13227 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: faceting >Affects Versions: 7.5, 8.0, master (9.0) >Reporter: Nikolay Khitrin >Assignee: Mikhail Khludnev >Priority: Major > Attachments: SOLR-13227.patch, SOLR-13227.patch, profiler.png > > > RangeFacetProcessor.getFacetRangeCountsDocValues is checking every range name > over FacetParams.FacetRangeOther enum via catching IllegalArgumentException > from valueOf, rethrowing it as SolrException and picking a branch based on > the presence of last one. > It is very slow due to enormous cost of failed Enum.valueOf. > Also RangeFacetRequest.FacetRange already have a field with parsed > FacetRangeOther value for special ranges or null for ordinary ones. > Replacing this with simple null check leads to huge performance boost here. > In real case with a lot of intervals (~2000) whole QTime is reduced from > 300ms to 50ms by this patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 2304 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/2304/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC
2 tests failed.
FAILED: org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic
Error Message:
{} expected:<1> but was:<0>
Stack Trace:
java.lang.AssertionError: {} expected:<1> but was:<0>
at
__randomizedtesting.SeedInfo.seed([FAE0EA92FAFF02D3:511AF787252384FD]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at
org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic(SolrRrdBackendFactoryTest.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
FAILED:
org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest.testCommitWithinOnDelete
Error Message:
expected:<1> but was:<0>
Stack Trace:
junit.framework.AssertionFailedError: expected:<1> but was:<0>
[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from defaulting to async logging
[ https://issues.apache.org/jira/browse/SOLR-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777283#comment-16777283 ] Erick Erickson commented on SOLR-13268: --- Cool, reproduces for me too. I won't be able to look at this at least for the rest of the day. The shutdown bits changed some tests from always failing to passing, but I suspect that it was just masking a problem. Especially since the tests pass with that bit commented out. So I'll probably back those all out... > Clean up any test failures resulting from defaulting to async logging > - > > Key: SOLR-13268 > URL: https://issues.apache.org/jira/browse/SOLR-13268 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13268.patch > > Time Spent: 40m > Remaining Estimate: 0h > > This is a catch-all for test failures due to the async logging changes. So > far, the I see a couple failures on JDK13 only. I'll collect a "starter set" > here, these are likely systemic, once the root cause is found/fixed, then > others are likely fixed as well. > JDK13: > ant test -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV > -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8 > ant test -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk > -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13271) Implement a read-only mode for a collection
Andrzej Bialecki created SOLR-13271: Summary: Implement a read-only mode for a collection Key: SOLR-13271 URL: https://issues.apache.org/jira/browse/SOLR-13271 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 8.x, master (9.0) Reporter: Andrzej Bialecki Assignee: Andrzej Bialecki Fix For: 8.x, master (9.0) Spin-off from SOLR-11127. In some scenarios it's useful to be able to block any updates to a collection, while still being able to search its contents. Currently the scope of this issue is SolrCloud, ie. standalone Solr will not be supported. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-8.0-Linux (64bit/jdk-12-ea+shipilev-fastdebug) - Build # 214 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.0-Linux/214/
Java: 64bit/jdk-12-ea+shipilev-fastdebug -XX:+UseCompressedOops
-XX:+UseConcMarkSweepGC
1 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testSearchRate
Error Message:
last ClusterState: znodeVersion: 6 live nodes:[127.0.0.1:10009_solr,
127.0.0.1:10008_solr]
collections:{collection1=DocCollection(collection1//clusterstate.json/5)={
"replicationFactor":"1", "pullReplicas":"0",
"router":{"name":"compositeId"}, "maxShardsPerNode":"1",
"autoAddReplicas":"false", "nrtReplicas":"2", "tlogReplicas":"0",
"autoCreated":"true", "shards":{"shard1":{ "replicas":{
"core_node1":{ "core":"collection1_shard1_replica_n1",
"SEARCHER.searcher.maxDoc":0, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":10240, "node_name":"127.0.0.1:10008_solr",
"state":"active", "type":"NRT",
"INDEX.sizeInGB":9.5367431640625E-6, "SEARCHER.searcher.numDocs":0},
"core_node2":{ "core":"collection1_shard1_replica_n2",
"SEARCHER.searcher.maxDoc":0, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":10240, "node_name":"127.0.0.1:10009_solr",
"state":"active", "type":"NRT",
"INDEX.sizeInGB":9.5367431640625E-6, "SEARCHER.searcher.numDocs":0}},
"range":"8000-7fff", "state":"active", last coll state:
DocCollection(collection1//clusterstate.json/5)={ "replicationFactor":"1",
"pullReplicas":"0", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false", "nrtReplicas":"2",
"tlogReplicas":"0", "autoCreated":"true", "shards":{"shard1":{
"replicas":{ "core_node1":{
"core":"collection1_shard1_replica_n1", "SEARCHER.searcher.maxDoc":0,
"SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":10240, "node_name":"127.0.0.1:10008_solr",
"state":"active", "type":"NRT",
"INDEX.sizeInGB":9.5367431640625E-6, "SEARCHER.searcher.numDocs":0},
"core_node2":{ "core":"collection1_shard1_replica_n2",
"SEARCHER.searcher.maxDoc":0, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":10240, "node_name":"127.0.0.1:10009_solr",
"state":"active", "type":"NRT",
"INDEX.sizeInGB":9.5367431640625E-6, "SEARCHER.searcher.numDocs":0}},
"range":"8000-7fff", "state":"active"}}}
Stack Trace:
java.util.concurrent.TimeoutException: last ClusterState: znodeVersion: 6
live nodes:[127.0.0.1:10009_solr, 127.0.0.1:10008_solr]
collections:{collection1=DocCollection(collection1//clusterstate.json/5)={
"replicationFactor":"1",
"pullReplicas":"0",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"2",
"tlogReplicas":"0",
"autoCreated":"true",
"shards":{"shard1":{
"replicas":{
"core_node1":{
"core":"collection1_shard1_replica_n1",
"SEARCHER.searcher.maxDoc":0,
"SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":10240,
"node_name":"127.0.0.1:10008_solr",
"state":"active",
"type":"NRT",
"INDEX.sizeInGB":9.5367431640625E-6,
"SEARCHER.searcher.numDocs":0},
"core_node2":{
"core":"collection1_shard1_replica_n2",
"SEARCHER.searcher.maxDoc":0,
"SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":10240,
"node_name":"127.0.0.1:10009_solr",
"state":"active",
"type":"NRT",
"INDEX.sizeInGB":9.5367431640625E-6,
"SEARCHER.searcher.numDocs":0}},
"range":"8000-7fff",
"state":"active", last coll state:
DocCollection(collection1//clusterstate.json/5)={
"replicationFactor":"1",
"pullReplicas":"0",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"2",
"tlogReplicas":"0",
"autoCreated":"true",
"shards":{"shard1":{
"replicas":{
"core_node1":{
"core":"collection1_shard1_replica_n1",
"SEARCHER.searcher.maxDoc":0,
"SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":10240,
"node_name":"127.0.0.1:10008_solr",
"state":"active",
"type":"NRT",
"INDEX.sizeInGB":9.5367431640625E-6,
"SEARCHER.searcher.numDocs":0},
"core_node2":{
"core":"collection1_shard1_replica_n2",
"SEARCHER.searcher.maxDoc":0,
"SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":10240,
"node_name":"127.0.0.1:10009_solr",
"state":"active",
"type":"NRT",
[jira] [Commented] (SOLR-11127) Add a Collections API command to migrate the .system collection schema from Trie-based (pre-7.0) to Points-based (7.0+)
[
https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777262#comment-16777262
]
Andrzej Bialecki commented on SOLR-11127:
--
Implementing a read-only mode for a collection allows us to use a better
solution to this problem:
* create a new unique collection using the new schema, eg.
{{.reindex__}}
* put the source collection in read-only mode. This entails:
** blocking new updates,
** issuing a hard commit
** closing the IndexWriter to make sure there aren't any ongoing background
merges.
* copy all documents from source to the new collection
* create an alias pointing from the source name to the new collection. The new
collection is already in read-write mode by default, and this operation is
atomic.
* optionally delete the original source
In this scenario we never lose the ability to search the source collection, at
the cost of losing the ability to process updates during the reindexing.
BTW. this scenario is applicable to basically any collection, not just the
{{.system}}, with the usual caveats about potentially losing the data from
document fields that can't be retrieved from the source collection.
> Add a Collections API command to migrate the .system collection schema from
> Trie-based (pre-7.0) to Points-based (7.0+)
> ---
>
> Key: SOLR-11127
> URL: https://issues.apache.org/jira/browse/SOLR-11127
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki
>Priority: Blocker
> Labels: numeric-tries-to-points
> Fix For: 8.0
>
>
> SOLR-9 will switch the Trie fieldtypes in the .system collection's schema
> to Points.
> Users with pre-7.0 .system collections will no longer be able to use them
> once Trie fields have been removed (8.0).
> Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to
> automatically convert a Trie-based .system collection to a Points-based one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from defaulting to async logging
[
https://issues.apache.org/jira/browse/SOLR-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777225#comment-16777225
]
Kevin Risden commented on SOLR-13268:
-
Another reproducing seed:
https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/291
{code:java}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=IgnoreLargeDocumentProcessorFactoryTest
-Dtests.seed=FFE5AB53EC0B3896 -Dtests.multiplier=2 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=es-MX -Dtests.timezone=Pacific/Majuro
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 0.00s J2 | IgnoreLargeDocumentProcessorFactoryTest (suite)
<<<
[junit4]> Throwable #1:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE
scope at
org.apache.solr.update.processor.IgnoreLargeDocumentProcessorFactoryTest:
[junit4]>1) Thread[id=13, name=Log4j2-TF-1-AsyncLoggerConfig-1,
state=TIMED_WAITING, group=TGRP-IgnoreLargeDocumentProcessorFactoryTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[junit4]> at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
[junit4]> at
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
[junit4]> at
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
[junit4]> at
com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159)
[junit4]> at
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125)
[junit4]> at java.lang.Thread.run(Thread.java:748)
[junit4]>at
__randomizedtesting.SeedInfo.seed([FFE5AB53EC0B3896]:0)Throwable #2:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie
threads that couldn't be terminated:
[junit4]>1) Thread[id=13, name=Log4j2-TF-1-AsyncLoggerConfig-1,
state=TIMED_WAITING, group=TGRP-IgnoreLargeDocumentProcessorFactoryTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[junit4]> at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
[junit4]> at
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
[junit4]> at
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
[junit4]> at
com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159)
[junit4]> at
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125)
[junit4]> at java.lang.Thread.run(Thread.java:748)
[junit4]>at
__randomizedtesting.SeedInfo.seed([FFE5AB53EC0B3896]:0)
[junit4] Completed [1/844 (1!)] on J2 in 38.09s, 4 tests, 2 errors <<<
FAILURES!
{code}
> Clean up any test failures resulting from defaulting to async logging
> -
>
> Key: SOLR-13268
> URL: https://issues.apache.org/jira/browse/SOLR-13268
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13268.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This is a catch-all for test failures due to the async logging changes. So
> far, the I see a couple failures on JDK13 only. I'll collect a "starter set"
> here, these are likely systemic, once the root cause is found/fixed, then
> others are likely fixed as well.
> JDK13:
> ant test -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV
> -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ant test -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk
> -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from defaulting to async logging
[
https://issues.apache.org/jira/browse/SOLR-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777213#comment-16777213
]
Kevin Risden commented on SOLR-13268:
-
[~erickerickson] Here is a reproducing seed from Uwe's Jenkins. This reproduces
for me locally as well.
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23720/
{code:java}
[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=BufferStoreTest
-Dtests.seed=3EF531368FC72D9F -Dtests.multiplier=3 -Dtests.slow=true
-Dtests.locale=sr-Latn-BA -Dtests.timezone=Africa/Bissau -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 0.00s J1 | BufferStoreTest (suite) <<<
[junit4]> Throwable #1:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE
scope at org.apache.solr.store.blockcache.BufferStoreTest:
[junit4]>1) Thread[id=14, name=Log4j2-TF-1-AsyncLoggerConfig-1,
state=TIMED_WAITING, group=TGRP-BufferStoreTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[junit4]> at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
[junit4]> at
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
[junit4]> at
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
[junit4]> at
com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159)
[junit4]> at
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125)
[junit4]> at java.lang.Thread.run(Thread.java:748)
[junit4]>at
__randomizedtesting.SeedInfo.seed([3EF531368FC72D9F]:0)Throwable #2:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie
threads that couldn't be terminated:
[junit4]>1) Thread[id=14, name=Log4j2-TF-1-AsyncLoggerConfig-1,
state=TIMED_WAITING, group=TGRP-BufferStoreTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[junit4]> at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
[junit4]> at
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
[junit4]> at
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
[junit4]> at
com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159)
[junit4]> at
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125)
[junit4]> at java.lang.Thread.run(Thread.java:748)
[junit4]>at
__randomizedtesting.SeedInfo.seed([3EF531368FC72D9F]:0)
[junit4] Completed [8/844 (1!)] on J1 in 24.65s, 1 test, 2 errors <<<
FAILURES!
{code}
> Clean up any test failures resulting from defaulting to async logging
> -
>
> Key: SOLR-13268
> URL: https://issues.apache.org/jira/browse/SOLR-13268
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13268.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This is a catch-all for test failures due to the async logging changes. So
> far, the I see a couple failures on JDK13 only. I'll collect a "starter set"
> here, these are likely systemic, once the root cause is found/fixed, then
> others are likely fixed as well.
> JDK13:
> ant test -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV
> -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ant test -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk
> -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13035) Utilize solr.data.home / solrDataHome in solr.xml to set all writable files in single directory
[
https://issues.apache.org/jira/browse/SOLR-13035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar reassigned SOLR-13035:
Assignee: Shalin Shekhar Mangar
> Utilize solr.data.home / solrDataHome in solr.xml to set all writable files
> in single directory
> ---
>
> Key: SOLR-13035
> URL: https://issues.apache.org/jira/browse/SOLR-13035
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Amrit Sarkar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Attachments: SOLR-13035.patch, SOLR-13035.patch, SOLR-13035.patch,
> SOLR-13035.patch, SOLR-13035.patch
>
>
> {{solr.data.home}} system property or {{solrDataHome}} in _solr.xml_ is
> already available as per SOLR-6671.
> The writable content in Solr are index files, core properties, and ZK data if
> embedded zookeeper is started in SolrCloud mode. It would be great if all
> writable content can come under the same directory to have separate READ-ONLY
> and WRITE-ONLY directories.
> It can then also solve official docker Solr image issues:
> https://github.com/docker-solr/docker-solr/issues/74
> https://github.com/docker-solr/docker-solr/issues/133
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] mikemccand commented on issue #580: LUCENE-8700: IndexWriter.yield()
mikemccand commented on issue #580: LUCENE-8700: IndexWriter.yield() URL: https://github.com/apache/lucene-solr/pull/580#issuecomment-467133980 > but I wonder if you see any value in adding this concurrent flushing to lots more tests? +1 This might help uncover concurrency bugs in `IndexWriter`. This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13270) SolrJ does not send "Expect: 100-continue" header
[
https://issues.apache.org/jira/browse/SOLR-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777186#comment-16777186
]
Karl Wright commented on SOLR-13270:
I just grepped for it and did not find it explicitly set:
{code}
kawright@1USDKAWRIGHT:/mnt/c/wipgit/lucene4/lucene-solr$ grep -R
"setExpectContinue" . --include "*.java"
kawright@1USDKAWRIGHT:/mnt/c/wipgit/lucene4/lucene-solr$
{code}
I therefore believe it's being set because the RequestConfig is being
overwritten. And, sure enough:
{code}
kawright@1USDKAWRIGHT:/mnt/c/wipgit/lucene4/lucene-solr$ grep -R
"setDefaultRequestConfig" . --include "*.java"
./lucene/replicator/src/java/org/apache/lucene/replicator/http/HttpClientBase.java:
httpc =
HttpClientBuilder.create().setConnectionManager(conMgr).setDefaultRequestConfig(this.defaultConfig).build();
./solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpClientUtil.java:
HttpClientBuilder retBuilder = builder.setDefaultRequestConfig(requestConfig);
kawright@1USDKAWRIGHT:/mnt/c/wipgit/lucene4/lucene-solr$
{code}
> SolrJ does not send "Expect: 100-continue" header
> -
>
> Key: SOLR-13270
> URL: https://issues.apache.org/jira/browse/SOLR-13270
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7
>Reporter: Erlend Garåsen
>Priority: Major
>
> SolrJ does not set the "Expect: 100-continue" header, even though it's
> configured in HttpClient:
> {code:java}
> builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());{code}
> A HttpClient developer has reviewed the code and says we're setting up
> the client correctly, so we have a reason to believe there is a bug in
> SolrJ. It's actually a problem we are facing in ManifoldCF, explained in:
> https://issues.apache.org/jira/browse/CONNECTORS-1564
> The problem can be reproduced by building and running the following small
> Maven project:
> [http://folk.uio.no/erlendfg/solr/missing-header.zip]
> The application runs SolrJ code where the header does not show up and
> HttpClient code where the header is present.
>
> {code:java}
> HttpClientBuilder builder = HttpClients.custom();
> // This should add an Expect: 100-continue header:
> builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());
> HttpClient httpClient = builder.build();
> // Start Solr and create a core named "test".
> String baseUrl = "http://localhost:8983/solr/test;;
> // Test using SolrJ — no expect 100 header
> HttpSolrClient client = new HttpSolrClient.Builder()
> .withHttpClient(httpClient)
> .withBaseSolrUrl(baseUrl).build();
> SolrQuery query = new SolrQuery();
> query.setQuery("*:*");
> client.query(query);
> // Test using HttpClient directly — expect 100 header shows up:
> HttpPost httpPost = new HttpPost(baseUrl);
> HttpEntity entity = new InputStreamEntity(new
> ByteArrayInputStream("test".getBytes()));
> httpPost.setEntity(entity);
> httpClient.execute(httpPost);
> {code}
> When using the last HttpClient test, the expect 100 header appears in
> missing-header.log:
> {noformat}
> http-outgoing-1 >> Expect: 100-continue{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8708) Can we simplify conjunctions of range queries automatically?
[
https://issues.apache.org/jira/browse/LUCENE-8708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777169#comment-16777169
]
Adrien Grand commented on LUCENE-8708:
--
Agreed it'd be nice to have this sort of case optimized as well. I have seen it
happen with automatically-generated queries sometimes.
I'm not going to work actively on it in the near future. Feel free to give it a
try to see how this could look like.
> Can we simplify conjunctions of range queries automatically?
>
>
> Key: LUCENE-8708
> URL: https://issues.apache.org/jira/browse/LUCENE-8708
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> BooleanQuery#rewrite already has some logic to make queries more efficient,
> such as deduplicating filters or rewriting boolean queries that wrap a single
> positive clause to that clause.
> It would be nice to also simplify conjunctions of range queries, so that eg.
> {{foo: [5 TO *] AND foo:[* TO 20]}} would be rewritten to {{foo:[5 TO 20]}}.
> When constructing queries manually or via the classic query parser, it feels
> unnecessary as this is something that the user can fix easily. However if you
> want to implement a query parser that only allows specifying one bound at
> once, such as Gmail ({{after:2018-12-31}}
> https://support.google.com/mail/answer/7190?hl=en) or GitHub
> ({{updated:>=2018-12-31}}
> https://help.github.com/en/articles/searching-issues-and-pull-requests#search-by-when-an-issue-or-pull-request-was-created-or-last-updated)
> then you might end up with inefficient queries if the end user specifies
> both an upper and a lower bound. It would be nice if we optimized those
> automatically.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13074) MoveReplicaHDFSTest leaks threads, falls into an endless loop, logging like crazy
[
https://issues.apache.org/jira/browse/SOLR-13074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-13074:
Attachment: SOLR-13074.patch
> MoveReplicaHDFSTest leaks threads, falls into an endless loop, logging like
> crazy
> -
>
> Key: SOLR-13074
> URL: https://issues.apache.org/jira/browse/SOLR-13074
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Hadoop Integration
>Reporter: Dawid Weiss
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-13074.patch, SOLR-13074.patch
>
>
> This reproduces for me, always (Linux box):
> {code}
> ant test -Dtestcase=MoveReplicaHDFSTest -Dtests.seed=DC1CE772C445A55D
> -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.locale=fr
> -Dtests.timezone=Australia/Tasmania -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
> {code}
> It's the bug in Hadoop I discusse in SOLR-13060 -- one of the threads falls
> into an endless loop when terminated (interrupted). Perhaps we should close
> something cleanly and don't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from defaulting to async logging
[ https://issues.apache.org/jira/browse/SOLR-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777135#comment-16777135 ] Kevin Risden commented on SOLR-13268: - So I would guess that Solr isn't doing something right when it comes to logging. I haven't dug in to the details of how Solr does logging. There have only been a few failures related to log4j threads after adding the log4j-web dependency. Maybe we can collect those failures and see if there is a common theme. I have a few of the failures collected on my local Jenkins server but haven't sat down to look at them. I probably won't for a few days. Either way, the failures have gone down significantly recently. I don't think ignoring the leaked threads is correct. I also don't think adding shutdown is correct since that didn't seem to help. Also not sure this is a bad idea. If Solr is starting/stopping logging correctly, then I doubt we would have issues like this. Maybe we only see these start/stop issues due to the async logging since that type of logging is more sensitive to specific start/stop handling. > Clean up any test failures resulting from defaulting to async logging > - > > Key: SOLR-13268 > URL: https://issues.apache.org/jira/browse/SOLR-13268 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13268.patch > > Time Spent: 40m > Remaining Estimate: 0h > > This is a catch-all for test failures due to the async logging changes. So > far, the I see a couple failures on JDK13 only. I'll collect a "starter set" > here, these are likely systemic, once the root cause is found/fixed, then > others are likely fixed as well. > JDK13: > ant test -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV > -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8 > ant test -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk > -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8708) Can we simplify conjunctions of range queries automatically?
[
https://issues.apache.org/jira/browse/LUCENE-8708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777138#comment-16777138
]
Atri Sharma commented on LUCENE-8708:
-
We could extend this approach to identify overlapping ranges ([5, 20], [15, 35]
can be converted to 5 to 35).
I can take a crack at this one, if you are not planning to actively work on it
> Can we simplify conjunctions of range queries automatically?
>
>
> Key: LUCENE-8708
> URL: https://issues.apache.org/jira/browse/LUCENE-8708
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> BooleanQuery#rewrite already has some logic to make queries more efficient,
> such as deduplicating filters or rewriting boolean queries that wrap a single
> positive clause to that clause.
> It would be nice to also simplify conjunctions of range queries, so that eg.
> {{foo: [5 TO *] AND foo:[* TO 20]}} would be rewritten to {{foo:[5 TO 20]}}.
> When constructing queries manually or via the classic query parser, it feels
> unnecessary as this is something that the user can fix easily. However if you
> want to implement a query parser that only allows specifying one bound at
> once, such as Gmail ({{after:2018-12-31}}
> https://support.google.com/mail/answer/7190?hl=en) or GitHub
> ({{updated:>=2018-12-31}}
> https://help.github.com/en/articles/searching-issues-and-pull-requests#search-by-when-an-issue-or-pull-request-was-created-or-last-updated)
> then you might end up with inefficient queries if the end user specifies
> both an upper and a lower bound. It would be nice if we optimized those
> automatically.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8708) Can we simplify conjunctions of range queries automatically?
Adrien Grand created LUCENE-8708:
Summary: Can we simplify conjunctions of range queries
automatically?
Key: LUCENE-8708
URL: https://issues.apache.org/jira/browse/LUCENE-8708
Project: Lucene - Core
Issue Type: Improvement
Reporter: Adrien Grand
BooleanQuery#rewrite already has some logic to make queries more efficient,
such as deduplicating filters or rewriting boolean queries that wrap a single
positive clause to that clause.
It would be nice to also simplify conjunctions of range queries, so that eg.
{{foo: [5 TO *] AND foo:[* TO 20]}} would be rewritten to {{foo:[5 TO 20]}}.
When constructing queries manually or via the classic query parser, it feels
unnecessary as this is something that the user can fix easily. However if you
want to implement a query parser that only allows specifying one bound at once,
such as Gmail ({{after:2018-12-31}}
https://support.google.com/mail/answer/7190?hl=en) or GitHub
({{updated:>=2018-12-31}}
https://help.github.com/en/articles/searching-issues-and-pull-requests#search-by-when-an-issue-or-pull-request-was-created-or-last-updated)
then you might end up with inefficient queries if the end user specifies both
an upper and a lower bound. It would be nice if we optimized those
automatically.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13270) SolrJ does not send "Expect: 100-continue" header
[
https://issues.apache.org/jira/browse/SOLR-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777113#comment-16777113
]
Karl Wright commented on SOLR-13270:
Hi [~erlendfg], can you identify where in the SolrJ code it explicitly sets
expect/continue to "off"? It must be there somewhere.
> SolrJ does not send "Expect: 100-continue" header
> -
>
> Key: SOLR-13270
> URL: https://issues.apache.org/jira/browse/SOLR-13270
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7
>Reporter: Erlend Garåsen
>Priority: Major
>
> SolrJ does not set the "Expect: 100-continue" header, even though it's
> configured in HttpClient:
> {code:java}
> builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());{code}
> A HttpClient developer has reviewed the code and says we're setting up
> the client correctly, so we have a reason to believe there is a bug in
> SolrJ. It's actually a problem we are facing in ManifoldCF, explained in:
> https://issues.apache.org/jira/browse/CONNECTORS-1564
> The problem can be reproduced by building and running the following small
> Maven project:
> [http://folk.uio.no/erlendfg/solr/missing-header.zip]
> The application runs SolrJ code where the header does not show up and
> HttpClient code where the header is present.
>
> {code:java}
> HttpClientBuilder builder = HttpClients.custom();
> // This should add an Expect: 100-continue header:
> builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());
> HttpClient httpClient = builder.build();
> // Start Solr and create a core named "test".
> String baseUrl = "http://localhost:8983/solr/test;;
> // Test using SolrJ — no expect 100 header
> HttpSolrClient client = new HttpSolrClient.Builder()
> .withHttpClient(httpClient)
> .withBaseSolrUrl(baseUrl).build();
> SolrQuery query = new SolrQuery();
> query.setQuery("*:*");
> client.query(query);
> // Test using HttpClient directly — expect 100 header shows up:
> HttpPost httpPost = new HttpPost(baseUrl);
> HttpEntity entity = new InputStreamEntity(new
> ByteArrayInputStream("test".getBytes()));
> httpPost.setEntity(entity);
> httpClient.execute(httpPost);
> {code}
> When using the last HttpClient test, the expect 100 header appears in
> missing-header.log:
> {noformat}
> http-outgoing-1 >> Expect: 100-continue{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 1069 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/1069/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseG1GC
5 tests failed.
FAILED: org.apache.solr.cloud.LeaderTragicEventTest.test
Error Message:
Timeout waiting for new replica become leader Timeout waiting to see state for
collection=collection1
:DocCollection(collection1//collections/collection1/state.json/6)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node3":{ "core":"collection1_shard1_replica_n1",
"base_url":"http://127.0.0.1:51551/solr;,
"node_name":"127.0.0.1:51551_solr", "state":"active",
"type":"NRT", "force_set_state":"false"}, "core_node4":{
"core":"collection1_shard1_replica_n2",
"base_url":"http://127.0.0.1:51552/solr;,
"node_name":"127.0.0.1:51552_solr", "state":"active",
"type":"NRT", "force_set_state":"false",
"leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false", "nrtReplicas":"2",
"tlogReplicas":"0"} Live Nodes: [127.0.0.1:51551_solr, 127.0.0.1:51552_solr]
Last available state:
DocCollection(collection1//collections/collection1/state.json/6)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node3":{ "core":"collection1_shard1_replica_n1",
"base_url":"http://127.0.0.1:51551/solr;,
"node_name":"127.0.0.1:51551_solr", "state":"active",
"type":"NRT", "force_set_state":"false"}, "core_node4":{
"core":"collection1_shard1_replica_n2",
"base_url":"http://127.0.0.1:51552/solr;,
"node_name":"127.0.0.1:51552_solr", "state":"active",
"type":"NRT", "force_set_state":"false",
"leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false", "nrtReplicas":"2",
"tlogReplicas":"0"}
Stack Trace:
java.lang.AssertionError: Timeout waiting for new replica become leader
Timeout waiting to see state for collection=collection1
:DocCollection(collection1//collections/collection1/state.json/6)={
"pullReplicas":"0",
"replicationFactor":"2",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node3":{
"core":"collection1_shard1_replica_n1",
"base_url":"http://127.0.0.1:51551/solr;,
"node_name":"127.0.0.1:51551_solr",
"state":"active",
"type":"NRT",
"force_set_state":"false"},
"core_node4":{
"core":"collection1_shard1_replica_n2",
"base_url":"http://127.0.0.1:51552/solr;,
"node_name":"127.0.0.1:51552_solr",
"state":"active",
"type":"NRT",
"force_set_state":"false",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"2",
"tlogReplicas":"0"}
Live Nodes: [127.0.0.1:51551_solr, 127.0.0.1:51552_solr]
Last available state:
DocCollection(collection1//collections/collection1/state.json/6)={
"pullReplicas":"0",
"replicationFactor":"2",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node3":{
"core":"collection1_shard1_replica_n1",
"base_url":"http://127.0.0.1:51551/solr;,
"node_name":"127.0.0.1:51551_solr",
"state":"active",
"type":"NRT",
"force_set_state":"false"},
"core_node4":{
"core":"collection1_shard1_replica_n2",
"base_url":"http://127.0.0.1:51552/solr;,
"node_name":"127.0.0.1:51552_solr",
"state":"active",
"type":"NRT",
"force_set_state":"false",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"2",
"tlogReplicas":"0"}
at
__randomizedtesting.SeedInfo.seed([F6BEBD2EA3D4C739:7EEA82F40D28AAC1]:0)
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:304)
at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:282)
at
org.apache.solr.cloud.LeaderTragicEventTest.test(LeaderTragicEventTest.java:84)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
[jira] [Updated] (SOLR-13270) SolrJ does not send "Expect: 100-continue" header
[
https://issues.apache.org/jira/browse/SOLR-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erlend Garåsen updated SOLR-13270:
--
Description:
SolrJ does not set the "Expect: 100-continue" header, even though it's
configured in HttpClient:
{code:java}
builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());{code}
A HttpClient developer has reviewed the code and says we're setting up
the client correctly, so we have a reason to believe there is a bug in
SolrJ. It's actually a problem we are facing in ManifoldCF, explained in:
https://issues.apache.org/jira/browse/CONNECTORS-1564
The problem can be reproduced by building and running the following small Maven
project:
[http://folk.uio.no/erlendfg/solr/missing-header.zip]
The application runs SolrJ code where the header does not show up and
HttpClient code where the header is present.
{code:java}
HttpClientBuilder builder = HttpClients.custom();
// This should add an Expect: 100-continue header:
builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());
HttpClient httpClient = builder.build();
// Start Solr and create a core named "test".
String baseUrl = "http://localhost:8983/solr/test;;
// Test using SolrJ — no expect 100 header
HttpSolrClient client = new HttpSolrClient.Builder()
.withHttpClient(httpClient)
.withBaseSolrUrl(baseUrl).build();
SolrQuery query = new SolrQuery();
query.setQuery("*:*");
client.query(query);
// Test using HttpClient directly — expect 100 header shows up:
HttpPost httpPost = new HttpPost(baseUrl);
HttpEntity entity = new InputStreamEntity(new
ByteArrayInputStream("test".getBytes()));
httpPost.setEntity(entity);
httpClient.execute(httpPost);
{code}
When using the last HttpClient test, the expect 100 header appears in
missing-header.log:
{noformat}
http-outgoing-1 >> Expect: 100-continue{noformat}
was:
SolrJ does not set the "Expect: 100-continue" header, even though it's
configured in HttpClient:
{code:java}
builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());{code}
A HttpClient developer has reviewed the code and says we're setting up
the client correctly, so we have a reason to believe there is a bug in
SolrJ. It's actually a problem we are facing in ManifoldCF, explained in:
https://issues.apache.org/jira/browse/CONNECTORS-1564
The problem can be reproduced by building and running the following small Maven
project:
[http://folk.uio.no/erlendfg/solr/missing-header.zip]
The application runs SolrJ code where the header does not show up and
HttpClient code where the header is present.
{code:java}
HttpClientBuilder builder = HttpClients.custom();
// This should add an Expect: 100-continue header:
builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());
HttpClient httpClient = builder.build();
// Start Solr and create a core named "test".
String baseUrl = "http://localhost:8983/solr/test;;
// Test using SolrJ — no expect 100 header
HttpSolrClient client = new HttpSolrClient.Builder()
.withHttpClient(httpClient)
.withBaseSolrUrl(baseUrl).build();
SolrQuery query = new SolrQuery();
query.setQuery("*:*");
client.query(query);
// Test using HttpClient directly — expect 100 header shows up:
HttpPost httpPost = new HttpPost(baseUrl);
HttpEntity entity = new InputStreamEntity(new
ByteArrayInputStream("test".getBytes()));
httpPost.setEntity(entity);
httpClient.execute(httpPost);
{code}
> SolrJ does not send "Expect: 100-continue" header
> -
>
> Key: SOLR-13270
> URL: https://issues.apache.org/jira/browse/SOLR-13270
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7
>Reporter: Erlend Garåsen
>Priority: Major
>
> SolrJ does not set the "Expect: 100-continue" header, even though it's
> configured in HttpClient:
> {code:java}
> builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());{code}
> A HttpClient developer has reviewed the code and says we're setting up
> the client correctly, so we have a reason to believe there is a bug in
> SolrJ. It's actually a problem we are facing in ManifoldCF, explained in:
> https://issues.apache.org/jira/browse/CONNECTORS-1564
> The problem can be reproduced by building and running the following small
> Maven project:
> [http://folk.uio.no/erlendfg/solr/missing-header.zip]
> The application runs SolrJ code where the header does not show up and
> HttpClient code where the header is present.
>
> {code:java}
> HttpClientBuilder builder = HttpClients.custom();
> // This should add an Expect: 100-continue header:
>
[JENKINS] Lucene-Solr-Tests-master - Build # 3188 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3188/ 1 tests failed. FAILED: org.apache.solr.schema.TestCloudSchemaless.test Error Message: Timeout occurred while waiting response from server at: http://127.0.0.1:38111/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: http://127.0.0.1:38111/collection1 at __randomizedtesting.SeedInfo.seed([43756CB7F44EF222:CB21536D5AB29FDA]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:661) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:256) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:504) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:479) at org.apache.solr.schema.TestCloudSchemaless.test(TestCloudSchemaless.java:116) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at
[jira] [Commented] (SOLR-13060) Some Nightly HDFS tests never terminate on ASF Jenkins, triggering whole-job timeout, causing Jenkins to kill JVMs, causing dump files to be created that fill all disk
[ https://issues.apache.org/jira/browse/SOLR-13060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777074#comment-16777074 ] ASF subversion and git services commented on SOLR-13060: Commit 129de3f5e9f45d79711853b087fce86358a63307 in lucene-solr's branch refs/heads/branch_8x from Kevin Risden [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=129de3f ] SOLR-13060: Improve HdfsAutoAddReplicasIntegrationTest and HdfsCollectionsAPIDistributedZkTest Signed-off-by: Kevin Risden > Some Nightly HDFS tests never terminate on ASF Jenkins, triggering whole-job > timeout, causing Jenkins to kill JVMs, causing dump files to be created that > fill all disk space, causing failure of all following jobs on the same node > - > > Key: SOLR-13060 > URL: https://issues.apache.org/jira/browse/SOLR-13060 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Hadoop Integration, Tests >Reporter: Steve Rowe >Assignee: Kevin Risden >Priority: Major > Attachments: SOLR-13060.patch, > junit4-J0-20181210_065854_4175881849742830327151.spill.part1.gz > > > The 3 tests that are affected: > * HdfsAutoAddReplicasIntegrationTest > * HdfsCollectionsAPIDistributedZkTest > * MoveReplicaHDFSTest > Instances from the dev list: > 12/1: > https://lists.apache.org/thread.html/e04ad0f9113e15f77393ccc26e3505e3090783b1d61bd1c7ff03d33e@%3Cdev.lucene.apache.org%3E > 12/5: > https://lists.apache.org/thread.html/d78c99255abfb5134803c2b77664c1a039d741f92d6e6fcbcc66cd14@%3Cdev.lucene.apache.org%3E > 12/8: > https://lists.apache.org/thread.html/92ad03795ae60b1e94859d49c07740ca303f997ae2532e6f079acfb4@%3Cdev.lucene.apache.org%3E > 12/8: > https://lists.apache.org/thread.html/26aace512bce0b51c4157e67ac3120f93a99905b40040bee26472097@%3Cdev.lucene.apache.org%3E > 12/11: > https://lists.apache.org/thread.html/33558a8dd292fd966a7f476bf345b66905d99f7eb9779a4d17b7ec97@%3Cdev.lucene.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_172) - Build # 23720 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23720/ Java: 64bit/jdk1.8.0_172 -XX:+UseCompressedOops -XX:+UseParallelGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.store.blockcache.BufferStoreTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.store.blockcache.BufferStoreTest: 1) Thread[id=14, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-BufferStoreTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.store.blockcache.BufferStoreTest: 1) Thread[id=14, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-BufferStoreTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([3EF531368FC72D9F]:0) FAILED: junit.framework.TestSuite.org.apache.solr.store.blockcache.BufferStoreTest Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=14, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-BufferStoreTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=14, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-BufferStoreTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([3EF531368FC72D9F]:0) FAILED: junit.framework.TestSuite.org.apache.solr.store.blockcache.BufferStoreTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.store.blockcache.BufferStoreTest: 1) Thread[id=14, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-BufferStoreTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at
[jira] [Created] (SOLR-13270) SolrJ does not send "Expect: 100-continue" header
Erlend Garåsen created SOLR-13270:
-
Summary: SolrJ does not send "Expect: 100-continue" header
Key: SOLR-13270
URL: https://issues.apache.org/jira/browse/SOLR-13270
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrJ
Affects Versions: 7.7
Reporter: Erlend Garåsen
SolrJ does not set the "Expect: 100-continue" header, even though it's
configured in HttpClient:
{code:java}
builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());{code}
A HttpClient developer has reviewed the code and says we're setting up
the client correctly, so we have a reason to believe there is a bug in
SolrJ. It's actually a problem we are facing in ManifoldCF, explained in:
https://issues.apache.org/jira/browse/CONNECTORS-1564
The problem can be reproduced by building and running the following small Maven
project:
[http://folk.uio.no/erlendfg/solr/missing-header.zip]
The application runs SolrJ code where the header does not show up and
HttpClient code where the header is present.
{code:java}
HttpClientBuilder builder = HttpClients.custom();
// This should add an Expect: 100-continue header:
builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());
HttpClient httpClient = builder.build();
// Start Solr and create a core named "test".
String baseUrl = "http://localhost:8983/solr/test;;
// Test using SolrJ — no expect 100 header
HttpSolrClient client = new HttpSolrClient.Builder()
.withHttpClient(httpClient)
.withBaseSolrUrl(baseUrl).build();
SolrQuery query = new SolrQuery();
query.setQuery("*:*");
client.query(query);
// Test using HttpClient directly — expect 100 header shows up:
HttpPost httpPost = new HttpPost(baseUrl);
HttpEntity entity = new InputStreamEntity(new
ByteArrayInputStream("test".getBytes()));
httpPost.setEntity(entity);
httpClient.execute(httpPost);
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13060) Some Nightly HDFS tests never terminate on ASF Jenkins, triggering whole-job timeout, causing Jenkins to kill JVMs, causing dump files to be created that fill all disk sp
[ https://issues.apache.org/jira/browse/SOLR-13060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13060: Fix Version/s: master (9.0) 8.x > Some Nightly HDFS tests never terminate on ASF Jenkins, triggering whole-job > timeout, causing Jenkins to kill JVMs, causing dump files to be created that > fill all disk space, causing failure of all following jobs on the same node > - > > Key: SOLR-13060 > URL: https://issues.apache.org/jira/browse/SOLR-13060 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Hadoop Integration, Tests >Reporter: Steve Rowe >Assignee: Kevin Risden >Priority: Major > Fix For: 8.x, master (9.0) > > Attachments: SOLR-13060.patch, > junit4-J0-20181210_065854_4175881849742830327151.spill.part1.gz > > > The 3 tests that are affected: > * HdfsAutoAddReplicasIntegrationTest > * HdfsCollectionsAPIDistributedZkTest > * MoveReplicaHDFSTest > Instances from the dev list: > 12/1: > https://lists.apache.org/thread.html/e04ad0f9113e15f77393ccc26e3505e3090783b1d61bd1c7ff03d33e@%3Cdev.lucene.apache.org%3E > 12/5: > https://lists.apache.org/thread.html/d78c99255abfb5134803c2b77664c1a039d741f92d6e6fcbcc66cd14@%3Cdev.lucene.apache.org%3E > 12/8: > https://lists.apache.org/thread.html/92ad03795ae60b1e94859d49c07740ca303f997ae2532e6f079acfb4@%3Cdev.lucene.apache.org%3E > 12/8: > https://lists.apache.org/thread.html/26aace512bce0b51c4157e67ac3120f93a99905b40040bee26472097@%3Cdev.lucene.apache.org%3E > 12/11: > https://lists.apache.org/thread.html/33558a8dd292fd966a7f476bf345b66905d99f7eb9779a4d17b7ec97@%3Cdev.lucene.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13060) Some Nightly HDFS tests never terminate on ASF Jenkins, triggering whole-job timeout, causing Jenkins to kill JVMs, causing dump files to be created that fill all disk
[ https://issues.apache.org/jira/browse/SOLR-13060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777072#comment-16777072 ] ASF subversion and git services commented on SOLR-13060: Commit 6a886b274d6cc24dd1b84a7379ee8a07ccae3ce8 in lucene-solr's branch refs/heads/master from Kevin Risden [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6a886b2 ] SOLR-13060: Improve HdfsAutoAddReplicasIntegrationTest and HdfsCollectionsAPIDistributedZkTest Signed-off-by: Kevin Risden > Some Nightly HDFS tests never terminate on ASF Jenkins, triggering whole-job > timeout, causing Jenkins to kill JVMs, causing dump files to be created that > fill all disk space, causing failure of all following jobs on the same node > - > > Key: SOLR-13060 > URL: https://issues.apache.org/jira/browse/SOLR-13060 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Hadoop Integration, Tests >Reporter: Steve Rowe >Assignee: Kevin Risden >Priority: Major > Attachments: SOLR-13060.patch, > junit4-J0-20181210_065854_4175881849742830327151.spill.part1.gz > > > The 3 tests that are affected: > * HdfsAutoAddReplicasIntegrationTest > * HdfsCollectionsAPIDistributedZkTest > * MoveReplicaHDFSTest > Instances from the dev list: > 12/1: > https://lists.apache.org/thread.html/e04ad0f9113e15f77393ccc26e3505e3090783b1d61bd1c7ff03d33e@%3Cdev.lucene.apache.org%3E > 12/5: > https://lists.apache.org/thread.html/d78c99255abfb5134803c2b77664c1a039d741f92d6e6fcbcc66cd14@%3Cdev.lucene.apache.org%3E > 12/8: > https://lists.apache.org/thread.html/92ad03795ae60b1e94859d49c07740ca303f997ae2532e6f079acfb4@%3Cdev.lucene.apache.org%3E > 12/8: > https://lists.apache.org/thread.html/26aace512bce0b51c4157e67ac3120f93a99905b40040bee26472097@%3Cdev.lucene.apache.org%3E > 12/11: > https://lists.apache.org/thread.html/33558a8dd292fd966a7f476bf345b66905d99f7eb9779a4d17b7ec97@%3Cdev.lucene.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] gus-asf merged pull request #583: SOLR-13151
gus-asf merged pull request #583: SOLR-13151 URL: https://github.com/apache/lucene-solr/pull/583 This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from defaulting to async logging
[ https://issues.apache.org/jira/browse/SOLR-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777006#comment-16777006 ] Erick Erickson commented on SOLR-13268: --- I'm going to be busy today all day and won't have time to deal with. This is obviously vastly better, but I'm not sure what to do next. This certainly feels like a problem in log4j2, but doesn't seem like it affects running solr in the normal case. Does it make sense to ignore it? We'd need to keep it from failing tests and creating noise, not sure how to get the leak checker to ignore this one, I think there's a way. Or try turning the shutdown back on? That feels like pushing a random button and hoping it'll work. Or just give this up as a bad idea? Async logging should be an option, I'm not sure I see any _practical_ (as opposed to a test issue) consequences. And certainly users can enable it on their own. Or leave the config for async logging commented out (the opposite of now). Not sure I like that one, but Thoughts? > Clean up any test failures resulting from defaulting to async logging > - > > Key: SOLR-13268 > URL: https://issues.apache.org/jira/browse/SOLR-13268 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13268.patch > > Time Spent: 40m > Remaining Estimate: 0h > > This is a catch-all for test failures due to the async logging changes. So > far, the I see a couple failures on JDK13 only. I'll collect a "starter set" > here, these are likely systemic, once the root cause is found/fixed, then > others are likely fixed as well. > JDK13: > ant test -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV > -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8 > ant test -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk > -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 2897 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/2897/ [...truncated 36 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-Tests-master/3187/consoleText [repro] Revision: 52097627f8a5e5c8e0771d826ea0f5936411a251 [repro] Repro line: ant test -Dtestcase=TestSurroundQueryParser -Dtests.seed=4D94AA31A67BFEAC -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=bg -Dtests.timezone=Etc/GMT-2 -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=TestCollectionStateWatchers -Dtests.method=testStateWatcherChecksCurrentStateOnRegister -Dtests.seed=58418E9F8B07D726 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=is -Dtests.timezone=Australia/Hobart -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestCollectionStateWatchers -Dtests.seed=58418E9F8B07D726 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=is -Dtests.timezone=Australia/Hobart -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 8c34da8a626634eac07841795b72c8e225de3b04 [repro] git fetch [...truncated 2 lines...] [repro] git checkout 52097627f8a5e5c8e0771d826ea0f5936411a251 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestSurroundQueryParser [repro]solr/solrj [repro] TestCollectionStateWatchers [repro] ant compile-test [...truncated 3565 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestSurroundQueryParser" -Dtests.showOutput=onerror -Dtests.seed=4D94AA31A67BFEAC -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=bg -Dtests.timezone=Etc/GMT-2 -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 67 lines...] [repro] ant compile-test [...truncated 454 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestCollectionStateWatchers" -Dtests.showOutput=onerror -Dtests.seed=58418E9F8B07D726 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=is -Dtests.timezone=Australia/Hobart -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [...truncated 4805 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.search.TestSurroundQueryParser [repro] 2/5 failed: org.apache.solr.common.cloud.TestCollectionStateWatchers [repro] git checkout 8c34da8a626634eac07841795b72c8e225de3b04 [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 291 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/291/ 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.IgnoreLargeDocumentProcessorFactoryTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.update.processor.IgnoreLargeDocumentProcessorFactoryTest: 1) Thread[id=13, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-IgnoreLargeDocumentProcessorFactoryTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.update.processor.IgnoreLargeDocumentProcessorFactoryTest: 1) Thread[id=13, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-IgnoreLargeDocumentProcessorFactoryTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([FFE5AB53EC0B3896]:0) FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.IgnoreLargeDocumentProcessorFactoryTest Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=13, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-IgnoreLargeDocumentProcessorFactoryTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=13, name=Log4j2-TF-1-AsyncLoggerConfig-1, state=TIMED_WAITING, group=TGRP-IgnoreLargeDocumentProcessorFactoryTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38) at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56) at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159) at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([FFE5AB53EC0B3896]:0) FAILED: org.apache.solr.cloud.cdcr.CdcrVersionReplicationTest.testCdcrDocVersions Error Message: Error from server at https://127.0.0.1:44766: ADDREPLICA failed to create replica Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:44766: ADDREPLICA failed to create replica at __randomizedtesting.SeedInfo.seed([FFE5AB53EC0B3896:773A0F11E6DD78A]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:650) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:256) at
[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776975#comment-16776975
]
Karl Wright commented on LUCENE-8696:
-
[~jpountz], should be addressed now.
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-8.x - Build # 45 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/45/ All tests passed Build Log: [...truncated 53570 lines...] -ecj-javadoc-lint-tests: [mkdir] Created dir: /tmp/ecj311088577 [ecj-lint] Compiling 20 source files to /tmp/ecj311088577 [ecj-lint] -- [ecj-lint] 1. ERROR in /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPathTest.java (at line 22) [ecj-lint] import static org.junit.Assert.assertEquals; [ecj-lint] ^ [ecj-lint] The import org.junit.Assert.assertEquals is never used [ecj-lint] -- [ecj-lint] 2. ERROR in /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPathTest.java (at line 23) [ecj-lint] import static org.junit.Assert.assertFalse; [ecj-lint] [ecj-lint] The import org.junit.Assert.assertFalse is never used [ecj-lint] -- [ecj-lint] 3. ERROR in /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPathTest.java (at line 24) [ecj-lint] import static org.junit.Assert.assertTrue; [ecj-lint] ^^^ [ecj-lint] The import org.junit.Assert.assertTrue is never used [ecj-lint] -- [ecj-lint] 3 problems (3 errors) BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:633: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/build.xml:101: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/build.xml:207: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2268: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2099: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/lucene/common-build.xml:2132: Compile failed; see the compiler error output for details. Total time: 94 minutes 43 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-13-ea+8) - Build # 3580 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/3580/ Java: 64bit/jdk-13-ea+8 -XX:-UseCompressedOops -XX:+UseParallelGC 11 tests failed. FAILED: org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitShardWithRuleLink Error Message: Error from server at http://127.0.0.1:37381/_d/iy: Could not find collection : shardSplitWithRule_link Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:37381/_d/iy: Could not find collection : shardSplitWithRule_link at __randomizedtesting.SeedInfo.seed([6EAA59A424290989:64B6EC3FAEB56F2C]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:484) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:414) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1110) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.api.collections.ShardSplitTest.doSplitShardWithRule(ShardSplitTest.java:661) at org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitShardWithRuleLink(ShardSplitTest.java:633) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1075) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1047) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at
[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776970#comment-16776970
]
ASF subversion and git services commented on LUCENE-8696:
-
Commit ad42f6c3467041b8e5e82ad5fb3d8f2306d31f00 in lucene-solr's branch
refs/heads/branch_7_7 from Karl Wright
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ad42f6c ]
LUCENE-8696: Fix precommit objections
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776969#comment-16776969
]
ASF subversion and git services commented on LUCENE-8696:
-
Commit a86a64fd0eae840f82803e31daf9e5b93a3e2187 in lucene-solr's branch
refs/heads/branch_7_7 from Karl Wright
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a86a64f ]
LUCENE-8696: Update test to be what's actually failing
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776899#comment-16776899
]
Karl Wright edited comment on LUCENE-8696 at 2/25/19 2:39 PM:
--
Reviewing the solid, and what the edge points *should* be:
minx, maxx: -0.7731590077686981, 1.0011188539924791
miny, maxy: 0.9519964046486451, 1.0011188539924791
minz, maxz: -0.9977622932859775, 0.9977599768255027
The minz/maxz planes might touch the world at the poles, but probably don't.
The maxx plane might touch the world at the max X pole.
The minx plane definitely slices the world, so it should generate at least one
point.
The maxy plane might touch the world at the max Y pole.
The miny plane slices the world, so it should generate at least one point.
This is the debugging output:
{code}
[junit4] 2> notableMinXPoints=[] notableMaxXPoints=[] notableMinYPoints=[]
notableMaxYPoints=[] notableMinZPoints=[] notableMaxZPoints=[]
[junit4] 2> minXEdges=[] maxXEdges=[] minYEdges=[[X=0.0,
Y=0.9519964046486451, Z=-0.30870622678085735]] maxYEdges=[[X=-0.0,
Y=1.0011188539924791, Z=0.0]] minZEdges=[] maxZEdges=[]
{code}
"Notable points" are places where the plane intersections also intersect the
world. There are none of these, as expected.
The planes that intersect the world are minY and maxY. We do *not* see
intersections for minX, though, and we expected to. That's got to be
researched to figure out why. It may be because the intersection is actually
outside the solid bounds as determined by the Y plane.
Out of time for the moment though.
was (Author: kwri...@metacarta.com):
Reviewing the solid, and what the edge points *should* be:
minx, maxx: -0.7731590077686981, 1.0011188539924791
miny, maxy: 0.9519964046486451, 1.0011188539924791
minz, maxz: -0.9977622932859775, 0.9977599768255027
The minz/maxz planes might touch the world at the poles, but probably don't.
The maxx plane might touch the world at the max X pole.
The minx plane definitely slices the world, so it should generate at least one
point.
The maxy plane might touch the world at the max Y pole.
The miny plane slices the world, so it should generate at least one point.
We therefore should expect a minimum of two points, which is what we see. If
any of these planes actually encounters the pole, though, we should have gotten
another point from that. The maxZ plane looks potentially like it might
qualify. Out of time for the moment though.
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776964#comment-16776964
]
ASF subversion and git services commented on LUCENE-8696:
-
Commit e7e5798792e89eea2c04dc61a2ee034a9e393984 in lucene-solr's branch
refs/heads/branch_8x from Karl Wright
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e7e5798 ]
LUCENE-8696: Fix precommit objections
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776963#comment-16776963
]
ASF subversion and git services commented on LUCENE-8696:
-
Commit 4be095e69823451f094152d8e2142605418caf4e in lucene-solr's branch
refs/heads/branch_7x from Karl Wright
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4be095e ]
LUCENE-8696: Fix precommit objections
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776958#comment-16776958
]
ASF subversion and git services commented on LUCENE-8696:
-
Commit 8c34da8a626634eac07841795b72c8e225de3b04 in lucene-solr's branch
refs/heads/master from Karl Wright
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8c34da8 ]
LUCENE-8696: Fix precommit objections
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from defaulting to async logging
[ https://issues.apache.org/jira/browse/SOLR-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776960#comment-16776960 ] Kevin Risden commented on SOLR-13268: - [~erickerickson] - FYI been testing with the shutdown and test class changes removed in https://github.com/apache/lucene-solr/pull/586. Tests pass with the cleanup as well. > Clean up any test failures resulting from defaulting to async logging > - > > Key: SOLR-13268 > URL: https://issues.apache.org/jira/browse/SOLR-13268 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13268.patch > > Time Spent: 40m > Remaining Estimate: 0h > > This is a catch-all for test failures due to the async logging changes. So > far, the I see a couple failures on JDK13 only. I'll collect a "starter set" > here, these are likely systemic, once the root cause is found/fixed, then > others are likely fixed as well. > JDK13: > ant test -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV > -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8 > ant test -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk > -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13227) Remove slow other-range checks from RangeFacetProcessor
[ https://issues.apache.org/jira/browse/SOLR-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776953#comment-16776953 ] Mikhail Khludnev commented on SOLR-13227: - [~shalinmangar], can you comment on that? I'd like to pick it up. > Remove slow other-range checks from RangeFacetProcessor > --- > > Key: SOLR-13227 > URL: https://issues.apache.org/jira/browse/SOLR-13227 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: faceting >Affects Versions: 7.5, 8.0, master (9.0) >Reporter: Nikolay Khitrin >Assignee: Mikhail Khludnev >Priority: Major > Attachments: SOLR-13227.patch, SOLR-13227.patch, profiler.png > > > RangeFacetProcessor.getFacetRangeCountsDocValues is checking every range name > over FacetParams.FacetRangeOther enum via catching IllegalArgumentException > from valueOf, rethrowing it as SolrException and picking a branch based on > the presence of last one. > It is very slow due to enormous cost of failed Enum.valueOf. > Also RangeFacetRequest.FacetRange already have a field with parsed > FacetRangeOther value for special ranges or null for ordinary ones. > Replacing this with simple null check leads to huge performance boost here. > In real case with a lot of intervals (~2000) whole QTime is reduced from > 300ms to 50ms by this patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776920#comment-16776920
]
Adrien Grand commented on LUCENE-8696:
--
[~kwri...@metacarta.com] FYI your latest commits are causing precommit
failures, see eg.
https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1265/consoleFull.
Also I see that you pushed some code to branch_7x even though we will likely
never create new releases from this branch anymore, only from branch_7_7.
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776899#comment-16776899
]
Karl Wright commented on LUCENE-8696:
-
Reviewing the solid, and what the edge points *should* be:
minx, maxx: -0.7731590077686981, 1.0011188539924791
miny, maxy: 0.9519964046486451, 1.0011188539924791
minz, maxz: -0.9977622932859775, 0.9977599768255027
The minz/maxz planes might touch the world at the poles, but probably don't.
The maxx plane might touch the world at the max X pole.
The minx plane definitely slices the world, so it should generate at least one
point.
The maxy plane might touch the world at the max Y pole.
The miny plane slices the world, so it should generate at least one point.
We therefore should expect a minimum of two points, which is what we see. If
any of these planes actually encounters the pole, though, we should have gotten
another point from that. The maxZ plane looks potentially like it might
qualify. Out of time for the moment though.
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.0-Linux (32bit/jdk1.8.0_172) - Build # 213 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.0-Linux/213/ Java: 32bit/jdk1.8.0_172 -server -XX:+UseParallelGC 3 tests failed. FAILED: org.apache.solr.cloud.LeaderTragicEventTest.test Error Message: Failed while waiting for active collection Timeout waiting to see state for collection=collection1 :null Live Nodes: [127.0.0.1:32939_solr, 127.0.0.1:43521_solr] Last available state: null Stack Trace: java.lang.RuntimeException: Failed while waiting for active collection Timeout waiting to see state for collection=collection1 :null Live Nodes: [127.0.0.1:32939_solr, 127.0.0.1:43521_solr] Last available state: null at __randomizedtesting.SeedInfo.seed([8197B178C51CE1D1:9C38EA26BE08C29]:0) at org.apache.solr.cloud.MiniSolrCloudCluster.waitForActiveCollection(MiniSolrCloudCluster.java:728) at org.apache.solr.cloud.MiniSolrCloudCluster.waitForActiveCollection(MiniSolrCloudCluster.java:734) at org.apache.solr.cloud.LeaderTragicEventTest.test(LeaderTragicEventTest.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776881#comment-16776881
]
Karl Wright commented on LUCENE-8696:
-
Reviewing the solid edge point logic finds nothing wrong. Will try to rule out
numerical precision problems next.
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1265 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1265/ No tests ran. Build Log: [...truncated 23448 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2477 links (2023 relative) to 3301 anchors in 249 files [echo] Validated Links & Anchors via: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked [untar] Expanding: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-9.0.0.tgz into /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail:
[jira] [Commented] (SOLR-12694) JavaBinUpdateRequestCodec fails to restore UpdateRequest correctly with implicit routing
[
https://issues.apache.org/jira/browse/SOLR-12694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776855#comment-16776855
]
Jaroslaw Rozanski commented on SOLR-12694:
--
Referencing [Solr User mailing
post|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201902.mbox/%3Cab231aa3-bd71-523e-f51b-d28f18f19fa4%40jarekrozanski.eu%3E]
of mine which mentions this specific issue.
> JavaBinUpdateRequestCodec fails to restore UpdateRequest correctly with
> implicit routing
>
>
> Key: SOLR-12694
> URL: https://issues.apache.org/jira/browse/SOLR-12694
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Reporter: Yuki Yano
>Priority: Major
> Attachments: SOLR-12694.patch
>
>
> h1. Overview
> As reported in [SOLR-7384|https://issues.apache.org/jira/browse/SOLR-7384],
> when send {{deleteById}} request to Solr with {{ImplicitDocRouter}}, Solr
> fails to delete the document with the following error.
> {quote}
> org.apache.solr.common.SolrException: missing \_version\_ on update from
> leader
> {quote}
> This issue is related to
> [SOLR-5890|https://issues.apache.org/jira/browse/SOLR-5890], which solved the
> issue about deleting documents with the implicit router. Unfortunately, this
> change left one bug in {{JavaBinUpdateRequestCodec}} that it forgets to
> restore {{version}} during {{unmarshal}} if {{\_route\_}} is set.
> {code:java}
> Long version = (Long) params.get(UpdateRequest.VER);
> if (params.containsKey(ShardParams._ROUTE_))
> updateRequest.deleteById(entry.getKey(), (String)
> params.get(ShardParams._ROUTE_));
> else
> updateRequest.deleteById(entry.getKey(), version);
> {code}
> Note that, since this code refers {{\_route\_}} parameter from properties of
> {{UpdateRequest}}, this error doesn't occur if you use {{\_route\_}} request
> parameter (like {{/update?\_route\_=foo}}) instead.
> h1. How to reproduce
> 1. start solr cloud with default configuration.
> {code:bash}
> $ ./bin/solr start -e cloud
> {code}
> 2. create new collection (named {{test}} here) with implicit router.
> {code:bash}
> $ curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=implicit=shard1,shard2=2=2'
> {code}
> 3. send add and delete document requests.
> {code:bash}
> // add a document "id=foo" to shard1
> $ curl 'http://localhost:8983/solr/test/update?commit=true&_route_=shard1' -H
> 'Content-Type: text/xml' --data-binary ' name="id">foo'
> // delete the document by using "_route_" request parameter (this is OK)
> $ curl 'http://localhost:8983/solr/test/update?commit=true&_route_=shard1' -H
> 'Content-Type: text/xml' --data-binary 'foo'
> // add a document "id=foo" to shard1 again
> $ curl 'http://localhost:8983/solr/test/update?commit=true&_route_=shard1' -H
> 'Content-Type: text/xml' --data-binary ' name="id">foo'
> // delete the document by using "_route_" attribute (this raises the error
> mentioned above)
> $ curl 'http://localhost:8983/solr/test/update?commit=true' -H 'Content-Type:
> text/xml' --data-binary 'foo'
> {code}
> 4. stop solr cloud
> {code:bash}
> $ ./bin/solr stop -all
> {code}
> h1. How to fix
> We can fix this issue by restoring {{UpdateRequest}} with {{version}}
> correctly like the following code:
> {code:java}
> Long version = (Long) params.get(UpdateRequest.VER);
> if (params.containsKey(ShardParams._ROUTE_))
> updateRequest.deleteById(entry.getKey(), (String)
> params.get(ShardParams._ROUTE_), version);
> else
> updateRequest.deleteById(entry.getKey(), version);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776841#comment-16776841
]
Karl Wright commented on LUCENE-8696:
-
I've verified that there are two solid edge points and they both lie within the
path:
{code}
[junit4] 2> solid edge point [X=0.0, Y=0.9519964046486451,
Z=-0.30870622678085735] path.isWithin()? true
[junit4] 2> solid edge point [X=-0.0, Y=1.0011188539924791, Z=0.0]
path.isWithin()? true
[junit4] 2> path edge point [X=0.22516844226485835,
Y=0.003930329545205224, Z=0.9721897091178435] isWithin()? false
minx=0.9983274500335564 maxx=-0.7759504117276208 miny=-0.9480660751034399
maxy=-0.9971885244472739 minz=1.969952002403821 maxz=-0.025570267707659133
{code}
So this confirms that there is no intersection detected, and how the conclusion
that the solid is completely within the path is arrived at.
Possible errors that would cause this:
(1) We might be missing a solid edge point. These edge points are computed
based on the lines of intersection between adjoining solid planes and the
surface of the world. There is also special computation to handle the case
where a solid edge plane intersects the world by itself, but this logic might
not be complete. We need to capture all plane/world intersection closed curves
and come up with an example point for each.
(2) There might be numerical precision issues with intersection computation
that prevent us from concluding that the path edges intersect the solid edges.
I still have to figure out which is the real problem here.
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776831#comment-16776831
]
Ignacio Vera commented on LUCENE-8696:
--
Yes, that is how it surface in the test. Is it true that if you have a GeoPath
with cutoff angle x, the same GeoPath with cutoff angle x + 1 should contain
all points of the GeoPath with smaller cutoff angle?
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure
[
https://issues.apache.org/jira/browse/LUCENE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776821#comment-16776821
]
Karl Wright commented on LUCENE-8696:
-
Looking at the actual failure now.
Basically, problem is that the relationship between the XYZSolid and the
GeoPath is containment: the XYZSolid is reported to be inside the GeoPath. It
reaches this conclusion because it detects no intersections between the solid
and the path edges, and because the path edge point it is using is outside the
solid:
{code}
[junit4] 1> in isShapeInsideArea
[junit4] 1> there are 1 pathPoints
[junit4] 1> pathpoint [X=0.22516844226485835, Y=0.003930329545205224,
Z=0.9721897091178435]...
[junit4] 1> outside
{code}
Haven't verified it yet, but this implies that at least one of the solid's
surface points is inside of the path too. Still too early to know which
conclusion is incorrect.
> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
> [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
> [junit4] > Throwable #1: java.lang.AssertionError: invalid hits for
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84,
> width=1.3439035240356338(77.01),
> points={[[lat=2.4457272005608357E-47,
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473,
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47,
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843,
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459,
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452,
> Z=-0.6971214014446648])]]}}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8707) Add LatLonShape distance query
[ https://issues.apache.org/jira/browse/LUCENE-8707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-8707: - Issue Type: New Feature (was: Improvement) > Add LatLonShape distance query > -- > > Key: LUCENE-8707 > URL: https://issues.apache.org/jira/browse/LUCENE-8707 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Ignacio Vera >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Add a query to LatLonShape that filters by distance from a provided point. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-13-ea+8) - Build # 204 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/204/ Java: 64bit/jdk-13-ea+8 -XX:-UseCompressedOops -XX:+UseParallelGC 8 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.OverseerTest Error Message: SOLR-11606: ByteBuddy used by Mockito is not working with this JVM version. Stack Trace: org.junit.AssumptionViolatedException: SOLR-11606: ByteBuddy used by Mockito is not working with this JVM version. at __randomizedtesting.SeedInfo.seed([151E81A82448C63B]:0) at com.carrotsearch.randomizedtesting.RandomizedTest.assumeNoException(RandomizedTest.java:742) at org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:367) at org.apache.solr.cloud.OverseerTest.beforeClass(OverseerTest.java:284) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:878) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:835) Caused by: java.lang.IllegalArgumentException: Unknown Java version: 13 at net.bytebuddy.ClassFileVersion.ofJavaVersion(ClassFileVersion.java:210) at net.bytebuddy.ClassFileVersion$VersionLocator$ForJava9CapableVm.locate(ClassFileVersion.java:462) at net.bytebuddy.ClassFileVersion.ofThisVm(ClassFileVersion.java:223) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:365) ... 24 more FAILED: junit.framework.TestSuite.org.apache.solr.cloud.OverseerTest Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([151E81A82448C63B]:0) at org.apache.solr.cloud.OverseerTest.afterClass(OverseerTest.java:307) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:901) at
[GitHub] iverase opened a new pull request #587: LUCENE-8707: Add LatLonShape distance query
iverase opened a new pull request #587: LUCENE-8707: Add LatLonShape distance query URL: https://github.com/apache/lucene-solr/pull/587 LatLonShape query distance based heavily in LatLonPoint implementation This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8707) Add LatLonShape distance query
Ignacio Vera created LUCENE-8707: Summary: Add LatLonShape distance query Key: LUCENE-8707 URL: https://issues.apache.org/jira/browse/LUCENE-8707 Project: Lucene - Core Issue Type: Improvement Reporter: Ignacio Vera Add a query to LatLonShape that filters by distance from a provided point. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 2895 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/2895/ [...truncated 29 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/28/consoleText [repro] Revision: 1dfc766afa63f246ef10ff2ab325db8ddec0cf9d [repro] Ant options: -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt [repro] Repro line: ant test -Dtestcase=ChaosMonkeySafeLeaderWithPullReplicasTest -Dtests.seed=8834A9C1C6EEB85D -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=is -Dtests.timezone=Indian/Christmas -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=TestCloudSchemaless -Dtests.method=test -Dtests.seed=8834A9C1C6EEB85D -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=en-IE -Dtests.timezone=Brazil/DeNoronha -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=HdfsUnloadDistributedZkTest -Dtests.method=test -Dtests.seed=8834A9C1C6EEB85D -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=es-GT -Dtests.timezone=Asia/Beirut -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=TestV2Request -Dtests.method=testHttpSolrClient -Dtests.seed=CB5B6E1D0C19E48A -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=ru -Dtests.timezone=America/Antigua -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 303d11921f19f73c0b5476c4ab4cdca0f7dd249e [repro] git fetch [repro] git checkout 1dfc766afa63f246ef10ff2ab325db8ddec0cf9d [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestCloudSchemaless [repro] HdfsUnloadDistributedZkTest [repro] ChaosMonkeySafeLeaderWithPullReplicasTest [repro]solr/solrj [repro] TestV2Request [repro] ant compile-test [...truncated 3575 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 -Dtests.class="*.TestCloudSchemaless|*.HdfsUnloadDistributedZkTest|*.ChaosMonkeySafeLeaderWithPullReplicasTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.seed=8834A9C1C6EEB85D -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=en-IE -Dtests.timezone=Brazil/DeNoronha -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 35447 lines...] [repro] Setting last failure code to 256 [repro] ant compile-test [...truncated 454 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestV2Request" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.seed=CB5B6E1D0C19E48A -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=ru -Dtests.timezone=America/Antigua -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 82 lines...] [repro] Failures: [repro] 0/5 failed: org.apache.solr.client.solrj.request.TestV2Request [repro] 0/5 failed: org.apache.solr.cloud.hdfs.HdfsUnloadDistributedZkTest [repro] 2/5 failed: org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest [repro] 2/5 failed: org.apache.solr.schema.TestCloudSchemaless [repro] git checkout 303d11921f19f73c0b5476c4ab4cdca0f7dd249e [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 5 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-7.x - Build # 1249 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/1249/ All tests passed Build Log: [...truncated 53560 lines...] -ecj-javadoc-lint-tests: [mkdir] Created dir: /tmp/ecj1100540928 [ecj-lint] Compiling 20 source files to /tmp/ecj1100540928 [ecj-lint] -- [ecj-lint] 1. ERROR in /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPathTest.java (at line 22) [ecj-lint] import static org.junit.Assert.assertEquals; [ecj-lint] ^ [ecj-lint] The import org.junit.Assert.assertEquals is never used [ecj-lint] -- [ecj-lint] 2. ERROR in /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPathTest.java (at line 23) [ecj-lint] import static org.junit.Assert.assertFalse; [ecj-lint] [ecj-lint] The import org.junit.Assert.assertFalse is never used [ecj-lint] -- [ecj-lint] 3. ERROR in /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPathTest.java (at line 24) [ecj-lint] import static org.junit.Assert.assertTrue; [ecj-lint] ^^^ [ecj-lint] The import org.junit.Assert.assertTrue is never used [ecj-lint] -- [ecj-lint] 3 problems (3 errors) BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/build.xml:633: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/build.xml:101: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/build.xml:207: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/common-build.xml:2268: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/common-build.xml:2099: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/common-build.xml:2132: Compile failed; see the compiler error output for details. Total time: 84 minutes 51 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
