[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 194 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/194/ 1 tests failed. FAILED: org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage Error Message: Error from server at http://127.0.0.1:40061/solr: Underlying core creation failed while creating collection: globalCacheColl Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:40061/solr: Underlying core creation failed while creating collection: globalCacheColl at __randomizedtesting.SeedInfo.seed([BF883998AEB0A67:C7DDD70781BCBC84]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage(TestContainerReqHandler.java:687) 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
[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk-12.0.1) - Build # 252 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/252/
Java: 64bit/jdk-12.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC
4 tests failed.
FAILED: org.apache.solr.handler.admin.TestApiFramework.testFramework
Error Message:
incorrect value for path /spec[0]/methods[0] in :{ "spec":[ {
"documentation":"https://lucene.apache.org/solr/guide/collection-management.html#list;,
"description":"List all available collections and their properties.",
"methods":["GET"], "url":{"paths":[ "/collections",
"/c"]}}, {
"documentation":"https://lucene.apache.org/solr/guide/collection-management.html#create;,
"description":"Create collections and collection aliases, backup or
restore collections, and delete collections and aliases.",
"methods":["POST"], "url":{"paths":[ "/collections",
"/c"]}, "commands":{ "create":{ "type":"object",
"documentation":"https://lucene.apache.org/solr/guide/collection-management.html#create;,
"description":"Create a collection.", "properties":{
"name":{ "type":"string", "description":"The
name of the collection to be created."}, "config":{
"type":"string", "description":"The name of the configuration set
(which must already be stored in ZooKeeper) to use for this collection. If not
provided, Solr will default to the collection name as the configuration set
name."}, "router":{ "type":"object",
"documentation":"https://lucene.apache.org/solr/guide/shards-and-indexing-data-in-solrcloud.html;,
"description":"These properties define how to distribute
documents across a collection's shards.", "properties":{
"name":{ "type":"string", "enum":[
"implicit", "compositeId"],
"description":"The router implementation to use for this collection. There
are two options: compositeId or implicit. The compositeId option has Solr
decide how to distribute documents (with some possibilities for customization).
The implicit option requires you define your own routing strategy, and puts the
balancing of documents in shards entirely in your hands.",
"default":"compositeId"}, "field":{
"type":"string", "description":"A field to be used by Solr to
identify the shard a document should be routed to. By default, the field
defined as the unique ID for each document is used, but an alternative field
can be defined with this parameter."}}}, "numShards":{
"type":"integer", "description":"The number of shards to be
created as part of the collection. Shards are logical partitions of a single
collection. Each shard has at least one replica, but more replicas for each
shard can be defined with the replicationFactor property. This is a required
parameter when using the 'compositeId' router."}, "shards":{
"type":"string", "description":"A comma-separated list of
shard names, e.g., shard-x,shard-y,shard-z. This is a required parameter when
using the 'implicit' router."}, "replicationFactor":{
"type":"integer", "description":"The number of NRT replicas to be
created for each shard. Replicas are physical copies of each shard, acting as
failover for the shard."}, "nrtReplicas":{
"type":"integer", "description":"The number of NRT replicas to be
created for each shard. Replicas are physical copies of each shard, acting as
failover for the shard. Replicas of type NRT will be updated with each document
that is added to the cluster, and can use \"softCommits\" to get a new view of
the index in Near Real Time. This parameter works in the same way as
'replicationFactor'"}, "tlogReplicas":{
"type":"integer", "description":"The number of TLOG replicas to
be created for each shard. TLOG replicas update their transaction log for every
update to the cluster, but only the shard leader updates the local index, other
TLOG replicas will use segment replication and copy the latest index files from
the leader."}, "pullReplicas":{ "type":"integer",
"description":"The number of PULL replicas to be created for each
shard. PULL replicas don't receive copies of the documents on update requests,
they just replicate the latest segments periodically from the shard leader.
PULL replicas can't become shard leaders, and need at least one active
TLOG(recommended) or NRT replicas in the shard to replicate from."},
"nodeSet":{ "type":"array",
[jira] [Commented] (SOLR-13717) Distributed Grouping breaks multi valued 'fl' param
[
https://issues.apache.org/jira/browse/SOLR-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914791#comment-16914791
]
Lucene/Solr QA commented on SOLR-13717:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
19s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 2m 7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 2m 7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 2m 7s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 51m
56s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 58m 34s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13717 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12978469/SOLR-13717.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 225fd3d |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/538/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/538/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Distributed Grouping breaks multi valued 'fl' param
> ---
>
> Key: SOLR-13717
> URL: https://issues.apache.org/jira/browse/SOLR-13717
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13717.patch
>
>
> Co-worker discovered a bug with (distributed) grouping when multiple {{fl}}
> params are specified.
> {{StoredFieldsShardRequestFactory}} has very (old and) brittle code that
> assumes there will be 0 or 1 {{fl}} params in the original request that it
> should inspect to see if it needs to append (via string concat) the uniqueKey
> field onto in order to collate the returned stored fields into their
> respective (grouped) documents -- and then ignores any additional {{fl}}
> params that may exist in the original request when it does so.
> The net result is that only the uniqueKey field and whatever fields _are_
> specified in the first {{fl}} param specified are fetched from each shard and
> ultimately returned.
> The only workaround is to replace multiple {{fl}} params with a single {{fl}}
> param containing a comma seperated list of the requested fields.
>
> Bug is trivial to reproduce with {{bin/solr -e cloud -noprompt}} by comparing
> these requests which should all be equivilent...
> {noformat}
> $ bin/post -c gettingstarted -out yes example/exampledocs/books.csv
> ...
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=author,name,id=*:*=true=genre_s'
> {
> "grouped":{
> "genre_s":{
> "matches":10,
> "groups":[{
> "groupValue":"fantasy",
> "doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"0812521390",
> "name":["The Black Company"],
> "author":["Glen Cook"]}]
> }},
> {
> "groupValue":"scifi",
> "doclist":{"numFound":2,"start":0,"docs":[
> {
>
[GitHub] [lucene-solr] atris commented on issue #817: SOLR-13655:Upgrade Collections.unModifiableSet to Set.of and Set.copyOf
atris commented on issue #817: SOLR-13655:Upgrade Collections.unModifiableSet to Set.of and Set.copyOf URL: https://github.com/apache/lucene-solr/pull/817#issuecomment-524513296 Thanks @tflobbe ! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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-Tests-8.x - Build # 462 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/462/ 1 tests failed. FAILED: org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage Error Message: Error from server at http://127.0.0.1:35767/solr: Underlying core creation failed while creating collection: globalCacheColl Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:35767/solr: Underlying core creation failed while creating collection: globalCacheColl at __randomizedtesting.SeedInfo.seed([8AF05BC7BD329E9F:46D50F59B665287C]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage(TestContainerReqHandler.java:687) 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
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1939 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1939/ No tests ran. Build Log: [...truncated 25 lines...] ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086) 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:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 284 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/284/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.sim.TestSimClusterStateProvider Error Message: Error starting up MiniSolrCloudCluster Stack Trace: java.lang.Exception: Error starting up MiniSolrCloudCluster at __randomizedtesting.SeedInfo.seed([F14AD537D4831DD8]:0) at org.apache.solr.cloud.MiniSolrCloudCluster.checkForExceptions(MiniSolrCloudCluster.java:654) at org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:306) at org.apache.solr.cloud.SolrCloudTestCase$Builder.build(SolrCloudTestCase.java:222) at org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:214) at org.apache.solr.cloud.autoscaling.sim.TestSimClusterStateProvider.setupCluster(TestSimClusterStateProvider.java:80) 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$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 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) Suppressed: java.lang.RuntimeException: Jetty/Solr unresponsive at org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:507) at org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:465) at org.apache.solr.cloud.MiniSolrCloudCluster.startJettySolrRunner(MiniSolrCloudCluster.java:469) at org.apache.solr.cloud.MiniSolrCloudCluster.lambda$new$0(MiniSolrCloudCluster.java:300) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ... 1 more Suppressed: java.lang.RuntimeException: Jetty/Solr unresponsive at org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:507) at org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:465) at org.apache.solr.cloud.MiniSolrCloudCluster.startJettySolrRunner(MiniSolrCloudCluster.java:469) at org.apache.solr.cloud.MiniSolrCloudCluster.lambda$new$0(MiniSolrCloudCluster.java:300) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
[jira] [Updated] (SOLR-13717) Distributed Grouping breaks multi valued 'fl' param
[
https://issues.apache.org/jira/browse/SOLR-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13717:
Status: Patch Available (was: Open)
> Distributed Grouping breaks multi valued 'fl' param
> ---
>
> Key: SOLR-13717
> URL: https://issues.apache.org/jira/browse/SOLR-13717
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13717.patch
>
>
> Co-worker discovered a bug with (distributed) grouping when multiple {{fl}}
> params are specified.
> {{StoredFieldsShardRequestFactory}} has very (old and) brittle code that
> assumes there will be 0 or 1 {{fl}} params in the original request that it
> should inspect to see if it needs to append (via string concat) the uniqueKey
> field onto in order to collate the returned stored fields into their
> respective (grouped) documents -- and then ignores any additional {{fl}}
> params that may exist in the original request when it does so.
> The net result is that only the uniqueKey field and whatever fields _are_
> specified in the first {{fl}} param specified are fetched from each shard and
> ultimately returned.
> The only workaround is to replace multiple {{fl}} params with a single {{fl}}
> param containing a comma seperated list of the requested fields.
>
> Bug is trivial to reproduce with {{bin/solr -e cloud -noprompt}} by comparing
> these requests which should all be equivilent...
> {noformat}
> $ bin/post -c gettingstarted -out yes example/exampledocs/books.csv
> ...
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=author,name,id=*:*=true=genre_s'
> {
> "grouped":{
> "genre_s":{
> "matches":10,
> "groups":[{
> "groupValue":"fantasy",
> "doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"0812521390",
> "name":["The Black Company"],
> "author":["Glen Cook"]}]
> }},
> {
> "groupValue":"scifi",
> "doclist":{"numFound":2,"start":0,"docs":[
> {
> "id":"0553293354",
> "name":["Foundation"],
> "author":["Isaac Asimov"]}]
> }}]}}}
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=author=name,id=*:*=true=genre_s'
> {
> "grouped":{
> "genre_s":{
> "matches":10,
> "groups":[{
> "groupValue":"fantasy",
> "doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"0812521390",
> "author":["Glen Cook"]}]
> }},
> {
> "groupValue":"scifi",
> "doclist":{"numFound":2,"start":0,"docs":[
> {
> "id":"0553293354",
> "author":["Isaac Asimov"]}]
> }}]}}}
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=id=author=name=*:*=true=genre_s'
> {
> "grouped":{
> "genre_s":{
> "matches":10,
> "groups":[{
> "groupValue":"fantasy",
> "doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"0553573403"}]
> }},
> {
> "groupValue":"scifi",
> "doclist":{"numFound":2,"start":0,"docs":[
> {
> "id":"0553293354"}]
> }}]}}}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13717) Distributed Grouping breaks multi valued 'fl' param
[
https://issues.apache.org/jira/browse/SOLR-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13717:
Attachment: SOLR-13717.patch
Status: Open (was: Open)
Attached patch includes a fix and some new test coverage of distributed
grouping w/various options comparing the results when using a single {{fl}} vs
equivilent multivalued {{fl}} params.
> Distributed Grouping breaks multi valued 'fl' param
> ---
>
> Key: SOLR-13717
> URL: https://issues.apache.org/jira/browse/SOLR-13717
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13717.patch
>
>
> Co-worker discovered a bug with (distributed) grouping when multiple {{fl}}
> params are specified.
> {{StoredFieldsShardRequestFactory}} has very (old and) brittle code that
> assumes there will be 0 or 1 {{fl}} params in the original request that it
> should inspect to see if it needs to append (via string concat) the uniqueKey
> field onto in order to collate the returned stored fields into their
> respective (grouped) documents -- and then ignores any additional {{fl}}
> params that may exist in the original request when it does so.
> The net result is that only the uniqueKey field and whatever fields _are_
> specified in the first {{fl}} param specified are fetched from each shard and
> ultimately returned.
> The only workaround is to replace multiple {{fl}} params with a single {{fl}}
> param containing a comma seperated list of the requested fields.
>
> Bug is trivial to reproduce with {{bin/solr -e cloud -noprompt}} by comparing
> these requests which should all be equivilent...
> {noformat}
> $ bin/post -c gettingstarted -out yes example/exampledocs/books.csv
> ...
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=author,name,id=*:*=true=genre_s'
> {
> "grouped":{
> "genre_s":{
> "matches":10,
> "groups":[{
> "groupValue":"fantasy",
> "doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"0812521390",
> "name":["The Black Company"],
> "author":["Glen Cook"]}]
> }},
> {
> "groupValue":"scifi",
> "doclist":{"numFound":2,"start":0,"docs":[
> {
> "id":"0553293354",
> "name":["Foundation"],
> "author":["Isaac Asimov"]}]
> }}]}}}
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=author=name,id=*:*=true=genre_s'
> {
> "grouped":{
> "genre_s":{
> "matches":10,
> "groups":[{
> "groupValue":"fantasy",
> "doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"0812521390",
> "author":["Glen Cook"]}]
> }},
> {
> "groupValue":"scifi",
> "doclist":{"numFound":2,"start":0,"docs":[
> {
> "id":"0553293354",
> "author":["Isaac Asimov"]}]
> }}]}}}
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=id=author=name=*:*=true=genre_s'
> {
> "grouped":{
> "genre_s":{
> "matches":10,
> "groups":[{
> "groupValue":"fantasy",
> "doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"0553573403"}]
> }},
> {
> "groupValue":"scifi",
> "doclist":{"numFound":2,"start":0,"docs":[
> {
> "id":"0553293354"}]
> }}]}}}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13717) Distributed Grouping breaks multi valued 'fl' param
Hoss Man created SOLR-13717:
---
Summary: Distributed Grouping breaks multi valued 'fl' param
Key: SOLR-13717
URL: https://issues.apache.org/jira/browse/SOLR-13717
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man
Co-worker discovered a bug with (distributed) grouping when multiple {{fl}}
params are specified.
{{StoredFieldsShardRequestFactory}} has very (old and) brittle code that
assumes there will be 0 or 1 {{fl}} params in the original request that it
should inspect to see if it needs to append (via string concat) the uniqueKey
field onto in order to collate the returned stored fields into their respective
(grouped) documents -- and then ignores any additional {{fl}} params that may
exist in the original request when it does so.
The net result is that only the uniqueKey field and whatever fields _are_
specified in the first {{fl}} param specified are fetched from each shard and
ultimately returned.
The only workaround is to replace multiple {{fl}} params with a single {{fl}}
param containing a comma seperated list of the requested fields.
Bug is trivial to reproduce with {{bin/solr -e cloud -noprompt}} by comparing
these requests which should all be equivilent...
{noformat}
$ bin/post -c gettingstarted -out yes example/exampledocs/books.csv
...
$ curl
'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=author,name,id=*:*=true=genre_s'
{
"grouped":{
"genre_s":{
"matches":10,
"groups":[{
"groupValue":"fantasy",
"doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
{
"id":"0812521390",
"name":["The Black Company"],
"author":["Glen Cook"]}]
}},
{
"groupValue":"scifi",
"doclist":{"numFound":2,"start":0,"docs":[
{
"id":"0553293354",
"name":["Foundation"],
"author":["Isaac Asimov"]}]
}}]}}}
$ curl
'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=author=name,id=*:*=true=genre_s'
{
"grouped":{
"genre_s":{
"matches":10,
"groups":[{
"groupValue":"fantasy",
"doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
{
"id":"0812521390",
"author":["Glen Cook"]}]
}},
{
"groupValue":"scifi",
"doclist":{"numFound":2,"start":0,"docs":[
{
"id":"0553293354",
"author":["Isaac Asimov"]}]
}}]}}}
$ curl
'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=id=author=name=*:*=true=genre_s'
{
"grouped":{
"genre_s":{
"matches":10,
"groups":[{
"groupValue":"fantasy",
"doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
{
"id":"0553573403"}]
}},
{
"groupValue":"scifi",
"doclist":{"numFound":2,"start":0,"docs":[
{
"id":"0553293354"}]
}}]}}}
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk1.8.0) - Build # 291 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/291/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 5 tests failed. FAILED: org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage Error Message: Error from server at http://127.0.0.1:50681/solr: Underlying core creation failed while creating collection: globalCacheColl Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:50681/solr: Underlying core creation failed while creating collection: globalCacheColl at __randomizedtesting.SeedInfo.seed([BEBE936614E6EEDA:729BC7F81FB15839]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage(TestContainerReqHandler.java:687) 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
[JENKINS] Lucene-Solr-repro - Build # 3558 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3558/ [...truncated 30 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/461/consoleText [repro] Revision: 035d823acf752d5794cfd07e133a918f0fb6b8c6 [repro] Repro line: ant test -Dtestcase=TestContainerReqHandler -Dtests.method=testCacheLoadFromPackage -Dtests.seed=F1A44D698E3AC626 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=mt -Dtests.timezone=America/Guadeloupe -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: 225fd3d8ee4b7853cdf6c06448e8d4b9cec859c3 [repro] git fetch [repro] git checkout 035d823acf752d5794cfd07e133a918f0fb6b8c6 [...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] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.seed=F1A44D698E3AC626 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=mt -Dtests.timezone=America/Guadeloupe -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 22665 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] Re-testing 100% failures at the tip of branch_8x [repro] git fetch [repro] git checkout branch_8x [...truncated 4 lines...] [repro] git merge --ff-only [...truncated 8 lines...] [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.seed=F1A44D698E3AC626 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=mt -Dtests.timezone=America/Guadeloupe -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 22482 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] Re-testing 100% failures at the tip of branch_8x without a seed [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=mt -Dtests.timezone=America/Guadeloupe -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 22551 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x without a seed: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] git checkout 225fd3d8ee4b7853cdf6c06448e8d4b9cec859c3 [...truncated 8 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
[jira] [Updated] (SOLR-13683) SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
[
https://issues.apache.org/jira/browse/SOLR-13683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niranjan Nanda updated SOLR-13683:
--
Affects Version/s: (was: 8.1.1)
8.2
> SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
> -
>
> Key: SOLR-13683
> URL: https://issues.apache.org/jira/browse/SOLR-13683
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java
>Affects Versions: 8.2
>Reporter: Niranjan Nanda
>Priority: Minor
>
> Currently {{Http2SolrClient}} does not allow configuring custom headers. For
> example, how to pass Basic Auth headers? It should expose some builder APIs
> to pass such headers.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13683) SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
[
https://issues.apache.org/jira/browse/SOLR-13683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914714#comment-16914714
]
Niranjan Nanda edited comment on SOLR-13683 at 8/24/19 12:12 AM:
-
I am not sure; but I do not think you guys have decoupled yourself completely
from Jetty. For example {{*_HttpListenerFactory_*}} uses the Jetty APIs. If you
really want to abstract users of your APIs completely from underneath HTTP
libraries, you should define your own abstraction for everything - connection
pool size (may be type too), timeouts - everything globally applicable to HTTP.
The API {{*_Http2SolrClient_*}} is not very clear in intent.
- It allows setting max connection per host, connection timeout - which are
HTTP related, but not setting HTTP headers. Why is so?
- The {{*_addListenerFactory()_*}} of {{*_Http2SolrClient_*}} should be part of
its {{*_Builder_*}}. Current approach is confusing (a void method set on an
instance).
was (Author: nnanda):
I am not sure; but I do not think you guys have decoupled yourself completely
from Jetty. For example {{*_HttpListenerFactory_*}} uses the Jetty APIs. If you
really want to abstract users of your APIs completely from underneath HTTP
libraries, you should define your own abstraction for everything - connection
pool size (may be type too), timeouts - everything globally applicable to HTTP.
The API {{*_Http2SolrClient_*}} is not very clear in intent. It allows setting
max connection per host, connection timeout - which are HTTP related, but not
setting HTTP headers. Why is so?
> SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
> -
>
> Key: SOLR-13683
> URL: https://issues.apache.org/jira/browse/SOLR-13683
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java
>Affects Versions: 8.1.1
>Reporter: Niranjan Nanda
>Priority: Minor
>
> Currently {{Http2SolrClient}} does not allow configuring custom headers. For
> example, how to pass Basic Auth headers? It should expose some builder APIs
> to pass such headers.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 3611 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3611/
All tests passed
Build Log:
[...truncated 64487 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1535368801
[ecj-lint] Compiling 733 source files to /tmp/ecj1535368801
[ecj-lint] --
[ecj-lint] 1. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java
(at line 22)
[ecj-lint] import java.util.Arrays;
[ecj-lint]
[ecj-lint] The import java.util.Arrays is never used
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Variable.java
(at line 24)
[ecj-lint] import java.util.Arrays;
[ecj-lint]
[ecj-lint] The import java.util.Arrays is never used
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/ConcatEvaluator.java
(at line 46)
[ecj-lint] public Object doWork(Object values[]) throws IOException {
[ecj-lint] ^^
[ecj-lint] Varargs methods should only override or be overridden by other
varargs methods unlike ConcatEvaluator.doWork(Object[]) and
ManyValueWorker.doWork(Object...)
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/DateEvaluator.java
(at line 44)
[ecj-lint] public Object doWork(Object values[]) throws IOException {
[ecj-lint] ^^
[ecj-lint] Varargs methods should only override or be overridden by other
varargs methods unlike DateEvaluator.doWork(Object[]) and
ManyValueWorker.doWork(Object...)
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/EmpiricalDistributionEvaluator.java
(at line 41)
[ecj-lint] public Object doWork(Object[] values) throws IOException {
[ecj-lint] ^^
[ecj-lint] Varargs methods should only override or be overridden by other
varargs methods unlike EmpiricalDistributionEvaluator.doWork(Object[]) and
ManyValueWorker.doWork(Object...)
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 6. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/MatchesEvaluator.java
(at line 39)
[ecj-lint] public Object doWork(Object[] values) throws IOException {
[ecj-lint] ^^
[ecj-lint] Varargs methods should only override or be overridden by other
varargs methods unlike MatchesEvaluator.doWork(Object[]) and
ManyValueWorker.doWork(Object...)
[ecj-lint] --
[ecj-lint] 7. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/MatchesEvaluator.java
(at line 39)
[ecj-lint] public Object doWork(Object[] values) throws IOException {
[ecj-lint] ^^
[ecj-lint] Varargs methods should only override or be overridden by other
varargs methods unlike MatchesEvaluator.doWork(Object[]) and
RecursiveBooleanEvaluator.doWork(Object...)
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 8. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/solrj/src/java/org/apache/solr/client/solrj/io/eval/PivotEvaluator.java
(at line 45)
[ecj-lint] public Object doWork(Object[] values) throws IOException {
[ecj-lint] ^^
[ecj-lint] Varargs methods should only override or be overridden by other
varargs methods unlike PivotEvaluator.doWork(Object[]) and
ManyValueWorker.doWork(Object...)
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 9. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/MergeStream.java
(at line 197)
[ecj-lint] minimumStream = stream;
[ecj-lint] ^^
[ecj-lint] Resource leak: 'stream' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 10. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/solrj/src/java/org/apache/solr/client/solrj/request/MultiContentWriterRequest.java
(at line 63)
[ecj-lint] new JavaBinCodec().marshal((IteratorWriter) iw -> {
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never
[jira] [Commented] (SOLR-13683) SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
[
https://issues.apache.org/jira/browse/SOLR-13683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914714#comment-16914714
]
Niranjan Nanda commented on SOLR-13683:
---
I am not sure; but I do not think you guys have decoupled yourself completely
from Jetty. For example {{*_HttpListenerFactory_*}} uses the Jetty APIs. If you
really want to abstract users of your APIs completely from underneath HTTP
libraries, you should define your own abstraction for everything - connection
pool size (may be type too), timeouts - everything globally applicable to HTTP.
The API {{*_Http2SolrClient_*}} is not very clear in intent. It allows setting
max connection per host, connection timeout - which are HTTP related, but not
setting HTTP headers. Why is so?
> SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
> -
>
> Key: SOLR-13683
> URL: https://issues.apache.org/jira/browse/SOLR-13683
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java
>Affects Versions: 8.1.1
>Reporter: Niranjan Nanda
>Priority: Minor
>
> Currently {{Http2SolrClient}} does not allow configuring custom headers. For
> example, how to pass Basic Auth headers? It should expose some builder APIs
> to pass such headers.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13699) maxChars no longer working as designed on CopyField
[ https://issues.apache.org/jira/browse/SOLR-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914711#comment-16914711 ] Noble Paul commented on SOLR-13699: --- You can submit a PR and I can merge it > maxChars no longer working as designed on CopyField > --- > > Key: SOLR-13699 > URL: https://issues.apache.org/jira/browse/SOLR-13699 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, > 8.1.2 >Reporter: Chris Troullis >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13699.patch, SOLR-13699.patch > > > We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars > property on a copy field is no longer functioning as designed, while indexing > via SolrJ. Per the most recent documentation it looks like there have been no > intentional changes as to the functionality of this property, so I assume > this is a bug. > > In debugging the issue, it looks like the bug was caused by SOLR-12992. In > DocumentBuilder where the maxChar limit is applied, it first checks if the > value is instanceof String. As of SOLR-12992, string values are now coming in > as ByteArrayUtf8CharSequence (unless they are above a certain size as defined > by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String > check, and the maxChar truncation is not being applied. I am currently not > sure if this issue is limited to indexing via SolrJ or if it applies to > documents indexed via any means -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8956) QueryRescorer sort optimization
[
https://issues.apache.org/jira/browse/LUCENE-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914694#comment-16914694
]
Lucene/Solr QA commented on LUCENE-8956:
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
26s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 0m 25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 0m 25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 0m 25s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 28m
21s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 31m 3s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8956 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12978446/LUCENE-8956.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / f335ac9 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-LUCENE-Build/202/testReport/ |
| modules | C: lucene/core U: lucene/core |
| Console output |
https://builds.apache.org/job/PreCommit-LUCENE-Build/202/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> QueryRescorer sort optimization
> ---
>
> Key: LUCENE-8956
> URL: https://issues.apache.org/jira/browse/LUCENE-8956
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/query/scoring
>Reporter: Paul Sanwald
>Priority: Minor
> Attachments: LUCENE-8956.patch
>
>
> This patch addresses a TODO in QueryRescorer: We should not sort the full
> array of the results returned from rescoring, but rather only topN, when topN
> is less than total hits.
>
> Made this optimization with some suggestions from [~jpountz] and [~jimczi],
> this is my first lucene patch submission.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13655) Cut Over Collections.unmodifiableSet usages to Set.*
[ https://issues.apache.org/jira/browse/SOLR-13655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914690#comment-16914690 ] ASF subversion and git services commented on SOLR-13655: Commit 225fd3d8ee4b7853cdf6c06448e8d4b9cec859c3 in lucene-solr's branch refs/heads/master from Tomas Eduardo Fernandez Lobbe [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=225fd3d ] SOLR-13655: Fix precommit > Cut Over Collections.unmodifiableSet usages to Set.* > > > Key: SOLR-13655 > URL: https://issues.apache.org/jira/browse/SOLR-13655 > Project: Solr > Issue Type: Improvement >Reporter: Atri Sharma >Priority: Major > Fix For: master (9.0) > > Time Spent: 2h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11601) geodist fails for some fields when field is in parenthesis instead of sfield param
[
https://issues.apache.org/jira/browse/SOLR-11601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-11601:
Fix Version/s: 8.3
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks for contributing the fix Amrit. Feel free to prod us when we neglect to
pay attention to your waiting patches :-)
Note I moved the test from TestGeoJSONResponseWriter to TestSolr4Spatial2
because it had nothing to do with geojson.
> geodist fails for some fields when field is in parenthesis instead of sfield
> param
> --
>
> Key: SOLR-11601
> URL: https://issues.apache.org/jira/browse/SOLR-11601
> Project: Solr
> Issue Type: Improvement
> Components: spatial
>Affects Versions: 6.6
>Reporter: Clemens Wyss
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.3
>
> Attachments: SOLR-11601.patch, SOLR-11601.patch, SOLR-11601.patch
>
>
> Im switching my schemas from derprecated solr.LatLonType to
> solr.LatLonPointSpatialField.
> Now my sortquery (which used to work with solr.LatLonType):
> *sort=geodist(b4_location__geo_si,47.36667,8.55) asc*
> raises the error
> {color:red}*"sort param could not be parsed as a query, and is not a field
> that exists in the index: geodist(b4_location__geo_si,47.36667,8.55)"*{color}
> Invoking sort using syntax
> {color:#14892c}sfield=b4_location__geo_si=47.36667,8.55=geodist() asc
> works as expected though...{color}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11601) geodist fails for some fields when field is in parenthesis instead of sfield param
[
https://issues.apache.org/jira/browse/SOLR-11601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914680#comment-16914680
]
ASF subversion and git services commented on SOLR-11601:
Commit cac4d012e1a8db4b3033bb902c9fa932f10f in lucene-solr's branch
refs/heads/branch_8x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cac4d01 ]
SOLR-11601: Improve geodist error message when using with LLPSF.
(cherry picked from commit f335ac9bbc52fef3468ca69890bf9ba95053f8b5)
> geodist fails for some fields when field is in parenthesis instead of sfield
> param
> --
>
> Key: SOLR-11601
> URL: https://issues.apache.org/jira/browse/SOLR-11601
> Project: Solr
> Issue Type: Improvement
> Components: spatial
>Affects Versions: 6.6
>Reporter: Clemens Wyss
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-11601.patch, SOLR-11601.patch, SOLR-11601.patch
>
>
> Im switching my schemas from derprecated solr.LatLonType to
> solr.LatLonPointSpatialField.
> Now my sortquery (which used to work with solr.LatLonType):
> *sort=geodist(b4_location__geo_si,47.36667,8.55) asc*
> raises the error
> {color:red}*"sort param could not be parsed as a query, and is not a field
> that exists in the index: geodist(b4_location__geo_si,47.36667,8.55)"*{color}
> Invoking sort using syntax
> {color:#14892c}sfield=b4_location__geo_si=47.36667,8.55=geodist() asc
> works as expected though...{color}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11601) geodist fails for some fields when field is in parenthesis instead of sfield param
[
https://issues.apache.org/jira/browse/SOLR-11601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914679#comment-16914679
]
ASF subversion and git services commented on SOLR-11601:
Commit f335ac9bbc52fef3468ca69890bf9ba95053f8b5 in lucene-solr's branch
refs/heads/master from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f335ac9 ]
SOLR-11601: Improve geodist error message when using with LLPSF.
> geodist fails for some fields when field is in parenthesis instead of sfield
> param
> --
>
> Key: SOLR-11601
> URL: https://issues.apache.org/jira/browse/SOLR-11601
> Project: Solr
> Issue Type: Improvement
> Components: spatial
>Affects Versions: 6.6
>Reporter: Clemens Wyss
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-11601.patch, SOLR-11601.patch, SOLR-11601.patch
>
>
> Im switching my schemas from derprecated solr.LatLonType to
> solr.LatLonPointSpatialField.
> Now my sortquery (which used to work with solr.LatLonType):
> *sort=geodist(b4_location__geo_si,47.36667,8.55) asc*
> raises the error
> {color:red}*"sort param could not be parsed as a query, and is not a field
> that exists in the index: geodist(b4_location__geo_si,47.36667,8.55)"*{color}
> Invoking sort using syntax
> {color:#14892c}sfield=b4_location__geo_si=47.36667,8.55=geodist() asc
> works as expected though...{color}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 3557 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3557/ [...truncated 33 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/460/consoleText [repro] Revision: f3c7bbf79e35dc7429e8ec439dacd09b9c969a54 [repro] Repro line: ant test -Dtestcase=TestContainerReqHandler -Dtests.method=testCacheLoadFromPackage -Dtests.seed=A074C1A9D3F81AFD -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=tr -Dtests.timezone=America/La_Paz -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 180f6d2ec970eee165320385f5099dbabc71725d [repro] git fetch [repro] git checkout f3c7bbf79e35dc7429e8ec439dacd09b9c969a54 [...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] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.seed=A074C1A9D3F81AFD -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=tr -Dtests.timezone=America/La_Paz -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 22970 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] Re-testing 100% failures at the tip of branch_8x [repro] git fetch [repro] git checkout branch_8x [...truncated 3 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.seed=A074C1A9D3F81AFD -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=tr -Dtests.timezone=America/La_Paz -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 22950 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] Re-testing 100% failures at the tip of branch_8x without a seed [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=tr -Dtests.timezone=America/La_Paz -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 23175 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x without a seed: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] git checkout 180f6d2ec970eee165320385f5099dbabc71725d [...truncated 8 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-NightlyTests-8.x - Build # 190 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/190/ No tests ran. Build Log: [...truncated 25 lines...] ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086) 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:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[JENKINS] Lucene-Solr-Tests-8.x - Build # 461 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/461/ 1 tests failed. FAILED: org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage Error Message: Error from server at http://127.0.0.1:41965/solr: Underlying core creation failed while creating collection: globalCacheColl Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:41965/solr: Underlying core creation failed while creating collection: globalCacheColl at __randomizedtesting.SeedInfo.seed([F1A44D698E3AC626:3D8119F7856D70C5]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage(TestContainerReqHandler.java:687) 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
[JENKINS] Lucene-Solr-8.x-Linux (32bit/jdk1.8.0_201) - Build # 1068 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/1068/ Java: 32bit/jdk1.8.0_201 -server -XX:+UseConcMarkSweepGC 4 tests failed. FAILED: org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage Error Message: Error from server at http://127.0.0.1:40215/solr: Underlying core creation failed while creating collection: globalCacheColl Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:40215/solr: Underlying core creation failed while creating collection: globalCacheColl at __randomizedtesting.SeedInfo.seed([1D3924D402F6047C:D11C704A09A1B29F]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage(TestContainerReqHandler.java:687) 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
[jira] [Commented] (SOLR-13709) Race condition on core reload while core is still loading?
[
https://issues.apache.org/jira/browse/SOLR-13709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914665#comment-16914665
]
Hoss Man commented on SOLR-13709:
-
{quote}Is there a possibility that this is happening before
CoreContainer.load() is finished?
{quote}
it's absolutely possible – that's the point i made when i created this issue:
bq. ...AFAICT the only way this NPE is possily is if the CoreDescriptor for the
original SolrCore is NULL at the time the watcher fires, and the only
concievable way that seems to be possible is if the original SolrCore hadn't
completley finished loading.
Acording to the docs of that method it _should_ block until the core is loaded,
but the ZkWatcher thread in question -- set by the SolrCore durring it's own
init in order to reload the core if the schema changes -- is calling
{{getCoreDescriptor()}} in order to reload the core and getting null.
> Race condition on core reload while core is still loading?
> --
>
> Key: SOLR-13709
> URL: https://issues.apache.org/jira/browse/SOLR-13709
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Erick Erickson
>Priority: Major
> Attachments: apache_Lucene-Solr-Tests-8.x_449.log.txt
>
>
> A recent jenkins failure from {{TestSolrCLIRunExample}} seems to suggest that
> there may be a race condition when attempting to re-load a SolrCore while the
> core is currently in the process of (re)loading that can leave the SolrCore
> in an unusable state.
> Details to follow...
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 3610 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3610/ 2 tests failed. FAILED: org.apache.lucene.classification.utils.ConfusionMatrixGeneratorTest.testGetConfusionMatrixWithSNB Error Message: expected:<7> but was:<6> Stack Trace: java.lang.AssertionError: expected:<7> but was:<6> at __randomizedtesting.SeedInfo.seed([5C4D32B8DC84AD6B:95D1360B6380CB18]: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.junit.Assert.assertEquals(Assert.java:631) at org.apache.lucene.classification.utils.ConfusionMatrixGeneratorTest.checkCM(ConfusionMatrixGeneratorTest.java:110) at org.apache.lucene.classification.utils.ConfusionMatrixGeneratorTest.testGetConfusionMatrixWithSNB(ConfusionMatrixGeneratorTest.java:99) 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:566) 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.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 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:834) FAILED: org.apache.solr.cloud.MigrateRouteKeyTest.multipleShardMigrateTest Error Message: DocCount on target collection does not match expected:<19> but was:<0> Stack Trace: java.lang.AssertionError: DocCount on target collection does not match expected:<19> but was:<0> at __randomizedtesting.SeedInfo.seed([9D0D2F11282B2AB0:811D356B09EB9A51]:0) at org.junit.Assert.fail(Assert.java:88) at
[jira] [Commented] (SOLR-13709) Race condition on core reload while core is still loading?
[
https://issues.apache.org/jira/browse/SOLR-13709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914659#comment-16914659
]
Erick Erickson commented on SOLR-13709:
---
[~hossman] Take two, my investigations.
I don't see how core descriptors can be null. The modifyLock is all about list
keeping, _not_ successfully loading the cores. And it should be fully populated
by the time CoreContainer.load() is finished.
Is there a possibility that this is happening before CoreContainer.load() is
finished?
Except... core descriptors are removed from the underlying list when the core
is unloaded. I wonder if that's somehow in the mix.
Anyway, I'll put some logging in and beast it to see what I can see.
Thanks for sleuthing!
> Race condition on core reload while core is still loading?
> --
>
> Key: SOLR-13709
> URL: https://issues.apache.org/jira/browse/SOLR-13709
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Erick Erickson
>Priority: Major
> Attachments: apache_Lucene-Solr-Tests-8.x_449.log.txt
>
>
> A recent jenkins failure from {{TestSolrCLIRunExample}} seems to suggest that
> there may be a race condition when attempting to re-load a SolrCore while the
> core is currently in the process of (re)loading that can leave the SolrCore
> in an unusable state.
> Details to follow...
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe commented on issue #817: SOLR-13655:Upgrade Collections.unModifiableSet to Set.of and Set.copyOf
tflobbe commented on issue #817: SOLR-13655:Upgrade Collections.unModifiableSet to Set.of and Set.copyOf URL: https://github.com/apache/lucene-solr/pull/817#issuecomment-524470040 Thanks @atris! squashed/merged This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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] [Resolved] (SOLR-13655) Cut Over Collections.unmodifiableSet usages to Set.*
[ https://issues.apache.org/jira/browse/SOLR-13655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomás Fernández Löbbe resolved SOLR-13655. -- Fix Version/s: master (9.0) Resolution: Fixed > Cut Over Collections.unmodifiableSet usages to Set.* > > > Key: SOLR-13655 > URL: https://issues.apache.org/jira/browse/SOLR-13655 > Project: Solr > Issue Type: Improvement >Reporter: Atri Sharma >Priority: Major > Fix For: master (9.0) > > Time Spent: 1h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13655) Cut Over Collections.unmodifiableSet usages to Set.*
[ https://issues.apache.org/jira/browse/SOLR-13655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914650#comment-16914650 ] ASF subversion and git services commented on SOLR-13655: Commit 180f6d2ec970eee165320385f5099dbabc71725d in lucene-solr's branch refs/heads/master from Tomas Eduardo Fernandez Lobbe [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=180f6d2 ] SOLR-13655: Added CHANGES entry > Cut Over Collections.unmodifiableSet usages to Set.* > > > Key: SOLR-13655 > URL: https://issues.apache.org/jira/browse/SOLR-13655 > Project: Solr > Issue Type: Improvement >Reporter: Atri Sharma >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13655) Cut Over Collections.unmodifiableSet usages to Set.*
[ https://issues.apache.org/jira/browse/SOLR-13655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomás Fernández Löbbe updated SOLR-13655: - Summary: Cut Over Collections.unmodifiableSet usages to Set.* (was: Cut Over Collections.unmodifiedSet usages to Set.*) > Cut Over Collections.unmodifiableSet usages to Set.* > > > Key: SOLR-13655 > URL: https://issues.apache.org/jira/browse/SOLR-13655 > Project: Solr > Issue Type: Improvement >Reporter: Atri Sharma >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13655) Cut Over Collections.unmodifiedSet usages to Set.*
[ https://issues.apache.org/jira/browse/SOLR-13655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914647#comment-16914647 ] ASF subversion and git services commented on SOLR-13655: Commit 19aecb0f7da078880aae0ec7e70eb8e00429d3d5 in lucene-solr's branch refs/heads/master from Atri Sharma [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=19aecb0 ] SOLR-13655:Upgrade Collections.unModifiableSet to Set.of and Set.copyOf (#817) > Cut Over Collections.unmodifiedSet usages to Set.* > -- > > Key: SOLR-13655 > URL: https://issues.apache.org/jira/browse/SOLR-13655 > Project: Solr > Issue Type: Improvement >Reporter: Atri Sharma >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe merged pull request #817: SOLR-13655:Upgrade Collections.unModifiableSet to Set.of and Set.copyOf
tflobbe merged pull request #817: SOLR-13655:Upgrade Collections.unModifiableSet to Set.of and Set.copyOf URL: https://github.com/apache/lucene-solr/pull/817 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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-13709) Race condition on core reload while core is still loading?
[
https://issues.apache.org/jira/browse/SOLR-13709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914633#comment-16914633
]
Erick Erickson edited comment on SOLR-13709 at 8/23/19 9:04 PM:
Deleted comment because it's bogus. I'll try again
was (Author: erickerickson):
[~hossman] I'm hopping in the wayback machine. That said:
AFAICT, that comment in SolrCores.getCoreDescriptor is totally bogus and has
been since at least 2015.
There are various lists that are maintained so multiple threads can open, close
and reload cores etc. modifyLock is mostly used to coordinate multiple threads
making changes to the lists, _not_ to deal with the underlying operations. So
you're right, there is no blocking being done.
That said, getCoreDescriptor shouldn't be sensitive to whether the core is
loaded or not, it should be solely about bookkeeping _descriptors_. But it's
not. Over in CoreContainer, after all the cores have been discovered, there's
this code:
{code}
if (cd.isTransient() || !cd.isLoadOnStartup()) {
solrCores.addCoreDescriptor(cd);
} else if (asyncSolrCoreLoad) {
solrCores.markCoreAsLoading(cd);
}
if (cd.isLoadOnStartup()) {
futures.add(coreLoadExecutor.submit(() -> {
{code}
Eventually, if isLoadOnStartup is true the descriptor does get added to the
core descriptor list as part of the core creation process. So some descriptors
are available before and some after core discovery and that may be where the
race condition is coming from.
I'll play around a bit with what happens if we just add all the descriptors to
the internal lists before any cores are loaded, that seems like the right thing
to do. After all, the lazily-loaded cores peacefully exist with a descriptor
but no loaded core and "the right thing" happens when the core is referenced so
I believe it should be OK.
Of course I have some fears that something else will pop out, but blocking on
core load in getCoreDescriptor seems dangerous too, long-to-infinite delays if
someone happens to ask for a core that is simply not there and never will be.
And any timeout we choose will be wrong.
I'll assign this to myself for the nonce. If this doesn't break anything (and
I'll beast several tests a lot over the weekend) then maybe we can circle back
next week to see if any proposed changed make sense.
How often do you see this failure? I'll put an e-mail filter in place to see
how often we see "Unable to reload core" and collect some history about how
often this happens so we can have some confidence it actually gets fixed if I
can come up with some code.
Thanks for sleuthing this!
> Race condition on core reload while core is still loading?
> --
>
> Key: SOLR-13709
> URL: https://issues.apache.org/jira/browse/SOLR-13709
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Erick Erickson
>Priority: Major
> Attachments: apache_Lucene-Solr-Tests-8.x_449.log.txt
>
>
> A recent jenkins failure from {{TestSolrCLIRunExample}} seems to suggest that
> there may be a race condition when attempting to re-load a SolrCore while the
> core is currently in the process of (re)loading that can leave the SolrCore
> in an unusable state.
> Details to follow...
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13709) Race condition on core reload while core is still loading?
[
https://issues.apache.org/jira/browse/SOLR-13709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914633#comment-16914633
]
Erick Erickson commented on SOLR-13709:
---
[~hossman] I'm hopping in the wayback machine. That said:
AFAICT, that comment in SolrCores.getCoreDescriptor is totally bogus and has
been since at least 2015.
There are various lists that are maintained so multiple threads can open, close
and reload cores etc. modifyLock is mostly used to coordinate multiple threads
making changes to the lists, _not_ to deal with the underlying operations. So
you're right, there is no blocking being done.
That said, getCoreDescriptor shouldn't be sensitive to whether the core is
loaded or not, it should be solely about bookkeeping _descriptors_. But it's
not. Over in CoreContainer, after all the cores have been discovered, there's
this code:
{code}
if (cd.isTransient() || !cd.isLoadOnStartup()) {
solrCores.addCoreDescriptor(cd);
} else if (asyncSolrCoreLoad) {
solrCores.markCoreAsLoading(cd);
}
if (cd.isLoadOnStartup()) {
futures.add(coreLoadExecutor.submit(() -> {
{code}
Eventually, if isLoadOnStartup is true the descriptor does get added to the
core descriptor list as part of the core creation process. So some descriptors
are available before and some after core discovery and that may be where the
race condition is coming from.
I'll play around a bit with what happens if we just add all the descriptors to
the internal lists before any cores are loaded, that seems like the right thing
to do. After all, the lazily-loaded cores peacefully exist with a descriptor
but no loaded core and "the right thing" happens when the core is referenced so
I believe it should be OK.
Of course I have some fears that something else will pop out, but blocking on
core load in getCoreDescriptor seems dangerous too, long-to-infinite delays if
someone happens to ask for a core that is simply not there and never will be.
And any timeout we choose will be wrong.
I'll assign this to myself for the nonce. If this doesn't break anything (and
I'll beast several tests a lot over the weekend) then maybe we can circle back
next week to see if any proposed changed make sense.
How often do you see this failure? I'll put an e-mail filter in place to see
how often we see "Unable to reload core" and collect some history about how
often this happens so we can have some confidence it actually gets fixed if I
can come up with some code.
Thanks for sleuthing this!
> Race condition on core reload while core is still loading?
> --
>
> Key: SOLR-13709
> URL: https://issues.apache.org/jira/browse/SOLR-13709
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Priority: Major
> Attachments: apache_Lucene-Solr-Tests-8.x_449.log.txt
>
>
> A recent jenkins failure from {{TestSolrCLIRunExample}} seems to suggest that
> there may be a race condition when attempting to re-load a SolrCore while the
> core is currently in the process of (re)loading that can leave the SolrCore
> in an unusable state.
> Details to follow...
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13709) Race condition on core reload while core is still loading?
[
https://issues.apache.org/jira/browse/SOLR-13709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reassigned SOLR-13709:
-
Assignee: Erick Erickson
> Race condition on core reload while core is still loading?
> --
>
> Key: SOLR-13709
> URL: https://issues.apache.org/jira/browse/SOLR-13709
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Erick Erickson
>Priority: Major
> Attachments: apache_Lucene-Solr-Tests-8.x_449.log.txt
>
>
> A recent jenkins failure from {{TestSolrCLIRunExample}} seems to suggest that
> there may be a race condition when attempting to re-load a SolrCore while the
> core is currently in the process of (re)loading that can leave the SolrCore
> in an unusable state.
> Details to follow...
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8860) LatLonShapeBoundingBoxQuery could make more decisions on inner nodes
[ https://issues.apache.org/jira/browse/LUCENE-8860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914594#comment-16914594 ] Igor Motov commented on LUCENE-8860: Thanks! It is clear now. I think I understood the part about the bounding box queries and I opened PR based on it. Unfortunately, I don't see how to extend this to the polygons queries. If we take a look at the fig3, the bounding box for the red query completely encapsulates the green polygon's bounding box and yet, we cannot make any conclusion about their intersection based on this information. !fig3.png! > LatLonShapeBoundingBoxQuery could make more decisions on inner nodes > > > Key: LUCENE-8860 > URL: https://issues.apache.org/jira/browse/LUCENE-8860 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Attachments: fig1.png, fig2.png, fig3.png > > Time Spent: 10m > Remaining Estimate: 0h > > Currently LatLonShapeBoundingBoxQuery with the INTERSECTS relation only > returns CELL_INSIDE_QUERY if the query contains ALL minimum bounding > rectangles of the indexed triangles. > I think we could return CELL_INSIDE_QUERY if the box contains either of the > edges of all MBRs of indexed triangles since triangles are guaranteed to > touch all edges of their MBR by definition. In some cases this would help > save decoding triangles and running costly point-in-triangle computations. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8860) LatLonShapeBoundingBoxQuery could make more decisions on inner nodes
[ https://issues.apache.org/jira/browse/LUCENE-8860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Motov updated LUCENE-8860: --- Attachment: fig3.png > LatLonShapeBoundingBoxQuery could make more decisions on inner nodes > > > Key: LUCENE-8860 > URL: https://issues.apache.org/jira/browse/LUCENE-8860 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Attachments: fig1.png, fig2.png, fig3.png > > Time Spent: 10m > Remaining Estimate: 0h > > Currently LatLonShapeBoundingBoxQuery with the INTERSECTS relation only > returns CELL_INSIDE_QUERY if the query contains ALL minimum bounding > rectangles of the indexed triangles. > I think we could return CELL_INSIDE_QUERY if the box contains either of the > edges of all MBRs of indexed triangles since triangles are guaranteed to > touch all edges of their MBR by definition. In some cases this would help > save decoding triangles and running costly point-in-triangle computations. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8956) QueryRescorer sort optimization
[ https://issues.apache.org/jira/browse/LUCENE-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914588#comment-16914588 ] Paul Sanwald commented on LUCENE-8956: -- Thanks for your review [~jpountz], I've updated the patch. The one area I'm struggling to think of a good way is the assertion you mentioned: usually, asserting on length doesn't feel like a good check to me, but, for this case, I did want to make sure the logic is exercised, so the first query is a term query that will match most of the documents in the set, and the second is a phrase that should match less and thus return different scores. So, I've added a loop that asserts the topN scores are in fact ordered. Do you recommend to remove some of the randomization and assert on specific scores? Or is there another strategy I'm not thinking of? > QueryRescorer sort optimization > --- > > Key: LUCENE-8956 > URL: https://issues.apache.org/jira/browse/LUCENE-8956 > Project: Lucene - Core > Issue Type: Improvement > Components: core/query/scoring >Reporter: Paul Sanwald >Priority: Minor > Attachments: LUCENE-8956.patch > > > This patch addresses a TODO in QueryRescorer: We should not sort the full > array of the results returned from rescoring, but rather only topN, when topN > is less than total hits. > > Made this optimization with some suggestions from [~jpountz] and [~jimczi], > this is my first lucene patch submission. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8956) QueryRescorer sort optimization
[ https://issues.apache.org/jira/browse/LUCENE-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Sanwald updated LUCENE-8956: - Attachment: (was: LUCENE-8956.patch) > QueryRescorer sort optimization > --- > > Key: LUCENE-8956 > URL: https://issues.apache.org/jira/browse/LUCENE-8956 > Project: Lucene - Core > Issue Type: Improvement > Components: core/query/scoring >Reporter: Paul Sanwald >Priority: Minor > Attachments: LUCENE-8956.patch > > > This patch addresses a TODO in QueryRescorer: We should not sort the full > array of the results returned from rescoring, but rather only topN, when topN > is less than total hits. > > Made this optimization with some suggestions from [~jpountz] and [~jimczi], > this is my first lucene patch submission. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8956) QueryRescorer sort optimization
[ https://issues.apache.org/jira/browse/LUCENE-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Sanwald updated LUCENE-8956: - Attachment: LUCENE-8956.patch > QueryRescorer sort optimization > --- > > Key: LUCENE-8956 > URL: https://issues.apache.org/jira/browse/LUCENE-8956 > Project: Lucene - Core > Issue Type: Improvement > Components: core/query/scoring >Reporter: Paul Sanwald >Priority: Minor > Attachments: LUCENE-8956.patch > > > This patch addresses a TODO in QueryRescorer: We should not sort the full > array of the results returned from rescoring, but rather only topN, when topN > is less than total hits. > > Made this optimization with some suggestions from [~jpountz] and [~jimczi], > this is my first lucene patch submission. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914583#comment-16914583 ] Jan Høydahl commented on LUCENE-8951: - Requested list creation. I randomly added elyograg, msokolov and dsmiley as moderators in addition to myself. But there will be no moderation as this is an announce only list. However I believe you will have karma to manage the list. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] imotov opened a new pull request #844: LUCENE-8860: Make more decision on inner nodes in ShapeBoundingBoxQuery
imotov opened a new pull request #844: LUCENE-8860: Make more decision on inner nodes in ShapeBoundingBoxQuery URL: https://github.com/apache/lucene-solr/pull/844 Relaxes the bounding box intersection check in bounding box queries on the inner node level. For the intersection it is not required that the query bounding box contains the entire cell bounding box. It is sufficient for the bounding box to include at least one edge of min bounding box and max bounding. The edge has to be on the same side of both boxes. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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] [Updated] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated LUCENE-8951: Description: Issue to plan and execute decision from dev mailing list [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] # Create mailing lists as an announce only list (/) # Subscribe all emails that will be allowed to post # Update websites with info about the new lists # Announce to dev@ list that the change will happen # Modify Jira and Github bots to post to issues@ list instead of dev@ # Modify Jenkins (including Policeman and other) to post to builds@ # Announce to dev@ list that the change is effective was: Issue to plan and execute decision from dev mailing list [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] # Create mailing lists as an announce only list # Subscribe all emails that will be allowed to post # Update websites with info about the new lists # Announce to dev@ list that the change will happen # Modify Jira and Github bots to post to issues@ list instead of dev@ # Modify Jenkins (including Policeman and other) to post to builds@ # Announce to dev@ list that the change is effective > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13716) Check that (negative) sharded join behavior is consistent
Mikhail Khludnev created SOLR-13716: --- Summary: Check that (negative) sharded join behavior is consistent Key: SOLR-13716 URL: https://issues.apache.org/jira/browse/SOLR-13716 Project: Solr Issue Type: Test Security Level: Public (Default Security Level. Issues are Public) Components: query parsers Reporter: Mikhail Khludnev Error might be inconsistent, make sure it's always the same. see the thread linked. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8956) QueryRescorer sort optimization
[ https://issues.apache.org/jira/browse/LUCENE-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Sanwald updated LUCENE-8956: - Attachment: (was: LUCENE-8956.patch) > QueryRescorer sort optimization > --- > > Key: LUCENE-8956 > URL: https://issues.apache.org/jira/browse/LUCENE-8956 > Project: Lucene - Core > Issue Type: Improvement > Components: core/query/scoring >Reporter: Paul Sanwald >Priority: Minor > Attachments: LUCENE-8956.patch > > > This patch addresses a TODO in QueryRescorer: We should not sort the full > array of the results returned from rescoring, but rather only topN, when topN > is less than total hits. > > Made this optimization with some suggestions from [~jpountz] and [~jimczi], > this is my first lucene patch submission. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8956) QueryRescorer sort optimization
[ https://issues.apache.org/jira/browse/LUCENE-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Sanwald updated LUCENE-8956: - Attachment: LUCENE-8956.patch > QueryRescorer sort optimization > --- > > Key: LUCENE-8956 > URL: https://issues.apache.org/jira/browse/LUCENE-8956 > Project: Lucene - Core > Issue Type: Improvement > Components: core/query/scoring >Reporter: Paul Sanwald >Priority: Minor > Attachments: LUCENE-8956.patch > > > This patch addresses a TODO in QueryRescorer: We should not sort the full > array of the results returned from rescoring, but rather only topN, when topN > is less than total hits. > > Made this optimization with some suggestions from [~jpountz] and [~jimczi], > this is my first lucene patch submission. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13715) Explore join and multithread facets
Mikhail Khludnev created SOLR-13715: --- Summary: Explore join and multithread facets Key: SOLR-13715 URL: https://issues.apache.org/jira/browse/SOLR-13715 Project: Solr Issue Type: Test Security Level: Public (Default Security Level. Issues are Public) Components: query parsers Reporter: Mikhail Khludnev User reported an issue when both of subj meet together. See the link to the mail thread. Include json facet and scored join as well. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914577#comment-16914577
]
Lucene/Solr QA commented on SOLR-6203:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
15s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 2m 5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 2m 5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 2m 5s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 34m
38s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 42m 17s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-6203 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12978434/SOLR-6203.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 07f1364800 |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/537/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/537/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
>Priority: Major
> Attachments: README, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at
[JENKINS] Lucene-Solr-Tests-8.x - Build # 460 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/460/ 1 tests failed. FAILED: org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage Error Message: Error from server at http://127.0.0.1:38863/solr: Underlying core creation failed while creating collection: globalCacheColl Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:38863/solr: Underlying core creation failed while creating collection: globalCacheColl at __randomizedtesting.SeedInfo.seed([A074C1A9D3F81AFD:6C519537D8AFAC1E]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage(TestContainerReqHandler.java:687) 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
[JENKINS] Lucene-Solr-repro - Build # 3556 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3556/ [...truncated 33 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/459/consoleText [repro] Revision: f3c7bbf79e35dc7429e8ec439dacd09b9c969a54 [repro] Repro line: ant test -Dtestcase=TestContainerReqHandler -Dtests.method=testCacheLoadFromPackage -Dtests.seed=1F1005E57793550C -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ca-ES -Dtests.timezone=America/Bahia -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: 07f136480006b3db4baaf5a96215954450d4b83e [repro] git fetch [repro] git checkout f3c7bbf79e35dc7429e8ec439dacd09b9c969a54 [...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] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.seed=1F1005E57793550C -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ca-ES -Dtests.timezone=America/Bahia -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [...truncated 23148 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] Re-testing 100% failures at the tip of branch_8x [repro] git fetch [repro] git checkout branch_8x [...truncated 4 lines...] [repro] git merge --ff-only [...truncated 10 lines...] [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.seed=1F1005E57793550C -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ca-ES -Dtests.timezone=America/Bahia -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [...truncated 23331 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] Re-testing 100% failures at the tip of branch_8x without a seed [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ca-ES -Dtests.timezone=America/Bahia -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [...truncated 23309 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x without a seed: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] git checkout 07f136480006b3db4baaf5a96215954450d4b83e [...truncated 8 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
[jira] [Resolved] (SOLR-13702) Some components register twice their metric names
[
https://issues.apache.org/jira/browse/SOLR-13702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-13702.
Resolution: Fixed
> Some components register twice their metric names
> -
>
> Key: SOLR-13702
> URL: https://issues.apache.org/jira/browse/SOLR-13702
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 8.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Spin-off from SOLR-13700.
> Both {{AuditLoggerPlugin.initializeMetrics}} and
> {{AuthenticationPlugin.initializeMetrics}} needlessly add metrics names to
> {{metricNames}} - this is already done as a part of each respective metric
> registration by using {{SolrInfoBean.this.registerName(name)}}.
> There may be other components that do this, too.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13702) Some components register twice their metric names
[
https://issues.apache.org/jira/browse/SOLR-13702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914526#comment-16914526
]
ASF subversion and git services commented on SOLR-13702:
Commit 4c9691ef191441add8c1f91e54d9d52775f395a7 in lucene-solr's branch
refs/heads/branch_8x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4c9691e ]
SOLR-13702: Some components register twice their metric names (#834)
(cherry picked from commit 0aa3654802fa8fd7da27c80619248b92b3ac6af5)
> Some components register twice their metric names
> -
>
> Key: SOLR-13702
> URL: https://issues.apache.org/jira/browse/SOLR-13702
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 8.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Spin-off from SOLR-13700.
> Both {{AuditLoggerPlugin.initializeMetrics}} and
> {{AuthenticationPlugin.initializeMetrics}} needlessly add metrics names to
> {{metricNames}} - this is already done as a part of each respective metric
> registration by using {{SolrInfoBean.this.registerName(name)}}.
> There may be other components that do this, too.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13702) Some components register twice their metric names
[
https://issues.apache.org/jira/browse/SOLR-13702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914527#comment-16914527
]
ASF subversion and git services commented on SOLR-13702:
Commit 035d823acf752d5794cfd07e133a918f0fb6b8c6 in lucene-solr's branch
refs/heads/branch_8x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=035d823 ]
SOLR-13702: Fix precommit
> Some components register twice their metric names
> -
>
> Key: SOLR-13702
> URL: https://issues.apache.org/jira/browse/SOLR-13702
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 8.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Spin-off from SOLR-13700.
> Both {{AuditLoggerPlugin.initializeMetrics}} and
> {{AuthenticationPlugin.initializeMetrics}} needlessly add metrics names to
> {{metricNames}} - this is already done as a part of each respective metric
> registration by using {{SolrInfoBean.this.registerName(name)}}.
> There may be other components that do this, too.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-12.0.1) - Build # 8104 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8104/ Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC 21 tests failed. FAILED: org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testFilePersistence Error Message: Software caused connection abort: recv failed Stack Trace: javax.net.ssl.SSLException: Software caused connection abort: recv failed at __randomizedtesting.SeedInfo.seed([8DEEF5F94E5FF5D1:AF4F9184EB339394]:0) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:320) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:258) at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1342) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:844) at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137) at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153) at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163) at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) at org.apache.solr.util.RestTestHarness.getResponse(RestTestHarness.java:215) at org.apache.solr.util.RestTestHarness.query(RestTestHarness.java:107) at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:226) at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192) at org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testFilePersistence(TestModelManagerPersistence.java:168) 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
[jira] [Updated] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-6203:
--
Status: Patch Available (was: Open)
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
>Priority: Major
> Attachments: README, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914493#comment-16914493
]
Christine Poerschke commented on SOLR-6203:
---
Hmm, so first I tried to resume work from the
https://github.com/jitka18/lucene-solr/tree/jira/solr-6203 working branch but
struggled with that because since then (May 2017) many things changed,
understandably so, and refactoring changes (e.g. SOLR-10990 and SOLR-13585 and
SOLR-13603) can be helpful for code readability etc. but can be tough to
conflict resolve on git merge etc.
Anyway, so then I've used
https://github.com/apache/lucene-solr/compare/master...jitka18:jira/solr-6203
as a reference and the patch just attached contains, I think, most (but not
all) of the changes e.g. the SolrIndexSearcher change is missing and also the
test changes are not yet transplanted.
With hindsight, perhaps the tests should have been revived first actually *to
determine if and how this is still an issue with the 8.x Solr series* ... ?
PS: Why the switch back from git branch to patch file? Just small personal
preference in part plus we now have a Lucene/Solr QA bot setup which will
automatically provide patch feedback but the bot does not (yet) do the same for
pull requests.
PS PS: As always, any and all input and contributions appreciated here and if
git branches and pull requests instead of patch file attachments are more your
thing then absolutely please do feel free to choose that option.
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
>Priority: Major
> Attachments: README, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-6203:
--
Attachment: SOLR-6203.patch
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
>Priority: Major
> Attachments: README, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13699) maxChars no longer working as designed on CopyField
[ https://issues.apache.org/jira/browse/SOLR-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914486#comment-16914486 ] Chris Troullis commented on SOLR-13699: --- [~noble.paul] Sounds good. I thought it would be cleaner to only have the 1 instanceOf check, the copyfield change seemed low risk since the only place that method was called was from DocumentBuilder. I fully understand the desire to keep the changes as low impact as possible though. Is there anything else I should do to move these changes forward? Not sure what the process is. Should I enable patch review on the ticket? Also, I agree that it would be good to have the tests running in all 3 formats, the existing CopyField tests would have caught this regression if the test docs had been indexed using javabin. Should we create a ticket to track that work, if one doesn't already exist? > maxChars no longer working as designed on CopyField > --- > > Key: SOLR-13699 > URL: https://issues.apache.org/jira/browse/SOLR-13699 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, > 8.1.2 >Reporter: Chris Troullis >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13699.patch, SOLR-13699.patch > > > We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars > property on a copy field is no longer functioning as designed, while indexing > via SolrJ. Per the most recent documentation it looks like there have been no > intentional changes as to the functionality of this property, so I assume > this is a bug. > > In debugging the issue, it looks like the bug was caused by SOLR-12992. In > DocumentBuilder where the maxChar limit is applied, it first checks if the > value is instanceof String. As of SOLR-12992, string values are now coming in > as ByteArrayUtf8CharSequence (unless they are above a certain size as defined > by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String > check, and the maxChar truncation is not being applied. I am currently not > sure if this issue is limited to indexing via SolrJ or if it applies to > documents indexed via any means -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 454 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/454/
All tests passed
Build Log:
[...truncated 63925 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1457058492
[ecj-lint] Compiling 1289 source files to /tmp/ecj1457058492
[ecj-lint] Processing annotations
[ecj-lint] Annotations processed
[ecj-lint] Processing annotations
[ecj-lint] No elements to process
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
(at line 219)
[ecj-lint] return (NamedList) new
JavaBinCodec(resolver).unmarshal(in);
[ecj-lint]^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
(at line 232)
[ecj-lint] ReplicationHandler replicationHandler = (ReplicationHandler)
handler;
[ecj-lint]^^
[ecj-lint] Resource leak: 'replicationHandler' is never closed
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
(at line 628)
[ecj-lint] PeerSyncWithLeader peerSyncWithLeader = new
PeerSyncWithLeader(core,
[ecj-lint]^^
[ecj-lint] Resource leak: 'peerSyncWithLeader' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java
(at line 186)
[ecj-lint] PeerSync peerSync = new PeerSync(core, syncWith,
core.getUpdateHandler().getUpdateLog().getNumRecordsToKeep(), true,
peerSyncOnlyWithActive, false);
[ecj-lint]
[ecj-lint] Resource leak: 'peerSync' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 788)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] 6. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 794)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/core/CoreContainer.java
(at line 725)
[ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean();
[ecj-lint]^^
[ecj-lint] Resource leak: 'fieldCacheBean' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 8. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/handler/CdcrRequestHandler.java
(at line 741)
[ecj-lint] ReplicationHandler replicationHandler = (ReplicationHandler)
handler;
[ecj-lint]^^
[ecj-lint] Resource leak: 'replicationHandler' is never closed
[ecj-lint] --
[ecj-lint] 9. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/handler/CdcrRequestHandler.java
(at line 760)
[ecj-lint] ReplicationHandler replicationHandler = (ReplicationHandler)
handler;
[ecj-lint]^^
[ecj-lint] Resource leak: 'replicationHandler' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 10. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/core/src/java/org/apache/solr/handler/SolrConfigHandler.java
(at line 819)
[ecj-lint] new RuntimeLib(req.getCore().getCoreContainer()).init(new
PluginInfo(info.tag,
[GitHub] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-524385885 > The reason for that is since `AtomicInteger.get()` is not guaranteed to be thread safe, so that was a hack way to read the value safely. If you notice, we do increment the counter when a hit is collected. However, the specific location you are mentioning is just for reading without a lock -- do an `incrementAndGet`, then decrement the phantom increment that we just did Hmm, I am thinking if we should just use `getAcquire` instead of this ugly dance, since that would ensure that loads and stores are not reordered and thus serialized? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-524382441 > I don't see what the modification is. The early termination logic is the same, the only diff is that the counter to check totalHitsThreshold is global in one case and local in the current impl. What I propose is to decorrelate the local totalHits that is needed to count the number of documents visited by the collector and the counter to check the `totalHitsThreshold`. A simple `BooleanSupplier` that checks if updateMinScore can be called won't change any existing functionality and you can hide this implementation detail by keeping the TopFieldCollector#create as they are today. Did I miss something ? No, you did not. As I mentioned earlier (sorry if I was not being clear), the reason I did not do it the way you proposed was an excessive paranoid to not touch a widely used family of collectors when adding this functionality, until I demonstrate it to the community and get feedback. Based on our discussion above, I implicitly understand that you are fine with the approached proposed in the PR and believe it is safe enough to be added to the core `TopFieldCollector`? If that is the case, I will raise another iteration, integrating the same into the parent class. > Yes, why do you need to decrement the counter, any visited document should increment ? The reason for that is since `AtomicInteger.get()` is not guaranteed to be thread safe, so that was a hack way to read the value safely. If you notice, we do increment the counter when a hit is collected. However, the specific location you are mentioning is just for reading without a lock -- do an `incrementAndGet`, then decrement the phantom increment that we just did This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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-13702) Some components register twice their metric names
[
https://issues.apache.org/jira/browse/SOLR-13702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914449#comment-16914449
]
ASF subversion and git services commented on SOLR-13702:
Commit 07f136480006b3db4baaf5a96215954450d4b83e in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=07f1364 ]
SOLR-13702: Fix precommit
> Some components register twice their metric names
> -
>
> Key: SOLR-13702
> URL: https://issues.apache.org/jira/browse/SOLR-13702
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 8.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Spin-off from SOLR-13700.
> Both {{AuditLoggerPlugin.initializeMetrics}} and
> {{AuthenticationPlugin.initializeMetrics}} needlessly add metrics names to
> {{metricNames}} - this is already done as a part of each respective metric
> registration by using {{SolrInfoBean.this.registerName(name)}}.
> There may be other components that do this, too.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.3) - Build # 24594 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24594/
Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 64021 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1841814946
[ecj-lint] Compiling 1289 source files to /tmp/ecj1841814946
[ecj-lint] Processing annotations
[ecj-lint] Annotations processed
[ecj-lint] Processing annotations
[ecj-lint] No elements to process
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
(at line 219)
[ecj-lint] return (NamedList) new
JavaBinCodec(resolver).unmarshal(in);
[ecj-lint]^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
(at line 232)
[ecj-lint] ReplicationHandler replicationHandler = (ReplicationHandler)
handler;
[ecj-lint]^^
[ecj-lint] Resource leak: 'replicationHandler' is never closed
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
(at line 628)
[ecj-lint] PeerSyncWithLeader peerSyncWithLeader = new
PeerSyncWithLeader(core,
[ecj-lint]^^
[ecj-lint] Resource leak: 'peerSyncWithLeader' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java
(at line 186)
[ecj-lint] PeerSync peerSync = new PeerSync(core, syncWith,
core.getUpdateHandler().getUpdateLog().getNumRecordsToKeep(), true,
peerSyncOnlyWithActive, false);
[ecj-lint]
[ecj-lint] Resource leak: 'peerSync' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 788)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] 6. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 794)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/CoreContainer.java
(at line 725)
[ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean();
[ecj-lint]^^
[ecj-lint] Resource leak: 'fieldCacheBean' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 8. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 19)
[ecj-lint] import javax.naming.Context;
[ecj-lint]
[ecj-lint] The type javax.naming.Context is not accessible
[ecj-lint] --
[ecj-lint] 9. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 20)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]^^^
[ecj-lint] The type javax.naming.InitialContext is not accessible
[ecj-lint] --
[ecj-lint] 10. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 21)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 11. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 22)
[ecj-lint] import javax.naming.NoInitialContextException;
[jira] [Commented] (SOLR-13712) JMX MBeans are not exposed because of race condition between creating platform mbean server and registering mbeans
[
https://issues.apache.org/jira/browse/SOLR-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914380#comment-16914380
]
Jeremy Branham commented on SOLR-13712:
---
Thanks for tracking this down -
It sounds like a workaround may be to configure log4j2 to register it's mbeans
earlier.
I'm not sure if this can be done through configuration, but I'll do some tests
and post my results.
> JMX MBeans are not exposed because of race condition between creating
> platform mbean server and registering mbeans
> --
>
> Key: SOLR-13712
> URL: https://issues.apache.org/jira/browse/SOLR-13712
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JMX
>Affects Versions: 6.6, 6.6.2, 6.6.5, 7.7.2, 8.2, 8.1.1
>Reporter: Shalin Shekhar Mangar
>Priority: Major
>
> This is quite easy to reproduce.
> {code}
> wget https://archive.apache.org/dist/lucene/solr/6.6.0/solr-6.6.0.tgz
> tar xvf solr-6.6.0.tgz
> cd solr-6.6.0
> {code}
> Enable jmx reporting by editing the server/solr/solr.xml and adding the
> following under the "" tag:
> {code}
>
> class="org.apache.solr.metrics.reporters.SolrJmxReporter" />
>
> {code}
> Start solr with:
> {code}
> ./bin/solr start -e cloud -noprompt
> {code}
> Open jconsole and inspect mbeans for solr nodes running on port 8983 and
> 7574. You'll find that all mbeans (node, jvm, jetty, solr) are present for
> the solr on port 8983 but completely absent for the solr node running on port
> 7574.
> Same behavior is on 6.6.2 and 6.6.6. However, Solr 7.x and 8.x seem to be
> fine.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true
[
https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914342#comment-16914342
]
Marcus Eagan edited comment on SOLR-13649 at 8/23/19 3:22 PM:
--
bq. What I was hoping for wrt smooth upgrade was a way to make the default
depend on config version. We could have used luceneMatchVersion if this was a
per-core config but it is a cluster-wide config so we cannot. I'm not aware of
any cluster-wide config version parameter we could use instead. Perhaps a new
clusterProperty solrMatchVersion could be of benefit for this and other cluster
wide breaking changes. Then if solrMatchVersion is not set you'll assume
Version.LATEST, but if it is set to e.g. 8.2 then blockUnknown could default to
true as before. Or perhaps better is to introduce a "version" property in
security.json that would work much like our schema version property, and we
could start on version=2 from Solr9. This is how e.g. docker versions their
docker-compose configs. This could be useful in the future if we need to change
the very format of security.json to e.g. support multiple auth schemes and
backends in the same cluster.
I think that would need to be addressed in another issue or PR that is linked
to this one. I can write it, but would prefer the scope not creep on this
change.
Great suggestion, though, although I feel like containers seem to address a lot
of this version checking
was (Author: marcussorealheis):
bq. What I was hoping for wrt smooth upgrade was a way to make the default
depend on config version. We could have used luceneMatchVersion if this was a
per-core config but it is a cluster-wide config so we cannot. I'm not aware of
any cluster-wide config version parameter we could use instead. Perhaps a new
clusterProperty solrMatchVersion could be of benefit for this and other cluster
wide breaking changes. Then if solrMatchVersion is not set you'll assume
Version.LATEST, but if it is set to e.g. 8.2 then blockUnknown could default to
true as before. Or perhaps better is to introduce a "version" property in
security.json that would work much like our schema version property, and we
could start on version=2 from Solr9. This is how e.g. docker versions their
docker-compose configs. This could be useful in the future if we need to change
the very format of security.json to e.g. support multiple auth schemes and
backends in the same cluster.
I think that would need to be addressed in another issue or PR that is linked
to this one. I can write it, but would prefer the scope not creep on this
change.
> BasicAuth's 'blockUnknown' param should default to true
> ---
>
> Key: SOLR-13649
> URL: https://issues.apache.org/jira/browse/SOLR-13649
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI, Authentication, security
>Affects Versions: 7.7.2, 8.1.1
> Environment: All
>Reporter: Marcus Eagan
>Priority: Major
> Labels: Authentication
> Fix For: master (9.0)
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> If someone seeks to enable basic authentication but they do not specify the
> {{blockUnknown}} parameter, the default value is {{false}}. That default
> behavior is a bit counterintuitive because if someone wishes to enable basic
> authentication, you would expect that they would want all unknown users to
> need to authenticate by default. I can imagine cases where you would not, but
> those cases would be less frequent.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true
[
https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914342#comment-16914342
]
Marcus Eagan commented on SOLR-13649:
-
bq. What I was hoping for wrt smooth upgrade was a way to make the default
depend on config version. We could have used luceneMatchVersion if this was a
per-core config but it is a cluster-wide config so we cannot. I'm not aware of
any cluster-wide config version parameter we could use instead. Perhaps a new
clusterProperty solrMatchVersion could be of benefit for this and other cluster
wide breaking changes. Then if solrMatchVersion is not set you'll assume
Version.LATEST, but if it is set to e.g. 8.2 then blockUnknown could default to
true as before. Or perhaps better is to introduce a "version" property in
security.json that would work much like our schema version property, and we
could start on version=2 from Solr9. This is how e.g. docker versions their
docker-compose configs. This could be useful in the future if we need to change
the very format of security.json to e.g. support multiple auth schemes and
backends in the same cluster.
I think that would need to be addressed in another issue or PR that is linked
to this one. I can write it, but would prefer the scope not creep on this
change.
> BasicAuth's 'blockUnknown' param should default to true
> ---
>
> Key: SOLR-13649
> URL: https://issues.apache.org/jira/browse/SOLR-13649
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI, Authentication, security
>Affects Versions: 7.7.2, 8.1.1
> Environment: All
>Reporter: Marcus Eagan
>Priority: Major
> Labels: Authentication
> Fix For: master (9.0)
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> If someone seeks to enable basic authentication but they do not specify the
> {{blockUnknown}} parameter, the default value is {{false}}. That default
> behavior is a bit counterintuitive because if someone wishes to enable basic
> authentication, you would expect that they would want all unknown users to
> need to authenticate by default. I can imagine cases where you would not, but
> those cases would be less frequent.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-8.x - Build # 459 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/459/ 1 tests failed. FAILED: org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage Error Message: Error from server at http://127.0.0.1:35326/solr: Underlying core creation failed while creating collection: globalCacheColl Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:35326/solr: Underlying core creation failed while creating collection: globalCacheColl at __randomizedtesting.SeedInfo.seed([1F1005E57793550C:D335517B7CC4E3EF]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage(TestContainerReqHandler.java:687) 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
[GitHub] [lucene-solr] jimczi commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
jimczi commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-524350989 > Yes, that is correct, but adding it to TopFieldCollector would mean that it is a part of SimpleFieldCollector and PagingFieldCollector code paths as well, and I was conservatively not modifying existing functionality (not atleast until we discussed it in the community). I don't see what the modification is. The early termination logic is the same, the only diff is that the counter to check totalHitsThreshold is global in one case and local in the current impl. What I propose is to decorrelate the local totalHits that is needed to count the number of documents visited by the collector and the counter to check the `totalHitsThreshold`. A simple `BooleanSupplier` that checks if updateMinScore can be called won't change any existing functionality and you can hide this implementation detail by keeping the TopFieldCollector#create as they are today. Did I miss something ? > Are you referring to the case when the global hits counter is decremented right when we cross the threshold? Yes, why do you need to decrement the counter, any visited document should increment ? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-524335774 > Sorry I don't follow. The logic for early termination should be the same in `TopFieldCollector` than the one you put in `SharedHitCountFieldCollector`. Yes, that is correct, but adding it to `TopFieldCollector` would mean that it is a part of `SimpleFieldCollector` and `PagingFieldCollector` code paths as well, and I was conservatively not modifying existing functionality (not atleast until we discussed it in the community). > I also don't understand why you decrement the global total hits counter ? Shouldn't it be equivalent to a shared totalHits in the current impl ? Are you referring to the case when the global hits counter is decremented right when we cross the threshold? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914296#comment-16914296
]
ASF subversion and git services commented on SOLR-13105:
Commit d217333cca92cfa6d9a922d3d8d7ac57e416f070 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d217333 ]
SOLR-13105: Update search/sample/agg viz2
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] jimczi commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
jimczi commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-524333717 Sorry I don't follow. The logic for early termination should be the same in `TopFieldCollector` than the one you put in `SharedHitCountFieldCollector`. I also don't understand why you decrement the global total hits counter ? Shouldn't it be equivalent to a shared totalHits in the current impl ? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914216#comment-16914216
]
Tomoko Uchida edited comment on SOLR-13452 at 8/23/19 2:18 PM:
---
When I looked into inter-module dependency problems on IDEA, I noticed that it
seems difficult to manage to keep our current IDEA module structure with Gradle
IDEA plugin.
I discarded (refactored) current structure defined in {{.idea/modules.xml}}
and instead, made use of the default structure generated by the Gradle plugin.
(Gradle IDEA plugin works well for me and I think it's much better than
maintaining ".iml" files for all Lucene/Solr modules on our own.)
By this change IDEA users will see:
1. module names have been changed (e.g., "backward-codecs" is now
"lucene-backward-codecs", "extraction" is "solr-contrib-extraction", and so on)
2. main / test modules had been merged into one module (e.g., "lucene-core"
and "lucene-core-tests" are now packed into "lucene-core", "solr-core" and
"solr-core-tests" are packed into "solr-core", and so on).
And you might notice 3. IDEA complains some circular dependencies those
haven't been reported so far (they had been cleverly suppressed by customized
module structure), but daily development shouldn't be affected by this.
I think unused IDEA configuration files can be removed when we remove all other
Ant related files.
For me IDEA setup is 90% ready now... still not perfect, some
fixes/improvements are needed.
[~markrmil...@gmail.com]: when I looked through build files, I noticed a typo.
[https://github.com/apache/lucene-solr/blob/jira/SOLR-13452_gradle_5/lucene/analysis/stempel/build.gradle#L22]
I think {{lucene-analyzers-stemple}} should be {{lucene-analyzers-stempel}} :)
was (Author: tomoko uchida):
When I looked into inter-module dependency problems on IDEA, I noticed that it
seems difficult to manage to keep our current IDEA module structure with Gradle
IDEA plugin.
I discarded (refactored) current structure defined in {{.idea/modules.xml}}
and instead, made use of the default structure generated by the Gradle plugin.
(Gradle IDEA plugin works well for me and I think it's much better than
maintaining ".iml" files for all Lucene/Solr modules on our own.)
By this change IDEA users will see:
1. module names have been changed (e.g., "backward-codecs" is now
"lucene-backward-codecs", "extraction" is "solr-contrib-extraction", and so on)
2. main / test modules have been merged into one module (e.g., "lucene-core"
and "lucene-core-tests" are now packed into "lucene-core", "solr-core" and
"solr-core-tests" are packed into "solr-core", and so on).
And you might notice 3. IDEA complains some circular dependencies those
haven't been reported so far (they have been cleverly suppressed by customized
module structure), but daily development shouldn't be affected by this.
I think unused IDEA configuration files can be removed when we remove all other
Ant related files.
For me IDEA setup is 90% ready now... still not perfect, some
fixes/improvements are needed.
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
>
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] magibney opened a new pull request #843: SOLR-13714: Correct refguide regarding shardHandlerFactory solrconfig…
magibney opened a new pull request #843: SOLR-13714: Correct refguide regarding shardHandlerFactory solrconfig… URL: https://github.com/apache/lucene-solr/pull/843 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-524332090 @jimczi I did consider doing that, but went down this route to explicitly decouple the early termination code path from the standard implementations of TopFieldCollector. I was unsure if we should directly enable existing (and future) field collectors to work with early termination. WDYT? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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] (SOLR-13714) Incorrect shardHandlerFactory config element documented in refguide for "distributed requests"
Michael Gibney created SOLR-13714:
-
Summary: Incorrect shardHandlerFactory config element documented
in refguide for "distributed requests"
Key: SOLR-13714
URL: https://issues.apache.org/jira/browse/SOLR-13714
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: documentation
Affects Versions: 8.1.1, 7.7.2
Reporter: Michael Gibney
Reference guide documentation is inconsistent with respect to configuration of
{{shardHandlerFactory}} in {{solrconfig.xml}}.
The correct config element name is "{{shardHandlerFactory}}", as reflected in
code [in
SolrXmlConfig.java|https://github.com/apache/lucene-solr/blob/301ea0e/solr/core/src/java/org/apache/solr/core/SolrXmlConfig.java#L460]
and [in
SearchHandler.java|https://github.com/apache/lucene-solr/blob/43fc05c/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L97].
The element name is documented correctly in the [refGuide page for "Format of
solr.xml"|https://lucene.apache.org/solr/guide/8_1/format-of-solr-xml.html#the-shardhandlerfactory-element],
but it is documented incorrectly (as "{{shardHandler}}", not
"{{shardHandlerFactory}}" in the [refGuide page for "Distributed
Requests"|https://lucene.apache.org/solr/guide/8_1/distributed-requests.html#configuring-the-shardhandlerfactory].
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 283 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/283/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 5 tests failed. FAILED: org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage Error Message: Error from server at http://127.0.0.1:51467/solr: Underlying core creation failed while creating collection: globalCacheColl Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:51467/solr: Underlying core creation failed while creating collection: globalCacheColl at __randomizedtesting.SeedInfo.seed([37C8E5ACEF30D23D:FBEDB132E46764DE]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage(TestContainerReqHandler.java:687) 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
[jira] [Commented] (SOLR-13702) Some components register twice their metric names
[
https://issues.apache.org/jira/browse/SOLR-13702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914262#comment-16914262
]
ASF subversion and git services commented on SOLR-13702:
Commit 0aa3654802fa8fd7da27c80619248b92b3ac6af5 in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0aa3654 ]
SOLR-13702: Some components register twice their metric names (#834)
> Some components register twice their metric names
> -
>
> Key: SOLR-13702
> URL: https://issues.apache.org/jira/browse/SOLR-13702
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 8.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Spin-off from SOLR-13700.
> Both {{AuditLoggerPlugin.initializeMetrics}} and
> {{AuthenticationPlugin.initializeMetrics}} needlessly add metrics names to
> {{metricNames}} - this is already done as a part of each respective metric
> registration by using {{SolrInfoBean.this.registerName(name)}}.
> There may be other components that do this, too.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy merged pull request #834: SOLR-13702: Some components register twice their metric names
janhoy merged pull request #834: SOLR-13702: Some components register twice their metric names URL: https://github.com/apache/lucene-solr/pull/834 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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-repro - Build # 3555 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3555/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/193/consoleText [repro] Revision: e94a7b05fbd2dcbce3700b318674bd0df1465510 [repro] Repro line: ant test -Dtestcase=TestContainerReqHandler -Dtests.method=testCacheLoadFromPackage -Dtests.seed=79DD7F09DF644A39 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ga -Dtests.timezone=Atlantic/Cape_Verde -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 152756fcbd8ae3bfd5e842f94b053715cb554588 [repro] git fetch [repro] git checkout e94a7b05fbd2dcbce3700b318674bd0df1465510 [...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] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.seed=79DD7F09DF644A39 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ga -Dtests.timezone=Atlantic/Cape_Verde -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 22594 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] Re-testing 100% failures at the tip of branch_8x [repro] git fetch [repro] git checkout branch_8x [...truncated 3 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.seed=79DD7F09DF644A39 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ga -Dtests.timezone=Atlantic/Cape_Verde -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 22610 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] Re-testing 100% failures at the tip of branch_8x without a seed [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ga -Dtests.timezone=Atlantic/Cape_Verde -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 22661 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x without a seed: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] git checkout 152756fcbd8ae3bfd5e842f94b053715cb554588 [...truncated 8 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
[jira] [Created] (SOLR-13713) JWTAuthPlugin to support multiple JWKS endpoints
Jan Høydahl created SOLR-13713:
--
Summary: JWTAuthPlugin to support multiple JWKS endpoints
Key: SOLR-13713
URL: https://issues.apache.org/jira/browse/SOLR-13713
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: security
Affects Versions: 8.2
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Some [Identity Providers|https://en.wikipedia.org/wiki/Identity_provider] do
not expose all JWK keys used to sign access tokens through the main [JWKS
|https://auth0.com/docs/jwks] endpoint exposed through OIDC Discovery. For
instance Ping Federate can have multiple Token Providers, each exposing its
signing keys through separate JWKS endpoints.
To support these, the JWT plugin should optinally accept an array of URLs for
the {{jwkUrl}} configuration option. If an array is provided, then we'll fetch
all the JWKS and validate the JWT against all before we fail the request.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914216#comment-16914216
]
Tomoko Uchida edited comment on SOLR-13452 at 8/23/19 12:42 PM:
When I looked into inter-module dependency problems on IDEA, I noticed that it
seems difficult to manage to keep our current IDEA module structure with Gradle
IDEA plugin.
I discarded (refactored) current structure defined in {{.idea/modules.xml}}
and instead, made use of the default structure generated by the Gradle plugin.
(Gradle IDEA plugin works well for me and I think it's much better than
maintaining ".iml" files for all Lucene/Solr modules on our own.)
By this change IDEA users will see:
1. module names have been changed (e.g., "backward-codecs" is now
"lucene-backward-codecs", "extraction" is "solr-contrib-extraction", and so on)
2. main / test modules have been merged into one module (e.g., "lucene-core"
and "lucene-core-tests" are now packed into "lucene-core", "solr-core" and
"solr-core-tests" are packed into "solr-core", and so on).
And you might notice 3. IDEA complains some circular dependencies those
haven't been reported so far (they have been cleverly suppressed by customized
module structure), but daily development shouldn't be affected by this.
I think unused IDEA configuration files can be removed when we remove all other
Ant related files.
For me IDEA setup is 90% ready now... still not perfect, some
fixes/improvements are needed.
was (Author: tomoko uchida):
When I looked into inter-module dependency problems on IDEA, I noticed that it
seems difficult to manage to keep our current IDEA module structure with Gradle
IDEA plugin.
I discarded current structure (defined in {{.idea/modules.xml}}) and instead
made use of the default structure generated by the Gradle plugin. (Gradle IDEA
plugin works well for me and I think it's much better than maintaining ".iml"
files for all Lucene/Solr modules on our own.)
By this change IDEA users will see:
1. module names have been changed (e.g., "backward-codecs" is now
"lucene-backward-codecs", "extraction" is "solr-contrib-extraction", and so on)
2. main / test modules have been merged into one module (e.g., "lucene-core"
and "lucene-core-tests" are now packed into "lucene-core", "solr-core" and
"solr-core-tests" are packed into "solr-core", and so on).
And you might notice 3. IDEA complains some circular dependencies those
haven't been reported so far (they have been cleverly suppressed by customized
module structure), but daily development shouldn't be affected by this.
I think unused IDEA configuration files can be removed when we remove all other
Ant related files.
For me IDEA setup is 90% ready now... still not perfect, some
fixes/improvements are needed.
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
>
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914216#comment-16914216
]
Tomoko Uchida edited comment on SOLR-13452 at 8/23/19 12:40 PM:
When I looked into inter-module dependency problems on IDEA, I noticed that it
seems difficult to manage to keep our current IDEA module structure with Gradle
IDEA plugin.
I discarded current structure (defined in {{.idea/modules.xml}}) and instead
made use of the default structure generated by the Gradle plugin. (Gradle IDEA
plugin works well for me and I think it's much better than maintaining ".iml"
files for all Lucene/Solr modules on our own.)
By this change IDEA users will see:
1. module names have been changed (e.g., "backward-codecs" is now
"lucene-backward-codecs", "extraction" is "solr-contrib-extraction", and so on)
2. main / test modules have been merged into one module (e.g., "lucene-core"
and "lucene-core-tests" are now packed into "lucene-core", "solr-core" and
"solr-core-tests" are packed into "solr-core", and so on).
And you might notice 3. IDEA complains some circular dependencies those
haven't been reported so far (they have been cleverly suppressed by customized
module structure), but daily development shouldn't be affected by this.
I think unused IDEA configuration files can be removed when we remove all other
Ant related files.
For me IDEA setup is 90% ready now... still not perfect, some
fixes/improvements are needed.
was (Author: tomoko uchida):
When I looked into inter-module dependency problems on IDEA, I noticed that it
seems difficult to manage to keep our current IDEA module structure with Gradle
IDEA plugin.
I discarded current IDEA module structure (defined in {{.idea/modules.xml}})
and instead made use of the default structure generated by the Gradle plugin.
(Gradle IDEA plugin works well for me and I think it's much better than
maintaining ".iml" files for all Lucene/Solr modules.)
By this change IDEA users will see that
1. module names have been changed (e.g., "backward-codecs" is now
"lucene-backward-codecs", "extraction" is "solr-contrib-extraction", and so on)
2. separated main / test modules have been merged into one module (e.g.,
"lucene-core" and "lucene-core-tests" are now packed into "lucene-core",
"solr-core" and "solr-core-tests" are packed into "solr-core", and so on).
And you might notice 3. IDEA complains some circular dependency problems those
haven't been reported so far, but daily development shouldn't be affected by
this.
For me IDEA setup is 90% ready now... still not perfect, some
fixes/improvements are needed.
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
>
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 3553 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3553/ [...truncated 33 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/458/consoleText [repro] Revision: e94a7b05fbd2dcbce3700b318674bd0df1465510 [repro] Repro line: ant test -Dtestcase=TestContainerReqHandler -Dtests.method=testCacheLoadFromPackage -Dtests.seed=BCE001D1936E580C -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=en-GB -Dtests.timezone=Mexico/BajaSur -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 152756fcbd8ae3bfd5e842f94b053715cb554588 [repro] git fetch [repro] git checkout e94a7b05fbd2dcbce3700b318674bd0df1465510 [...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] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.seed=BCE001D1936E580C -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=en-GB -Dtests.timezone=Mexico/BajaSur -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 22732 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] Re-testing 100% failures at the tip of branch_8x [repro] git fetch [repro] git checkout branch_8x [...truncated 3 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.seed=BCE001D1936E580C -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=en-GB -Dtests.timezone=Mexico/BajaSur -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 22535 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] Re-testing 100% failures at the tip of branch_8x without a seed [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=en-GB -Dtests.timezone=Mexico/BajaSur -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 22569 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x without a seed: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] git checkout 152756fcbd8ae3bfd5e842f94b053715cb554588 [...truncated 8 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
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914216#comment-16914216
]
Tomoko Uchida commented on SOLR-13452:
--
When I looked into inter-module dependency problems on IDEA, I noticed that it
seems difficult to manage to keep our current IDEA module structure with Gradle
IDEA plugin.
I discarded current IDEA module structure (defined in {{.idea/modules.xml}})
and instead made use of the default structure generated by the Gradle plugin.
(Gradle IDEA plugin works well for me and I think it's much better than
maintaining ".iml" files for all Lucene/Solr modules.)
By this change IDEA users will see that
1. module names have been changed (e.g., "backward-codecs" is now
"lucene-backward-codecs", "extraction" is "solr-contrib-extraction", and so on)
2. separated main / test modules have been merged into one module (e.g.,
"lucene-core" and "lucene-core-tests" are now packed into "lucene-core",
"solr-core" and "solr-core-tests" are packed into "solr-core", and so on).
And you might notice 3. IDEA complains some circular dependency problems those
haven't been reported so far, but daily development shouldn't be affected by
this.
For me IDEA setup is 90% ready now... still not perfect, some
fixes/improvements are needed.
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
>
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 3552 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3552/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/189/consoleText [repro] Revision: e94a7b05fbd2dcbce3700b318674bd0df1465510 [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=RollingRestartTest -Dtests.method=test -Dtests.seed=85B5443CD38D14BC -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=nl-NL -Dtests.timezone=America/Pangnirtung -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=TestContainerReqHandler -Dtests.method=testCacheLoadFromPackage -Dtests.seed=85B5443CD38D14BC -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=Indian/Reunion -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: 152756fcbd8ae3bfd5e842f94b053715cb554588 [repro] git fetch [repro] git checkout e94a7b05fbd2dcbce3700b318674bd0df1465510 [...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] TestContainerReqHandler [repro] RollingRestartTest [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.TestContainerReqHandler|*.RollingRestartTest" -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=85B5443CD38D14BC -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=Indian/Reunion -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 22611 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.cloud.RollingRestartTest [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] Re-testing 100% failures at the tip of branch_8x [repro] git fetch [repro] git checkout branch_8x [...truncated 3 lines...] [repro] git merge --ff-only [...truncated 7 lines...] [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -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=85B5443CD38D14BC -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=Indian/Reunion -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 22539 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] Re-testing 100% failures at the tip of branch_8x without a seed [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestContainerReqHandler [repro] ant compile-test [...truncated 3579 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestContainerReqHandler" -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.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=Indian/Reunion -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 22588 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_8x without a seed: [repro] 5/5 failed: org.apache.solr.handler.TestContainerReqHandler [repro] git checkout 152756fcbd8ae3bfd5e842f94b053715cb554588 [...truncated 8 lines...] [repro] Exiting with code 256 [...truncated 5 lines...]
[JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 188 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/188/ No tests ran. Build Log: [...truncated 24871 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 2594 links (2120 relative) to 3410 anchors in 259 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.3.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:
[GitHub] [lucene-solr] KoenDG commented on issue #717: SOLR-13542: Code cleanup - Avoid using stream filter count where possible
KoenDG commented on issue #717: SOLR-13542: Code cleanup - Avoid using stream filter count where possible URL: https://github.com/apache/lucene-solr/pull/717#issuecomment-524281371 Woops, I forgot about this one. I'll have a look at it later. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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-BadApples-NightlyTests-master - Build # 76 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-master/76/ No tests ran. Build Log: [...truncated 30 lines...] ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086) 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:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914191#comment-16914191 ] ASF subversion and git services commented on SOLR-13452: Commit 82022fdad3db532e0a9acd28c0cd5d6454abd334 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Tomoko Uchida [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=82022fd ] SOLR-13452: Refactor IDEA module structure > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries
[ https://issues.apache.org/jira/browse/SOLR-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914097#comment-16914097 ] Dr Oleg Savrasov commented on SOLR-6930: Patch is reworked in order to avoid finalize() invocation > Provide "Circuit Breakers" For Expensive Solr Queries > - > > Key: SOLR-6930 > URL: https://issues.apache.org/jira/browse/SOLR-6930 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Mike Drob >Priority: Major > Attachments: SOLR-6930.patch, SOLR-6930.patch > > > Ref: > http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html > ES currently allows operators to configure "circuit breakers" to preemptively > fail queries that are estimated too large rather than allowing an OOM > Exception to happen. We might be able to do the same thing. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries
[ https://issues.apache.org/jira/browse/SOLR-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dr Oleg Savrasov updated SOLR-6930: --- Attachment: SOLR-6930.patch > Provide "Circuit Breakers" For Expensive Solr Queries > - > > Key: SOLR-6930 > URL: https://issues.apache.org/jira/browse/SOLR-6930 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Mike Drob >Priority: Major > Attachments: SOLR-6930.patch, SOLR-6930.patch > > > Ref: > http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html > ES currently allows operators to configure "circuit breakers" to preemptively > fail queries that are estimated too large rather than allowing an OOM > Exception to happen. We might be able to do the same thing. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 193 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/193/ 1 tests failed. FAILED: org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage Error Message: Error from server at http://127.0.0.1:42909/solr: Underlying core creation failed while creating collection: globalCacheColl Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:42909/solr: Underlying core creation failed while creating collection: globalCacheColl at __randomizedtesting.SeedInfo.seed([79DD7F09DF644A39:B5F82B97D433FCDA]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.handler.TestContainerReqHandler.testCacheLoadFromPackage(TestContainerReqHandler.java:687) 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
[jira] [Resolved] (LUCENE-8952) Use a sort key instead of true distance in NearestNeighbors.
[ https://issues.apache.org/jira/browse/LUCENE-8952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera resolved LUCENE-8952. -- Fix Version/s: 8.3 Assignee: Ignacio Vera Resolution: Fixed > Use a sort key instead of true distance in NearestNeighbors. > > > Key: LUCENE-8952 > URL: https://issues.apache.org/jira/browse/LUCENE-8952 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Julie Tibshirani >Assignee: Ignacio Vera >Priority: Minor > Fix For: 8.3 > > Time Spent: 50m > Remaining Estimate: 0h > > The NearestNeighbors class contains a TODO to switch to > SloppyMath.haversinSortKey when comparing candidate nearest neighbors. This > change is not high priority, but could be a nice way to get more familiar > with the kNN search implementation. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] iverase commented on issue #832: LUCENE-8952: Use a sort key instead of true distance in NearestNeighbor.
iverase commented on issue #832: LUCENE-8952: Use a sort key instead of true distance in NearestNeighbor. URL: https://github.com/apache/lucene-solr/pull/832#issuecomment-524241231 Thank you @jtibshirani! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org 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] (LUCENE-8952) Use a sort key instead of true distance in NearestNeighbors.
[ https://issues.apache.org/jira/browse/LUCENE-8952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914078#comment-16914078 ] ASF subversion and git services commented on LUCENE-8952: - Commit f3c7bbf79e35dc7429e8ec439dacd09b9c969a54 in lucene-solr's branch refs/heads/branch_8x from Julie Tibshirani [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f3c7bbf ] LUCENE-8952: Use a sort key instead of true distance in NearestNeighbor. (#832) > Use a sort key instead of true distance in NearestNeighbors. > > > Key: LUCENE-8952 > URL: https://issues.apache.org/jira/browse/LUCENE-8952 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Julie Tibshirani >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > The NearestNeighbors class contains a TODO to switch to > SloppyMath.haversinSortKey when comparing candidate nearest neighbors. This > change is not high priority, but could be a nice way to get more familiar > with the kNN search implementation. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8952) Use a sort key instead of true distance in NearestNeighbors.
[ https://issues.apache.org/jira/browse/LUCENE-8952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914077#comment-16914077 ] ASF subversion and git services commented on LUCENE-8952: - Commit 152756fcbd8ae3bfd5e842f94b053715cb554588 in lucene-solr's branch refs/heads/master from Julie Tibshirani [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=152756f ] LUCENE-8952: Use a sort key instead of true distance in NearestNeighbor. (#832) > Use a sort key instead of true distance in NearestNeighbors. > > > Key: LUCENE-8952 > URL: https://issues.apache.org/jira/browse/LUCENE-8952 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Julie Tibshirani >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > The NearestNeighbors class contains a TODO to switch to > SloppyMath.haversinSortKey when comparing candidate nearest neighbors. This > change is not high priority, but could be a nice way to get more familiar > with the kNN search implementation. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] iverase merged pull request #832: LUCENE-8952: Use a sort key instead of true distance in NearestNeighbor.
iverase merged pull request #832: LUCENE-8952: Use a sort key instead of true distance in NearestNeighbor. URL: https://github.com/apache/lucene-solr/pull/832 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
