[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage
[ https://issues.apache.org/jira/browse/SOLR-12028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623097#comment-16623097 ] ASF subversion and git services commented on SOLR-12028: Commit c5056d00c60b532c49a062c4de47129350078614 in lucene-solr's branch refs/heads/branch_7x from [~cp.erick...@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c5056d0 ] SOLR-12028: BadApple and AwaitsFix annotations usage (cherry picked from commit dd088fb83eeb48c752cc69a5dd173aa1c5224bc9) > BadApple and AwaitsFix annotations usage > > > Key: SOLR-12028 > URL: https://issues.apache.org/jira/browse/SOLR-12028 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-12016-buildsystem.patch, SOLR-12028-3-Mar.patch, > SOLR-12028-sysprops-reproduce.patch, SOLR-12028.patch, SOLR-12028.patch > > > There's a long discussion of this topic at SOLR-12016. Here's a summary: > - BadApple annotations are used for tests that intermittently fail, say < 30% > of the time. Tests that fail more often shold be moved to AwaitsFix. This is, > of course, a judgement call > - AwaitsFix annotations are used for tests that, for some reason, the problem > can't be fixed immediately. Likely reasons are third-party dependencies, > extreme difficulty tracking down, dependency on another JIRA etc. > Jenkins jobs will typically run with BadApple disabled to cut down on noise. > Periodically Jenkins jobs will be run with BadApples enabled so BadApple > tests won't be lost and reports can be generated. Tests that run with > BadApples disabled that fail require _immediate_ attention. > The default for developers is that BadApple is enabled. > If you are working on one of these tests and cannot get the test to fail > locally, it is perfectly acceptable to comment the annotation out. You should > let the dev list know that this is deliberate. > This JIRA is a placeholder for BadApple tests to point to between the times > they're identified as BadApple and they're either fixed or changed to > AwaitsFix or assigned their own JIRA. > I've assigned this to myself to track so I don't lose track of it. No one > person will fix all of these issues, this will be an ongoing technical debt > cleanup effort. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage
[ https://issues.apache.org/jira/browse/SOLR-12028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623093#comment-16623093 ] ASF subversion and git services commented on SOLR-12028: Commit dd088fb83eeb48c752cc69a5dd173aa1c5224bc9 in lucene-solr's branch refs/heads/master from [~cp.erick...@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=dd088fb ] SOLR-12028: BadApple and AwaitsFix annotations usage > BadApple and AwaitsFix annotations usage > > > Key: SOLR-12028 > URL: https://issues.apache.org/jira/browse/SOLR-12028 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-12016-buildsystem.patch, SOLR-12028-3-Mar.patch, > SOLR-12028-sysprops-reproduce.patch, SOLR-12028.patch, SOLR-12028.patch > > > There's a long discussion of this topic at SOLR-12016. Here's a summary: > - BadApple annotations are used for tests that intermittently fail, say < 30% > of the time. Tests that fail more often shold be moved to AwaitsFix. This is, > of course, a judgement call > - AwaitsFix annotations are used for tests that, for some reason, the problem > can't be fixed immediately. Likely reasons are third-party dependencies, > extreme difficulty tracking down, dependency on another JIRA etc. > Jenkins jobs will typically run with BadApple disabled to cut down on noise. > Periodically Jenkins jobs will be run with BadApples enabled so BadApple > tests won't be lost and reports can be generated. Tests that run with > BadApples disabled that fail require _immediate_ attention. > The default for developers is that BadApple is enabled. > If you are working on one of these tests and cannot get the test to fail > locally, it is perfectly acceptable to comment the annotation out. You should > let the dev list know that this is deliberate. > This JIRA is a placeholder for BadApple tests to point to between the times > they're identified as BadApple and they're either fixed or changed to > AwaitsFix or assigned their own JIRA. > I've assigned this to myself to track so I don't lose track of it. No one > person will fix all of these issues, this will be an ongoing technical debt > cleanup effort. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12783) Slow queries log print status [-1] for potentially 500 error code
[
https://issues.apache.org/jira/browse/SOLR-12783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623089#comment-16623089
]
Lucene/Solr QA commented on SOLR-12783:
---
| (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
20s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 3m 25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 3m 25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 3m 25s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 88m 59s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 99m 49s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.DeleteStatusTest |
| | solr.cloud.autoscaling.sim.TestSimTriggerIntegration |
| | solr.cloud.autoscaling.sim.TestSimLargeCluster |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12783 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12940460/SOLR-12783.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 / 1d604d1 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | 1.8.0_172 |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/182/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/182/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/182/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Slow queries log print status [-1] for potentially 500 error code
> --
>
> Key: SOLR-12783
> URL: https://issues.apache.org/jira/browse/SOLR-12783
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (8.0)
>Reporter: Amrit Sarkar
>Priority: Major
> Attachments: SOLR-12783.patch
>
>
> For {{slow}} queries on {{update}}/{{select}} handler, we receive status
> {{-1}} at number of occasions;
> {code:java}
> WARN - 2018-09-17 17:37:16.683; org.apache.solr.core.SolrCore; slow:
> [collection_shard2_replica0] webapp=/solr path=/update
> params={wt=javabin=2} status=-1 QTime=61066
> ERROR - 2018-09-17 17:37:16.683; org.apache.solr.common.SolrException;
> null:org.apache.solr.update.processor.DistributedUpdateProcessor$DistributedUpdatesAsyncException:
> Async exception during distribute
> d update: Read timed out
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:972)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1911)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.finish(UpdateRequestProcessor.java:80)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:723)
> at
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-10) - Build # 796 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/796/ Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.cloud.autoscaling.sim.TestSimGenericDistributedQueue.testDistributedQueueBlocking Error Message: Stack Trace: java.util.concurrent.TimeoutException at __randomizedtesting.SeedInfo.seed([16B3BA7C51594A35:5319C805150BF641]:0) at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204) at org.apache.solr.cloud.autoscaling.sim.TestSimDistributedQueue.testDistributedQueueBlocking(TestSimDistributedQueue.java:102) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.sim.TestSimGenericDistributedQueue Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.autoscaling.sim.TestSimGenericDistributedQueue: 1) Thread[id=8510, name=sdqtest--2176-thread-1, state=TIMED_WAITING,
[jira] [Commented] (SOLR-12080) Frequent failures of MoveReplicaHDFSTest.testFailedMove
[
https://issues.apache.org/jira/browse/SOLR-12080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623070#comment-16623070
]
ASF subversion and git services commented on SOLR-12080:
Commit 1b0b33eaf1c0de8cd70b64dd27ef91e0f8d2482a in lucene-solr's branch
refs/heads/branch_7x from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1b0b33e ]
iSOLR-12080: Improve error handling of MoveReplicaCmd. Improve the test
stability
by avoiding killing overseer.
> Frequent failures of MoveReplicaHDFSTest.testFailedMove
> ---
>
> Key: SOLR-12080
> URL: https://issues.apache.org/jira/browse/SOLR-12080
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: jenkins.log.txt.gz
>
>
> This test frequently fails. This is one of the failing seeds:
> {code}
>[junit4] 2> 129275 INFO (qtp1647120030-248) [n:127.0.0.1:55469_solr
> c:MoveReplicaHDFSTest_failed_coll_true s:shard2 r:core_node7
> x:MoveReplicaHDFSTest_failed_coll_true_shard2_replica_n4] o.a.s.c.S.Request
> [MoveReplicaHDFSTest_failed_coll_true_shard2_replica_n4] webapp=/solr
> path=/select
> params={q=*:*&_stateVer_=MoveReplicaHDFSTest_failed_coll_true:9=javabin=2}
> status=503 QTime=0
>[junit4] 2> 129278 ERROR (qtp148844424-682) [n:127.0.0.1:54855_solr
> c:MoveReplicaHDFSTest_failed_coll_true s:shard2 r:core_node8
> x:MoveReplicaHDFSTest_failed_coll_true_shard2_replica_n6]
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: no servers
> hosting shard: shard1
>[junit4] 2> at
> org.apache.solr.handler.component.HttpShardHandler.prepDistributed(HttpShardHandler.java:436)
>[junit4] 2> at
> org.apache.solr.handler.component.SearchHandler.getAndPrepShardHandler(SearchHandler.java:226)
>[junit4] 2> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:264)
>[junit4] 2> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
>[junit4] 2> at
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
>[junit4] 2> at
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>[junit4] 2> at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:517)
>[junit4] 2> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)
>[junit4] 2> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)
>[junit4] 2> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>[junit4] 2> at
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
>[junit4] 2> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>[junit4] 2> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>[junit4] 2> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
>[junit4] 2> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
>[junit4] 2> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:527)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>[junit4] 2> at
> org.eclipse.jetty.server.Server.handle(Server.java:530)
>[junit4] 2> at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)
>[junit4] 2> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)
>[junit4] 2> at
>
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-11-ea+28) - Build # 22895 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22895/ Java: 64bit/jdk-11-ea+28 -XX:-UseCompressedOops -XX:+UseG1GC 31 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest Error Message: Could not find collection : AutoscalingHistoryHandlerTest_collection Stack Trace: org.apache.solr.common.SolrException: Could not find collection : AutoscalingHistoryHandlerTest_collection at __randomizedtesting.SeedInfo.seed([823E3160365E8A1E]:0) at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118) at org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:258) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.waitForRecovery(AutoscalingHistoryHandlerTest.java:403) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.setupCluster(AutoscalingHistoryHandlerTest.java:97) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) FAILED: junit.framework.TestSuite.org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest Error Message: Could not find collection : AutoscalingHistoryHandlerTest_collection Stack Trace: org.apache.solr.common.SolrException: Could not find collection : AutoscalingHistoryHandlerTest_collection at __randomizedtesting.SeedInfo.seed([823E3160365E8A1E]:0) at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118) at org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:258) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.waitForRecovery(AutoscalingHistoryHandlerTest.java:403) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.setupCluster(AutoscalingHistoryHandlerTest.java:97) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at
[JENKINS] Lucene-Solr-repro - Build # 1508 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/1508/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/322/consoleText [repro] Revision: c5ee4bcd2bbe73ba8655b8ef3a6c45e872234ab2 [repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 [repro] Repro line: ant test -Dtestcase=CdcrBidirectionalTest -Dtests.method=testBiDir -Dtests.seed=70C0290648A73CB6 -Dtests.multiplier=2 -Dtests.locale=ko -Dtests.timezone=HST -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: 1d604d1b3ffe1560700e5e462e9e796646a30d7a [repro] git fetch [repro] git checkout c5ee4bcd2bbe73ba8655b8ef3a6c45e872234ab2 [...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] CdcrBidirectionalTest [repro] ant compile-test [...truncated 3437 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.CdcrBidirectionalTest" -Dtests.showOutput=onerror -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 -Dtests.seed=70C0290648A73CB6 -Dtests.multiplier=2 -Dtests.locale=ko -Dtests.timezone=HST -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 2115 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 1/5 failed: org.apache.solr.cloud.cdcr.CdcrBidirectionalTest [repro] git checkout 1d604d1b3ffe1560700e5e462e9e796646a30d7a [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 5 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12792) extract test data into separate files in autoscaling tests
[ https://issues.apache.org/jira/browse/SOLR-12792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623019#comment-16623019 ] ASF subversion and git services commented on SOLR-12792: Commit d08f1de09e93265e7de2d87f2d4370db109b7a86 in lucene-solr's branch refs/heads/branch_7x from [~noble.paul] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d08f1de ] SOLR-12792: extract test data into separate files in autoscaling tests > extract test data into separate files in autoscaling tests > -- > > Key: SOLR-12792 > URL: https://issues.apache.org/jira/browse/SOLR-12792 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Trivial > > The tests are becoming too large because of inline json -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12792) extract test data into separate files in autoscaling tests
[ https://issues.apache.org/jira/browse/SOLR-12792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623016#comment-16623016 ] ASF subversion and git services commented on SOLR-12792: Commit 1d604d1b3ffe1560700e5e462e9e796646a30d7a in lucene-solr's branch refs/heads/master from [~noble.paul] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1d604d1 ] SOLR-12792: extract test data into separate files in autoscaling tests > extract test data into separate files in autoscaling tests > -- > > Key: SOLR-12792 > URL: https://issues.apache.org/jira/browse/SOLR-12792 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Trivial > > The tests are becoming too large because of inline json -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 159 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/159/ 1 tests failed. FAILED: org.apache.solr.cloud.ShardRoutingTest.test Error Message: expected:<3> but was:<6> Stack Trace: java.lang.AssertionError: expected:<3> but was:<6> at __randomizedtesting.SeedInfo.seed([771074D989E3E8FB:FF444B03271F8503]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.ShardRoutingTest.doTestNumRequests(ShardRoutingTest.java:256) at org.apache.solr.cloud.ShardRoutingTest.test(ShardRoutingTest.java:110) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1008) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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
[jira] [Commented] (SOLR-12792) extract test data into separate files in autoscaling tests
[ https://issues.apache.org/jira/browse/SOLR-12792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622992#comment-16622992 ] ASF subversion and git services commented on SOLR-12792: Commit 9e359c14b6d841e363fcef22f323ae8c986009ce in lucene-solr's branch refs/heads/branch_7x from [~noble.paul] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9e359c1 ] SOLR-12792: extract test data into separate files in autoscaling tests > extract test data into separate files in autoscaling tests > -- > > Key: SOLR-12792 > URL: https://issues.apache.org/jira/browse/SOLR-12792 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Trivial > > The tests are becoming too large because of inline json -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-10) - Build # 7528 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7528/ Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.cloud.autoscaling.sim.TestSimGenericDistributedQueue.testDistributedQueue Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([D89C446806E63393]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.sim.TestSimGenericDistributedQueue Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([D89C446806E63393]:0) Build Log: [...truncated 2014 lines...] [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\temp\junit4-J1-20180920_231048_85215800916887169780635.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 5 lines...] [junit4] JVM J0: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\temp\junit4-J0-20180920_231048_8529801194710611504404.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 316 lines...] [junit4] JVM J0: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\temp\junit4-J0-20180920_231847_8134382064301340602382.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\temp\junit4-J1-20180920_231847_8157591701404588767253.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 1084 lines...] [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\common\test\temp\junit4-J1-20180920_232013_80313477644302976691311.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [junit4] JVM J0: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\common\test\temp\junit4-J0-20180920_232013_8034924801453073123237.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 257 lines...] [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\icu\test\temp\junit4-J1-20180920_232250_1233766935157315658076.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 3 lines...] [junit4] JVM J0: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\icu\test\temp\junit4-J0-20180920_232250_123151876851998442807.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 254 lines...] [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\kuromoji\test\temp\junit4-J1-20180920_232301_70711934004336869762484.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<<
[jira] [Commented] (SOLR-12792) extract test data into separate files in autoscaling tests
[ https://issues.apache.org/jira/browse/SOLR-12792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622989#comment-16622989 ] ASF subversion and git services commented on SOLR-12792: Commit 6adeb5bc44040219962f00ddbf3d956e16149b62 in lucene-solr's branch refs/heads/master from [~noble.paul] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6adeb5b ] SOLR-12792: extract test data into separate files in autoscaling tests > extract test data into separate files in autoscaling tests > -- > > Key: SOLR-12792 > URL: https://issues.apache.org/jira/browse/SOLR-12792 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Trivial > > The tests are becoming too large because of inline json -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12785) Add test for activation functions in NeuralNetworkModel
[ https://issues.apache.org/jira/browse/SOLR-12785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622973#comment-16622973 ] Kamuela Lau edited comment on SOLR-12785 at 9/21/18 2:38 AM: - A couple of comments regarding the patch: # I moved the default implementations to the Activation interface, and implemented in enums (this pattern is mentioned in "Effective Java", Item 3). I decided on the enum as activation is just a function; if another layer is created with the same activation as a previous layer, only one object will be created (i.e. if there are three layers with sigmoid activation, one object will be created, instead of three as it is now). Doing this also made it easier to test. If it is preferred that the implementations not be singletons or in an enum class, please let me know; any comments are appreciated. # I also attempted to write the test for the activation functions without changing current implementation of DefaultLayer.setActivation(), however in doing so, I felt that I had to construct a NeuralNetworkModel object (with one input, one output, weight 1 and bias 0). See test-no-activation-change.txt, which I have attached. Any comments or advice would be greatly appreciated! was (Author: kamulau): A couple of couple of comments regarding the patch: # I moved the default implementations to the Activation interface, and implemented in enums (this pattern is mentioned in "Effective Java", Item 3). I decided on the enum as activation is just a function; if another layer is created with the same activation as a previous layer, only one object will be created (i.e. if there are three layers with sigmoid activation, one object will be created, instead of three as it is now). Doing this also made it easier to test. If it is preferred that the implementations not be singletons or in an enum class, please let me know; any comments are appreciated. # I also attempted to write the test for the activation functions without changing current implementation of DefaultLayer.setActivation(), however in doing so, I felt that I had to construct a NeuralNetworkModel object (with one input, one output, weight 1 and bias 0). See test-no-activation-change.txt, which I have attached. Any comments or advice would be greatly appreciated! > Add test for activation functions in NeuralNetworkModel > --- > > Key: SOLR-12785 > URL: https://issues.apache.org/jira/browse/SOLR-12785 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - LTR >Reporter: Kamuela Lau >Priority: Minor > Attachments: SOLR-12785.patch, test-no-activation-change.txt > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12785) Add test for activation functions in NeuralNetworkModel
[ https://issues.apache.org/jira/browse/SOLR-12785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622973#comment-16622973 ] Kamuela Lau commented on SOLR-12785: A couple of couple of comments regarding the patch: # I moved the default implementations to the Activation interface, and implemented in enums (this pattern is mentioned in "Effective Java", Item 3). I decided on the enum as activation is just a function; if another layer is created with the same activation as a previous layer, only one object will be created (i.e. if there are three layers with sigmoid activation, one object will be created, instead of three as it is now). Doing this also made it easier to test. If it is preferred that the implementations not be singletons or in an enum class, please let me know; any comments are appreciated. # I also attempted to write the test for the activation functions without changing current implementation of DefaultLayer.setActivation(), however in doing so, I felt that I had to construct a NeuralNetworkModel object (with one input, one output, weight 1 and bias 0). See test-no-activation-change.txt, which I have attached. Any comments or advice would be greatly appreciated! > Add test for activation functions in NeuralNetworkModel > --- > > Key: SOLR-12785 > URL: https://issues.apache.org/jira/browse/SOLR-12785 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - LTR >Reporter: Kamuela Lau >Priority: Minor > Attachments: SOLR-12785.patch, test-no-activation-change.txt > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11694) Remove extremely outdated UIMA contrib module
[ https://issues.apache.org/jira/browse/SOLR-11694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622971#comment-16622971 ] Erick Erickson commented on SOLR-11694: --- Well, it is (was) a contrib. Which means there's no reason you couldn't pull the old code and compile it yourself and continue to use it as-was. The fact that it won't be distributed with each new version of Solr is really not that big a barrier. Once you'd pulled it all locally and gotten the build to happen, going to version X+1 should be straightforward. Solr _volunteers_ can't be expected to maintain code that nobody who uses is willing to contribute effort to maintain. > Remove extremely outdated UIMA contrib module > - > > Key: SOLR-11694 > URL: https://issues.apache.org/jira/browse/SOLR-11694 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Reporter: Cassandra Targett >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: 7.5, master (8.0) > > Attachments: SOLR-11694.patch > > > A user on the [solr-user mailing list back in > June|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3CCANsk%2BC_PvZJ38AQ2VfzKRYSQn6c8b33kGvaXxR3qNS3GQ4VUKA%40mail.gmail.com%3E] > brought up the fact that IBM has bought Alchemy and keys are no longer > available to use Solr's UIMA contrib. > Someone recently made a [similar > comment|https://lucene.apache.org/solr/guide/7_1/uima-integration.html#comment_7174] > to the Solr Ref Guide page and asking for a patch. > I know next to nothing about UIMA, but figured it's worth an issue to > determine what to do here. I think folks are saying it's no longer usable? Or > maybe only usable by people who already have keys (which will possibly expire > at some point)? > Anyone have an idea what needs to be done here? It seems we should have some > kind of answer, but if it's no longer usable perhaps we should retire the > contrib. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12785) Add test for activation functions in NeuralNetworkModel
[ https://issues.apache.org/jira/browse/SOLR-12785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamuela Lau updated SOLR-12785: --- Attachment: test-no-activation-change.txt > Add test for activation functions in NeuralNetworkModel > --- > > Key: SOLR-12785 > URL: https://issues.apache.org/jira/browse/SOLR-12785 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - LTR >Reporter: Kamuela Lau >Priority: Minor > Attachments: SOLR-12785.patch, test-no-activation-change.txt > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12792) extract test data into separate files in autoscaling tests
Noble Paul created SOLR-12792: - Summary: extract test data into separate files in autoscaling tests Key: SOLR-12792 URL: https://issues.apache.org/jira/browse/SOLR-12792 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul Assignee: Noble Paul The tests are becoming too large because of inline json -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12785) Add test for activation functions in NeuralNetworkModel
[ https://issues.apache.org/jira/browse/SOLR-12785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamuela Lau updated SOLR-12785: --- Attachment: SOLR-12785.patch > Add test for activation functions in NeuralNetworkModel > --- > > Key: SOLR-12785 > URL: https://issues.apache.org/jira/browse/SOLR-12785 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - LTR >Reporter: Kamuela Lau >Priority: Minor > Attachments: SOLR-12785.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8454) Polygon tessellator can get into an infinite loop
[
https://issues.apache.org/jira/browse/LUCENE-8454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622889#comment-16622889
]
ASF subversion and git services commented on LUCENE-8454:
-
Commit d494f6be13a585c273c6a3dabc76644f4d480c31 in lucene-solr's branch
refs/heads/jira/http2 from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d494f6b ]
LUCENE-8454: Fix incorrect vertex indexing and other computation errors in
shape tessellation that would sometimes cause an infinite loop.
> Polygon tessellator can get into an infinite loop
> -
>
> Key: LUCENE-8454
> URL: https://issues.apache.org/jira/browse/LUCENE-8454
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8454.patch
>
>
> I was trying to index some shapes using {{LatLonshape}} and for some complex
> shapes, there teselletor goes into an infinite loop. I am providing a test
> showing the problem.
>
> [~nknize], you might be interested on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8498) Deprecate/Remove LowerCaseTokenizer
[ https://issues.apache.org/jira/browse/LUCENE-8498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622892#comment-16622892 ] ASF subversion and git services commented on LUCENE-8498: - Commit c0d2975970d3de8f5056a20504dec1431d455ab1 in lucene-solr's branch refs/heads/jira/http2 from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c0d2975 ] LUCENE-8498: Remove LowerCaseTokenizer > Deprecate/Remove LowerCaseTokenizer > --- > > Key: LUCENE-8498 > URL: https://issues.apache.org/jira/browse/LUCENE-8498 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: master (8.0) > > Attachments: LUCENE-8498.patch, LUCENE-8498.patch > > > LowerCaseTokenizer combines tokenization and filtering in a way that prevents > us improving the normalization API. We should deprecate and remove it, as it > can be replaced simply with a LetterTokenizer and LowerCaseFilter. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12784) SOLR Documentation "Link Not Found"
[ https://issues.apache.org/jira/browse/SOLR-12784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622888#comment-16622888 ] ASF subversion and git services commented on SOLR-12784: Commit 264110e7b92fdca471db593390901c632cb83bcb in lucene-solr's branch refs/heads/jira/http2 from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=264110e ] SOLR-12784: Fix broken link to stemdict.txt by including it in the Guide directly > SOLR Documentation "Link Not Found" > --- > > Key: SOLR-12784 > URL: https://issues.apache.org/jira/browse/SOLR-12784 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 7.4 >Reporter: Stephen Lewis Bianamara >Assignee: Cassandra Targett >Priority: Major > Labels: Documentation > Fix For: 7.6, master (8.0) > > > This page has a broken link for at least two SOLR versions I checked (7.4 and > 6.6) > https://lucene.apache.org/solr/guide/7_4/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory > > [https://lucene.apache.org/solr/guide/6_6/language-analysis.html#LanguageAnalysis-StemmerOverrideFilterFactory] > The broken link is an example to stemdict.txt and reports > """ > The requested URL > /repos/asf/lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/stemdict.txt > was not found on this server. > """ -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8454) Polygon tessellator can get into an infinite loop
[
https://issues.apache.org/jira/browse/LUCENE-8454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622890#comment-16622890
]
ASF subversion and git services commented on LUCENE-8454:
-
Commit eb0fcec50303e193339f49d8f15049551912b917 in lucene-solr's branch
refs/heads/jira/http2 from iverase
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eb0fcec ]
LUCENE-8454: Set test TestLatLonPolygonShapeQueries#testRandomMedium to AwaitFix
> Polygon tessellator can get into an infinite loop
> -
>
> Key: LUCENE-8454
> URL: https://issues.apache.org/jira/browse/LUCENE-8454
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8454.patch
>
>
> I was trying to index some shapes using {{LatLonshape}} and for some complex
> shapes, there teselletor goes into an infinite loop. I am providing a test
> showing the problem.
>
> [~nknize], you might be interested on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12080) Frequent failures of MoveReplicaHDFSTest.testFailedMove
[
https://issues.apache.org/jira/browse/SOLR-12080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622891#comment-16622891
]
ASF subversion and git services commented on SOLR-12080:
Commit 52bdcf6bb0b7645da55124298f6d268fe8f4a77a in lucene-solr's branch
refs/heads/jira/http2 from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=52bdcf6 ]
iSOLR-12080: Improve error handling of MoveReplicaCmd. Improve the test
stability
by avoiding killing overseer.
> Frequent failures of MoveReplicaHDFSTest.testFailedMove
> ---
>
> Key: SOLR-12080
> URL: https://issues.apache.org/jira/browse/SOLR-12080
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: jenkins.log.txt.gz
>
>
> This test frequently fails. This is one of the failing seeds:
> {code}
>[junit4] 2> 129275 INFO (qtp1647120030-248) [n:127.0.0.1:55469_solr
> c:MoveReplicaHDFSTest_failed_coll_true s:shard2 r:core_node7
> x:MoveReplicaHDFSTest_failed_coll_true_shard2_replica_n4] o.a.s.c.S.Request
> [MoveReplicaHDFSTest_failed_coll_true_shard2_replica_n4] webapp=/solr
> path=/select
> params={q=*:*&_stateVer_=MoveReplicaHDFSTest_failed_coll_true:9=javabin=2}
> status=503 QTime=0
>[junit4] 2> 129278 ERROR (qtp148844424-682) [n:127.0.0.1:54855_solr
> c:MoveReplicaHDFSTest_failed_coll_true s:shard2 r:core_node8
> x:MoveReplicaHDFSTest_failed_coll_true_shard2_replica_n6]
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: no servers
> hosting shard: shard1
>[junit4] 2> at
> org.apache.solr.handler.component.HttpShardHandler.prepDistributed(HttpShardHandler.java:436)
>[junit4] 2> at
> org.apache.solr.handler.component.SearchHandler.getAndPrepShardHandler(SearchHandler.java:226)
>[junit4] 2> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:264)
>[junit4] 2> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
>[junit4] 2> at
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
>[junit4] 2> at
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>[junit4] 2> at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:517)
>[junit4] 2> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)
>[junit4] 2> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)
>[junit4] 2> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>[junit4] 2> at
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
>[junit4] 2> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>[junit4] 2> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>[junit4] 2> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
>[junit4] 2> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
>[junit4] 2> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:527)
>[junit4] 2> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>[junit4] 2> at
> org.eclipse.jetty.server.Server.handle(Server.java:530)
>[junit4] 2> at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)
>[junit4] 2> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)
>[junit4] 2> at
>
[jira] [Commented] (LUCENE-8454) Polygon tessellator can get into an infinite loop
[
https://issues.apache.org/jira/browse/LUCENE-8454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622893#comment-16622893
]
ASF subversion and git services commented on LUCENE-8454:
-
Commit d7e97fb7f84d8613683a080610f177b7cae2b31a in lucene-solr's branch
refs/heads/jira/http2 from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d7e97fb ]
LUCENE-8454: Fix tessellator to use original polygon vertices.
> Polygon tessellator can get into an infinite loop
> -
>
> Key: LUCENE-8454
> URL: https://issues.apache.org/jira/browse/LUCENE-8454
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8454.patch
>
>
> I was trying to index some shapes using {{LatLonshape}} and for some complex
> shapes, there teselletor goes into an infinite loop. I am providing a test
> showing the problem.
>
> [~nknize], you might be interested on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1130 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1130/ No tests ran. Build Log: [...truncated 23270 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 2429 links (1981 relative) to 3172 anchors in 246 files [echo] Validated Links & Anchors via: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked [untar] Expanding: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-8.0.0.tgz into /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.
[jira] [Commented] (SOLR-11694) Remove extremely outdated UIMA contrib module
[ https://issues.apache.org/jira/browse/SOLR-11694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622839#comment-16622839 ] Aaron LaBella commented on SOLR-11694: -- Apace UIMA 3.0 is in alpha state, and it'll probably be a long time before a.) its an actual 3.0 release and b.) anyone out there actually adopts it. 2.10.2 is the latest and its from February of 2018. I'm really not sure why we're pulling a feature out of Solr that has to be used out there by several people. What harm does it have to keep it there? We're saving 7MB of space?? I don't actively follow the Solr mailing list and I'm not sure just because no one responded in ~6 months that you can safely assume that the entire community doesn't use UIMA. I feel strongly that this is not the right decision here. If you want to clean up, I'd agree, remove the AlchemyAPI, OpenCalais, and Tagger. Upgrade uima-core 2.3.1 to 2.10.2 and keep the rest of the Solr/UIMA classes – they work just fine. There's no reason to pull this contrib project. > Remove extremely outdated UIMA contrib module > - > > Key: SOLR-11694 > URL: https://issues.apache.org/jira/browse/SOLR-11694 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Reporter: Cassandra Targett >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: 7.5, master (8.0) > > Attachments: SOLR-11694.patch > > > A user on the [solr-user mailing list back in > June|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3CCANsk%2BC_PvZJ38AQ2VfzKRYSQn6c8b33kGvaXxR3qNS3GQ4VUKA%40mail.gmail.com%3E] > brought up the fact that IBM has bought Alchemy and keys are no longer > available to use Solr's UIMA contrib. > Someone recently made a [similar > comment|https://lucene.apache.org/solr/guide/7_1/uima-integration.html#comment_7174] > to the Solr Ref Guide page and asking for a patch. > I know next to nothing about UIMA, but figured it's worth an issue to > determine what to do here. I think folks are saying it's no longer usable? Or > maybe only usable by people who already have keys (which will possibly expire > at some point)? > Anyone have an idea what needs to be done here? It seems we should have some > kind of answer, but if it's no longer usable perhaps we should retire the > contrib. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 822 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/822/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 4 tests failed. FAILED: org.apache.solr.cloud.api.collections.ShardSplitTest.test Error Message: Could not find new collection splitByRouteKeyTest Stack Trace: java.lang.AssertionError: Could not find new collection splitByRouteKeyTest at __randomizedtesting.SeedInfo.seed([32C14E9773624CC9:BA95714DDD9E2131]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkForCollection(AbstractFullDistribZkTestBase.java:1823) at org.apache.solr.cloud.api.collections.ShardSplitTest.splitByRouteKeyTest(ShardSplitTest.java:790) at org.apache.solr.cloud.api.collections.ShardSplitTest.test(ShardSplitTest.java:109) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1008) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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
[jira] [Commented] (LUCENE-8511) MultiFields.getIndexedFields can be optimized to not use getMergedFieldInfos
[ https://issues.apache.org/jira/browse/LUCENE-8511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622786#comment-16622786 ] Yonik Seeley commented on LUCENE-8511: -- Looks good, +1 to avoiding getMergedFieldInfos() here! > MultiFields.getIndexedFields can be optimized to not use getMergedFieldInfos > > > Key: LUCENE-8511 > URL: https://issues.apache.org/jira/browse/LUCENE-8511 > Project: Lucene - Core > Issue Type: Improvement >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE-8511.patch, LUCENE-8511.patch > > > MultiFields.getIndexedFields calls getMergedFieldInfos. But > getMergedFieldInfos is kinda heavy, doing all sorts of stuff that > getIndexedFields doesn't care about. It can simply loop the leaf readers and > collect the results into a Set. Java 8 streams should make easy work of this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11694) Remove extremely outdated UIMA contrib module
[ https://issues.apache.org/jira/browse/SOLR-11694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622691#comment-16622691 ] Alexandre Rafalovitch commented on SOLR-11694: -- I think the proper indexing pipeline is already the Apache NiFi or Apache Camel. Both are our sister projects that do have some support for Solr. So to me, the really correct thing would be to get really close to one or both of them and ensure they cover all our use cases and their Solr integration is top notch. I think that building a bridge between two large cities/projects is better than trying to grow our own city satellite. > Remove extremely outdated UIMA contrib module > - > > Key: SOLR-11694 > URL: https://issues.apache.org/jira/browse/SOLR-11694 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Reporter: Cassandra Targett >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: 7.5, master (8.0) > > Attachments: SOLR-11694.patch > > > A user on the [solr-user mailing list back in > June|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3CCANsk%2BC_PvZJ38AQ2VfzKRYSQn6c8b33kGvaXxR3qNS3GQ4VUKA%40mail.gmail.com%3E] > brought up the fact that IBM has bought Alchemy and keys are no longer > available to use Solr's UIMA contrib. > Someone recently made a [similar > comment|https://lucene.apache.org/solr/guide/7_1/uima-integration.html#comment_7174] > to the Solr Ref Guide page and asking for a patch. > I know next to nothing about UIMA, but figured it's worth an issue to > determine what to do here. I think folks are saying it's no longer usable? Or > maybe only usable by people who already have keys (which will possibly expire > at some point)? > Anyone have an idea what needs to be done here? It seems we should have some > kind of answer, but if it's no longer usable perhaps we should retire the > contrib. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12746) Ref Guide HTML output should adhere to more standard HTML5
[
https://issues.apache.org/jira/browse/SOLR-12746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622419#comment-16622419
]
Cassandra Targett edited comment on SOLR-12746 at 9/20/18 8:41 PM:
---
There is now a branch for this work, that is getting close to being ready to
merge:
[https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=tree;h=refs/heads/jira/solr-12746;hb=refs/heads/jira/solr-12746]
Some info:
# These changes require us to add a new {{_templates}} directory to direct
Asciidoctor to use different selectors and classes when building the HTML. I
started out with templates from
[https://github.com/jirutka/asciidoctor-html5s], but modified them in many ways
to change their classnames to the ones we were already using to simplify the
process of fixing our CSS files.
** I have not yet dug into adding license info to Solr for use of these (or if
I even need to since we aren't distributing the templates themselves), but the
project uses the MIT license so it should be fine whatever we end up needing to
do (TODO).
# The Liquid templates used by Jekyll are still there, and have been modified
to use {{}} and {{}} tags instead of divs to identify the
sections of the page that are content vs navigational elements.
# I tried to simplify some of the layers of divs, but there's possibly more
that could be done. For example, for a paragraph there used to be about 6
nested divs, like: {{column > post-content > main-content > sect1 > sectionbody
> paragraph > p}}, but now it's closer to: {{column > content > sect1 > p}}.
# I threw in some other CSS changes for stuff that has been bugging me -
specifically the padding of 2nd level bullets in the in-page TOC, and changing
the 2nd level bullets to use an open circle instead of "-".
Caveats:
# The templates require that you have Slim installed locally in order to build
the HTML. I've added instructions for this to {{solr-ref-guide/README.txt}} in
the branch, but have not updated the Jenkins build script yet (TODO).
# There is an error output by the Slim engine ({{Slim::Engine: Option
:asciidoc is invalid}}) during the HTML build for every template (so, 30+
times). I suspect it's related to a part of our Jekyll config that we have to
have. There is supposedly some way to declare to Slim that it should ignore
this, but I haven't yet been able to figure it out yet. I also asked about it
on the [Asciidoctor mailing
list|http://discuss.asciidoctor.org/Slim-Engine-Option-asciidoc-invalid-with-custom-templates-and-Jekyll-td6477.html],
but have not yet had a reply (TODO).
was (Author: ctargett):
There is now a branch for this work, that is getting close to being ready to
merge:
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=tree;h=refs/heads/jira/solr-12746;hb=refs/heads/jira/solr-12746
Some info:
# These changes require us to add a new {{_templates}} directory to direct
Asciidoctor to use different selectors and classes when building the HTML. I
started out with templates from https://github.com/jirutka/asciidoctor-html5s,
but modified them in many ways to change their classnames to the ones we were
already using to simplify the process of fixing our CSS files.
** I have not yet dug into adding license info to Solr for use of these (or if
I even need to since we aren't distributing the templates themselves), but the
project uses the MIT license so it should be fine whatever we end up needing to
do (TODO).
# The Liquid templates used by Jekyll are still there, and have been modified
to use {{}} and {{}} tags instead of divs to identify the
sections of the page that are content vs navigational elements.
# I tried to simplify some of the layers of divs, but there's possibly more
that could be done. For example, for a paragraph there used to be about 6
nested divs, like: {{column > post-content > main-content > sect1 > sectionbody
> paragraph > p}}, but now it's closer to: {{column > content > sect1 > p}}.
# I threw in some other CSS changes for stuff that has been bugging me -
specifically the padding of 2nd level bullets in the in-page TOC, and changing
the 2nd level bullets to use an open circle instead of "-".
Caveats:
# The templates require that you have Slim installed locally in order to build
the HTML. I've added instructions for this to {{solr-ref-guide/README.txt}} in
the branch, but have not updated the Jenkins build script yet (TODO).
# There is an error output by the Slim engine ({{Slim::Engine: Option :asciidoc
is invalid}}) during the HTML build for every template (so, 30+ times). I
suspect it's related to a part of our Jekyll config that we have to have. There
is supposedly some way to declare to Slim that it should ignore this, but I
haven't yet been able to figure it out yet. I also asked about it on the
Asciidoctor mailing list, but have not yet had a reply (TODO).
> Ref
[GitHub] lucene-solr pull request #451: LUCENE-8496: Add selective indexing to BKD/PO...
Github user nknize commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/451#discussion_r219310315
--- Diff: lucene/core/src/java/org/apache/lucene/util/bkd/BKDWriter.java ---
@@ -981,15 +988,15 @@ public long finish(IndexOutput out) throws
IOException {
assert pointCount / numLeaves <= maxPointsInLeafNode: "pointCount=" +
pointCount + " numLeaves=" + numLeaves + " maxPointsInLeafNode=" +
maxPointsInLeafNode;
// Sort all docs once by each dimension:
-PathSlice[] sortedPointWriters = new PathSlice[numDims];
+PathSlice[] sortedPointWriters = new PathSlice[numDataDims];
// This is only used on exception; on normal code paths we close all
files we opened:
List toCloseHeroically = new ArrayList<>();
boolean success = false;
try {
//long t0 = System.nanoTime();
- for(int dim=0;dim
[jira] [Commented] (SOLR-11694) Remove extremely outdated UIMA contrib module
[ https://issues.apache.org/jira/browse/SOLR-11694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622676#comment-16622676 ] Eric Pugh commented on SOLR-11694: -- I've been down the upgrade UIMA process before, and I failed.. I dug into JIRA, and it was back in 2012! SOLR-3736 and SOLR-3738 specifically. I think as important as adding new features is deprecating/removing features that no longer have significant community support. As fascinated as I was by UIMA, I think that is an example of a feature that doesn't really fit into the mainline use cases for Solr, otherwise the upgrade to UIMA 3.x would have happened before now. I suspect that the best thing would be a proper indexing pipeline that encompasses the use cases for Tika, UIMA, the ScriptingUpdateRequestHandler and friends? Then you could have the UIMA plugin be it's own project with it's own dedicated folks...But right now, I think the core Solr committership isn't interested in UIMA. > Remove extremely outdated UIMA contrib module > - > > Key: SOLR-11694 > URL: https://issues.apache.org/jira/browse/SOLR-11694 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Reporter: Cassandra Targett >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: 7.5, master (8.0) > > Attachments: SOLR-11694.patch > > > A user on the [solr-user mailing list back in > June|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3CCANsk%2BC_PvZJ38AQ2VfzKRYSQn6c8b33kGvaXxR3qNS3GQ4VUKA%40mail.gmail.com%3E] > brought up the fact that IBM has bought Alchemy and keys are no longer > available to use Solr's UIMA contrib. > Someone recently made a [similar > comment|https://lucene.apache.org/solr/guide/7_1/uima-integration.html#comment_7174] > to the Solr Ref Guide page and asking for a patch. > I know next to nothing about UIMA, but figured it's worth an issue to > determine what to do here. I think folks are saying it's no longer usable? Or > maybe only usable by people who already have keys (which will possibly expire > at some point)? > Anyone have an idea what needs to be done here? It seems we should have some > kind of answer, but if it's no longer usable perhaps we should retire the > contrib. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11694) Remove extremely outdated UIMA contrib module
[ https://issues.apache.org/jira/browse/SOLR-11694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622663#comment-16622663 ] Alexandre Rafalovitch commented on SOLR-11694: -- Here is a couple of decision points that went into this: # I made a call for UIMA use cases on the Solr Users mailing list and got zero positive replies. # UIMA version 2.8 was released in May 2016 # The current version of UIMA is 3.x, with a completely different infrastructure # We had integration points that no longer worked for very long time # I think you probably can still use UIMA as your own custom module, most of the integration I deleted was to get it to build and ship (and all the dead examples). I would say a contribution that upgrades UIMA to the latest 3.x version with at least rudimentary example/documentation would be viewed positively. However, it does not seem to be what is being offered here. So, I am -0 on the proposal to just reverse. Others may have a different opinion. > Remove extremely outdated UIMA contrib module > - > > Key: SOLR-11694 > URL: https://issues.apache.org/jira/browse/SOLR-11694 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Reporter: Cassandra Targett >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: 7.5, master (8.0) > > Attachments: SOLR-11694.patch > > > A user on the [solr-user mailing list back in > June|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3CCANsk%2BC_PvZJ38AQ2VfzKRYSQn6c8b33kGvaXxR3qNS3GQ4VUKA%40mail.gmail.com%3E] > brought up the fact that IBM has bought Alchemy and keys are no longer > available to use Solr's UIMA contrib. > Someone recently made a [similar > comment|https://lucene.apache.org/solr/guide/7_1/uima-integration.html#comment_7174] > to the Solr Ref Guide page and asking for a patch. > I know next to nothing about UIMA, but figured it's worth an issue to > determine what to do here. I think folks are saying it's no longer usable? Or > maybe only usable by people who already have keys (which will possibly expire > at some point)? > Anyone have an idea what needs to be done here? It seems we should have some > kind of answer, but if it's no longer usable perhaps we should retire the > contrib. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12786) Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
[
https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622655#comment-16622655
]
Jan Høydahl commented on SOLR-12786:
That's right, I changed the description.
> Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
> --
>
> Key: SOLR-12786
> URL: https://issues.apache.org/jira/browse/SOLR-12786
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
>Affects Versions: master (8.0)
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12786.patch
>
>
> Currently the refguide build requires asciidoctor 1.5.6.2.
> People using {{gem install jekyll-asciidoc}} will end up with version 1.5.7,
> causing different header ID syntax and the build will break.
> Long term we should move to latest asciidoctor.
> It is already documented in README how to install the older 1.5.6.2 version.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12786) Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
[
https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-12786:
---
Issue Type: Improvement (was: Bug)
> Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
> --
>
> Key: SOLR-12786
> URL: https://issues.apache.org/jira/browse/SOLR-12786
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
>Affects Versions: master (8.0)
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12786.patch
>
>
> Currently the refguide build requires asciidoctor 1.5.6.2.
> People using {{gem install jekyll-asciidoc}} will end up with version 1.5.7,
> causing different header ID syntax and the build will break.
> Long term we should move to latest asciidoctor.
> It is already documented in README how to install the older 1.5.6.2 version.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12786) Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
[
https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-12786:
---
Description:
Currently the refguide build requires asciidoctor 1.5.6.2.
People using {{gem install jekyll-asciidoc}} will end up with version 1.5.7,
causing different header ID syntax and the build will break.
Long term we should move to latest asciidoctor.
It is already documented in README how to install the older 1.5.6.2 version.
was:
Currently the refguide build requires asciidoctor 1.5.6.2.
People using {{gem install jekyll-asciidoc}} will end up with version 1.5.7,
causing different header ID syntax and the build will break.
Long term we should move to latest asciidoctor.
Short term we can document how to install jekyll-asciidoc with the exact
version needed:
{noformat}
gem install asciidoctor:1.5.6.2 jekyll-asciidoc
{noformat}
> Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
> --
>
> Key: SOLR-12786
> URL: https://issues.apache.org/jira/browse/SOLR-12786
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
>Affects Versions: master (8.0)
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12786.patch
>
>
> Currently the refguide build requires asciidoctor 1.5.6.2.
> People using {{gem install jekyll-asciidoc}} will end up with version 1.5.7,
> causing different header ID syntax and the build will break.
> Long term we should move to latest asciidoctor.
> It is already documented in README how to install the older 1.5.6.2 version.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12791) Add Metrics reporting for AuthenticationPlugin
[
https://issues.apache.org/jira/browse/SOLR-12791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622651#comment-16622651
]
Jan Høydahl commented on SOLR-12791:
First patch (Pull request) with metrics recorded in BasicAuthPlugin. No tests
so far
> Add Metrics reporting for AuthenticationPlugin
> --
>
> Key: SOLR-12791
> URL: https://issues.apache.org/jira/browse/SOLR-12791
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, metrics
>Reporter: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Propose to add Metrics support for all Auth plugins. Will let abstract
> {{AuthenticationPlugin}} base class implement {{SolrMetricProducer}} and keep
> the counters, such as:
> * requests
> * req authenticated
> * req pass-through (no credentials and blockUnknown false)
> * req with auth failures due to wrong or malformed credentials
> * req auth failures due to missing credentials
> * errors
> * timeouts
> * timing stats
> Each implementation still needs to increment the counters etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #457: SOLR-12791: Add Metrics reporting for Authent...
GitHub user janhoy opened a pull request: https://github.com/apache/lucene-solr/pull/457 SOLR-12791: Add Metrics reporting for AuthenticationPlugin First partial patch You can merge this pull request into a Git repository by running: $ git pull https://github.com/cominvent/lucene-solr solr12791-auth-metrics Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/457.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #457 commit 89608a9188cca30068f9fb74d5e06054748c6ec1 Author: Jan Høydahl Date: 2018-09-20T19:54:12Z SOLR-12791: First impl. Still no tests --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 2068 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/2068/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.TestPullReplica.testRealTimeGet Error Message: Unexpected replica count null Live Nodes: [127.0.0.1:47285_solr, 127.0.0.1:61484_solr] Last available state: null Stack Trace: java.lang.AssertionError: Unexpected replica count null Live Nodes: [127.0.0.1:47285_solr, 127.0.0.1:61484_solr] Last available state: null at __randomizedtesting.SeedInfo.seed([809F1FB1CAEFA7C8:D8F2EAB268550901]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:280) at org.apache.solr.cloud.TestPullReplica.testRealTimeGet(TestPullReplica.java:348) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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) Build Log: [...truncated 13477 lines...] [junit4] Suite: org.apache.solr.cloud.TestPullReplica
[jira] [Resolved] (SOLR-12788) RecoveryStrategy throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/SOLR-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki resolved SOLR-12788.
--
Resolution: Duplicate
> RecoveryStrategy throws IndexOutOfBoundsException
> -
>
> Key: SOLR-12788
> URL: https://issues.apache.org/jira/browse/SOLR-12788
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (8.0)
>Reporter: Andrzej Bialecki
>Priority: Major
>
> I spotted this when trying to reproduce a test failure:
> {code}
>[junit4] 2> 32176 ERROR
> (recoveryExecutor-132-thread-1-processing-n:127.0.0.1:53696_i
> x:collection1_shard4_replica_n93 c:collection1 s:shard4 r:core_node94)
> [n:127.0.0.1:53696_i c:collection1 s:shard4 r:core_node94
> x:collection1_shard4_replica_n93] o.a.s.c.RecoveryStrategy Error getting
> recent versions.:java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
>[junit4] 2> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
>[junit4] 2> at java.util.ArrayList.get(ArrayList.java:429)
>[junit4] 2> at
> org.apache.solr.cloud.RecoveryStrategy.doSyncOrReplicateRecovery(RecoveryStrategy.java:491)
>[junit4] 2> at
> org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:310)
>[junit4] 2> at
> org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:294)
>[junit4] 2> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
>[junit4] 2> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>[junit4] 2> at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>[junit4] 2> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
>[junit4] 2> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>[junit4] 2> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>[junit4] 2> at java.lang.Thread.run(Thread.java:745)
> {code}
> This reproduces consistently with the following command:
> {code}
> ant test -Dtestcase=ShardRoutingTest -Dtests.method=test
> -Dtests.seed=FF7B7D65A8936A3D -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=ar-BH -Dtests.timezone=Indian/Mahe -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr add doc with overwrite=false and presence of UpdateLog
Then how about: if the UpdateLog is in effect, then overwrite=false is ignored (uniqueKey constraint honored). If we've already agreed it's "wrong" to expect duplicated docs with overwrite=false, then we can choose to ignore this performance hint in certain cases. RE your aside: agreed! On Thu, Sep 20, 2018 at 3:33 PM Yonik Seeley wrote: > On Thu, Sep 20, 2018 at 3:18 PM David Smiley > wrote: > >> Is it even sensible to want overwrite=false and have an UpdateLog? That >> is, isn't the weight of the UpdateLog well more than whatever savings are >> had with overwrite=false? I suspect that the combinbing these two today >> has edge cases we don't even realize, despite the apparent lack of >> exceptions. >> > > They don't seem mutually exclusive or anything. It's true that you would > gain more in performance by not using the update log than by > overwrite=false. But it's also true that overwrite=false is implemented in > a way that has no functional impact and the same can't be said for not > using the update log (i.e. people can't just remove the update log and have > everything work like it did). > > Aside: bulk indexing is enough of a pain point / important use case, we > *should* figure out how to do it better by skipping as much as possible > (update log included) and still have explainable rational behavior. That's > something for the future though... > > -Yonik > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
Re: Solr add doc with overwrite=false and presence of UpdateLog
On Thu, Sep 20, 2018 at 3:18 PM David Smiley wrote: > Is it even sensible to want overwrite=false and have an UpdateLog? That > is, isn't the weight of the UpdateLog well more than whatever savings are > had with overwrite=false? I suspect that the combinbing these two today > has edge cases we don't even realize, despite the apparent lack of > exceptions. > They don't seem mutually exclusive or anything. It's true that you would gain more in performance by not using the update log than by overwrite=false. But it's also true that overwrite=false is implemented in a way that has no functional impact and the same can't be said for not using the update log (i.e. people can't just remove the update log and have everything work like it did). Aside: bulk indexing is enough of a pain point / important use case, we *should* figure out how to do it better by skipping as much as possible (update log included) and still have explainable rational behavior. That's something for the future though... -Yonik
[jira] [Created] (SOLR-12791) Add Metrics reporting for AuthenticationPlugin
Jan Høydahl created SOLR-12791:
--
Summary: Add Metrics reporting for AuthenticationPlugin
Key: SOLR-12791
URL: https://issues.apache.org/jira/browse/SOLR-12791
Project: Solr
Issue Type: New Feature
Security Level: Public (Default Security Level. Issues are Public)
Components: Authentication, metrics
Reporter: Jan Høydahl
Propose to add Metrics support for all Auth plugins. Will let abstract
{{AuthenticationPlugin}} base class implement {{SolrMetricProducer}} and keep
the counters, such as:
* requests
* req authenticated
* req pass-through (no credentials and blockUnknown false)
* req with auth failures due to wrong or malformed credentials
* req auth failures due to missing credentials
* errors
* timeouts
* timing stats
Each implementation still needs to increment the counters etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr add doc with overwrite=false and presence of UpdateLog
Alternatively, would it make sense for overwrite=false to _skip_ the UpdateLog if it is present (and assuming you're not using CDCR since that's based on the UpdateLog)? I don't know. On Thu, Sep 20, 2018 at 3:18 PM David Smiley wrote: > Is it even sensible to want overwrite=false and have an UpdateLog? That > is, isn't the weight of the UpdateLog well more than whatever savings are > had with overwrite=false? I suspect that the combinbing these two today > has edge cases we don't even realize, despite the apparent lack of > exceptions. > > On Thu, Sep 20, 2018 at 3:11 PM Yonik Seeley wrote: > >> On Thu, Sep 20, 2018 at 2:18 PM David Smiley >> wrote: >> >>> Thanks for the context. >>> >>> I'd like to do a few things: >>> * Document that "overwrite" is a (potentially dangerous) peformance hack >>> for documents that are assumed to be already unique. It is not to be used >>> to deliberately violate the uniqueKey constraint; this is considered >>> erroneous and unsupported use. >>> >> >> +1 >> >> >>> * Document *and enforce* that "overwrite" does not work with the >>> UpdateLog. User error; let them know. While we maintain the UpdateLog, I >>> don't want to have the complexity burden of considering how to support >>> overwrite=true. I'm not saying it's super complex, only that UpdateLog is >>> already complex and I don't think the value of overwrite is good enough for >>> me to want to maintain the two together. I hope others can appreciate this >>> point; I'm don't wish to be difficult. If someone volunteers to make it >>> work in a way that isn't complex then go for it. *It appears it might >>> work today but I wish to break this.* >>> >> >> Throwing an exception for overwrite=false when using UpdateLog will >> impact some users though (back compat break and performance regression), so >> I'd like to understand what we gain, and if it's enough of a gain to >> compensate. If updating nested docs doesn't immediately implement >> overwrite=false, it doesn't seem like a big deal. Prohibiting it from ever >> working on the other hand, doesn't seem like the right trade-off. >> >> >>> * Consequently, ConvertedLegacyTest needs fixing. If the intent of the >>> legacy test is to see that the document can be added and violate the >>> uniqueKey, then this test needs to use a config without the UpdateLog. Or >>> we keep the default config (with UpdateLog) and adjust the test's >>> expectations. >>> >> >> +1 >> >> -Yonik >> >> >>> >>> On Thu, Sep 20, 2018 at 1:42 PM Yonik Seeley wrote: >>> Yep, It's only for performance. I know a number of people using overwrite=false when doing bulk indexing, and then often later using normal adds for incremental changes. As far as why "overwrite(Pending|Committed)?" exists at all: it's been there since Solr was open sourced (SOLR-1), so there wouldn't be a discussion to find. Lucene had no concept of unique IDs or overwriting at the time and it was all implemented in Solr-land. The cost to enforce was significant (and still can be today), and often unneeded when building an index from a source known to have unique IDs already. -Yonik -- >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >>> http://www.solrenterprisesearchserver.com >>> >> -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: > http://www.solrenterprisesearchserver.com > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
Re: Solr add doc with overwrite=false and presence of UpdateLog
Is it even sensible to want overwrite=false and have an UpdateLog? That is, isn't the weight of the UpdateLog well more than whatever savings are had with overwrite=false? I suspect that the combinbing these two today has edge cases we don't even realize, despite the apparent lack of exceptions. On Thu, Sep 20, 2018 at 3:11 PM Yonik Seeley wrote: > On Thu, Sep 20, 2018 at 2:18 PM David Smiley > wrote: > >> Thanks for the context. >> >> I'd like to do a few things: >> * Document that "overwrite" is a (potentially dangerous) peformance hack >> for documents that are assumed to be already unique. It is not to be used >> to deliberately violate the uniqueKey constraint; this is considered >> erroneous and unsupported use. >> > > +1 > > >> * Document *and enforce* that "overwrite" does not work with the >> UpdateLog. User error; let them know. While we maintain the UpdateLog, I >> don't want to have the complexity burden of considering how to support >> overwrite=true. I'm not saying it's super complex, only that UpdateLog is >> already complex and I don't think the value of overwrite is good enough for >> me to want to maintain the two together. I hope others can appreciate this >> point; I'm don't wish to be difficult. If someone volunteers to make it >> work in a way that isn't complex then go for it. *It appears it might >> work today but I wish to break this.* >> > > Throwing an exception for overwrite=false when using UpdateLog will impact > some users though (back compat break and performance regression), so I'd > like to understand what we gain, and if it's enough of a gain to > compensate. If updating nested docs doesn't immediately implement > overwrite=false, it doesn't seem like a big deal. Prohibiting it from ever > working on the other hand, doesn't seem like the right trade-off. > > >> * Consequently, ConvertedLegacyTest needs fixing. If the intent of the >> legacy test is to see that the document can be added and violate the >> uniqueKey, then this test needs to use a config without the UpdateLog. Or >> we keep the default config (with UpdateLog) and adjust the test's >> expectations. >> > > +1 > > -Yonik > > >> >> On Thu, Sep 20, 2018 at 1:42 PM Yonik Seeley wrote: >> >>> Yep, It's only for performance. I know a number of people using >>> overwrite=false when doing bulk indexing, and then often later using normal >>> adds for incremental changes. >>> >>> As far as why "overwrite(Pending|Committed)?" exists at all: it's been >>> there since Solr was open sourced (SOLR-1), so there wouldn't be a >>> discussion to find. Lucene had no concept of unique IDs or overwriting at >>> the time and it was all implemented in Solr-land. The cost to enforce was >>> significant (and still can be today), and often unneeded when building an >>> index from a source known to have unique IDs already. >>> >>> -Yonik >>> >>> -- >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> http://www.solrenterprisesearchserver.com >> > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
[jira] [Commented] (SOLR-12502) Unify and reduce the number of SolrClient#add methods
[
https://issues.apache.org/jira/browse/SOLR-12502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622549#comment-16622549
]
David Smiley commented on SOLR-12502:
-
Ehh; in common cases this adds complexity, I think. Simply adding one document
means you now need to use SolrInputDocumentProvider, which is also a new
abstraction.
Towards the end of your suggestion, in terms of "builder like", you have me
thinking we already have UpdateRequest which is to a degree builder like.
Perhaps it could be made to work with SolrClient even more easily. Ideally,
IMO, you could have some client code that only needs to import SolrClient in
scope to then call methods on SolrClient that perhaps work with UpdateRequest
and you finally submit it. Today this is invisible with add() which is
completely hiding it's use of UpdateRequest but imagine this:
{{solrClient.updateReq().add(myDoc).setCommitWithin(commitWithinMs).setCollection(collection).send()}}
RE the collection: We could make the notion of a default collection built-in to
each SolrClient. And if you want to change it then you wrap one with a
delegate SolrClient that changes settings like this. HttpSolrClient would have
to change a little to be more clear on wether it has a default collection or
not; it's a bit ambiguous today leaving it up to whoever writes the URL.
> Unify and reduce the number of SolrClient#add methods
> -
>
> Key: SOLR-12502
> URL: https://issues.apache.org/jira/browse/SOLR-12502
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Reporter: Varun Thacker
>Priority: Major
>
> On SOLR-11654 we noticed that SolrClient#add has 10 overloaded methods which
> can be very confusing to new users.
> Also the UpdateRequest class is public so that means if a user is looking for
> a custom combination they can always choose to do so by writing a couple of
> lines of code.
> For 8.0 which might not be very far away we can improve this situation
>
> Quoting David from SOLR-11654
> {quote}Any way I guess we'll leave SolrClient alone. Thanks for your input
> Varun. Yes it's a shame there are so many darned overloaded methods... I
> think it's a large part due to the optional "collection" parameter which like
> doubles the methods! I've been bitten several times writing SolrJ code that
> doesn't use the right overloaded version (forgot to specify collection). I
> think for 8.0, *either* all SolrClient methods without "collection" can be
> removed in favor of insisting you use the overloaded variant accepting a
> collection, *or* SolrClient itself could be locked down to one collection at
> the time you create it *or* have a CollectionSolrClient interface retrieved
> from a SolrClient.withCollection(collection) in which all the operations that
> require a SolrClient are on that interface and not SolrClient proper.
> Several ideas to consider.
> {quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr add doc with overwrite=false and presence of UpdateLog
On Thu, Sep 20, 2018 at 2:18 PM David Smiley wrote: > Thanks for the context. > > I'd like to do a few things: > * Document that "overwrite" is a (potentially dangerous) peformance hack > for documents that are assumed to be already unique. It is not to be used > to deliberately violate the uniqueKey constraint; this is considered > erroneous and unsupported use. > +1 > * Document *and enforce* that "overwrite" does not work with the > UpdateLog. User error; let them know. While we maintain the UpdateLog, I > don't want to have the complexity burden of considering how to support > overwrite=true. I'm not saying it's super complex, only that UpdateLog is > already complex and I don't think the value of overwrite is good enough for > me to want to maintain the two together. I hope others can appreciate this > point; I'm don't wish to be difficult. If someone volunteers to make it > work in a way that isn't complex then go for it. *It appears it might > work today but I wish to break this.* > Throwing an exception for overwrite=false when using UpdateLog will impact some users though (back compat break and performance regression), so I'd like to understand what we gain, and if it's enough of a gain to compensate. If updating nested docs doesn't immediately implement overwrite=false, it doesn't seem like a big deal. Prohibiting it from ever working on the other hand, doesn't seem like the right trade-off. > * Consequently, ConvertedLegacyTest needs fixing. If the intent of the > legacy test is to see that the document can be added and violate the > uniqueKey, then this test needs to use a config without the UpdateLog. Or > we keep the default config (with UpdateLog) and adjust the test's > expectations. > +1 -Yonik > > On Thu, Sep 20, 2018 at 1:42 PM Yonik Seeley wrote: > >> Yep, It's only for performance. I know a number of people using >> overwrite=false when doing bulk indexing, and then often later using normal >> adds for incremental changes. >> >> As far as why "overwrite(Pending|Committed)?" exists at all: it's been >> there since Solr was open sourced (SOLR-1), so there wouldn't be a >> discussion to find. Lucene had no concept of unique IDs or overwriting at >> the time and it was all implemented in Solr-land. The cost to enforce was >> significant (and still can be today), and often unneeded when building an >> index from a source known to have unique IDs already. >> >> -Yonik >> >> -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: > http://www.solrenterprisesearchserver.com >
[jira] [Comment Edited] (SOLR-11694) Remove extremely outdated UIMA contrib module
[ https://issues.apache.org/jira/browse/SOLR-11694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622539#comment-16622539 ] Aaron LaBella edited comment on SOLR-11694 at 9/20/18 7:08 PM: --- Hi Team, _*How do we undo this commit/decision?*_ We use UIMA and SOLR +*every day*+ in production, and this decision will effectively freeze us on the last working Solr / UIMA version of 7.4.0. Surely there are other folks out there doing text analytics with even older versions of UIMA and wish to use the latest and greatest solr? Aso, even though SOLR/LUCENE "ship" with UIMA 2.3.1, I've been using UIMA 2.8.1 for 2+ years by simply dropping in the more up-to-date JAR in the core-specific "lib" directory. I'd have to look through all the lucene stuff again, but, I'm quite certain the lucene support for UIMA is still active as well, no? was (Author: aaronlab): Hi Team, How do we undo this commit/decision? We use UIMA and SOLR +*every day*+ in production, and this decision will effectively freeze us on the last working Solr / UIMA version of 7.4.0. Surely there are other folks out there doing text analytics with even older versions of UIMA and wish to use the latest and greatest solr? ALso, even though SOLR/LUCENE "ship" with UIMA 2.3.1, I've been using UIMA 2.8.1 for 2+ years by simply dropping in the more up-to-date JAR in the core-specific "lib" directory. I'd have to look through all the lucene stuff again, but, I'm quite certain the lucene support for UIMA is still active as well, no? > Remove extremely outdated UIMA contrib module > - > > Key: SOLR-11694 > URL: https://issues.apache.org/jira/browse/SOLR-11694 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Reporter: Cassandra Targett >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: 7.5, master (8.0) > > Attachments: SOLR-11694.patch > > > A user on the [solr-user mailing list back in > June|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3CCANsk%2BC_PvZJ38AQ2VfzKRYSQn6c8b33kGvaXxR3qNS3GQ4VUKA%40mail.gmail.com%3E] > brought up the fact that IBM has bought Alchemy and keys are no longer > available to use Solr's UIMA contrib. > Someone recently made a [similar > comment|https://lucene.apache.org/solr/guide/7_1/uima-integration.html#comment_7174] > to the Solr Ref Guide page and asking for a patch. > I know next to nothing about UIMA, but figured it's worth an issue to > determine what to do here. I think folks are saying it's no longer usable? Or > maybe only usable by people who already have keys (which will possibly expire > at some point)? > Anyone have an idea what needs to be done here? It seems we should have some > kind of answer, but if it's no longer usable perhaps we should retire the > contrib. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11694) Remove extremely outdated UIMA contrib module
[ https://issues.apache.org/jira/browse/SOLR-11694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622539#comment-16622539 ] Aaron LaBella edited comment on SOLR-11694 at 9/20/18 7:08 PM: --- Hi Team, How do we undo this commit/decision? We use UIMA and SOLR +*every day*+ in production, and this decision will effectively freeze us on the last working Solr / UIMA version of 7.4.0. Surely there are other folks out there doing text analytics with even older versions of UIMA and wish to use the latest and greatest solr? ALso, even though SOLR/LUCENE "ship" with UIMA 2.3.1, I've been using UIMA 2.8.1 for 2+ years by simply dropping in the more up-to-date JAR in the core-specific "lib" directory. I'd have to look through all the lucene stuff again, but, I'm quite certain the lucene support for UIMA is still active as well, no? was (Author: aaronlab): Hi Team, How do we undo this commit/decision? We use UIMA and SOLR +*every day*+ in production, and this decision will effectively freeze us on the last working Solr / UIMA version of 7.4.0. Surely there are other folks out there doing text analytics with even older versions of UIMA and wish to use the latest and greatest solr? > Remove extremely outdated UIMA contrib module > - > > Key: SOLR-11694 > URL: https://issues.apache.org/jira/browse/SOLR-11694 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Reporter: Cassandra Targett >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: 7.5, master (8.0) > > Attachments: SOLR-11694.patch > > > A user on the [solr-user mailing list back in > June|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3CCANsk%2BC_PvZJ38AQ2VfzKRYSQn6c8b33kGvaXxR3qNS3GQ4VUKA%40mail.gmail.com%3E] > brought up the fact that IBM has bought Alchemy and keys are no longer > available to use Solr's UIMA contrib. > Someone recently made a [similar > comment|https://lucene.apache.org/solr/guide/7_1/uima-integration.html#comment_7174] > to the Solr Ref Guide page and asking for a patch. > I know next to nothing about UIMA, but figured it's worth an issue to > determine what to do here. I think folks are saying it's no longer usable? Or > maybe only usable by people who already have keys (which will possibly expire > at some point)? > Anyone have an idea what needs to be done here? It seems we should have some > kind of answer, but if it's no longer usable perhaps we should retire the > contrib. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11694) Remove extremely outdated UIMA contrib module
[ https://issues.apache.org/jira/browse/SOLR-11694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622539#comment-16622539 ] Aaron LaBella commented on SOLR-11694: -- Hi Team, How do we undo this commit/decision? We use UIMA and SOLR +*every day*+ in production, and this decision will effectively freeze us on the last working Solr / UIMA version of 7.4.0. Surely there are other folks out there doing text analytics with even older versions of UIMA and wish to use the latest and greatest solr? > Remove extremely outdated UIMA contrib module > - > > Key: SOLR-11694 > URL: https://issues.apache.org/jira/browse/SOLR-11694 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Reporter: Cassandra Targett >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: 7.5, master (8.0) > > Attachments: SOLR-11694.patch > > > A user on the [solr-user mailing list back in > June|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3CCANsk%2BC_PvZJ38AQ2VfzKRYSQn6c8b33kGvaXxR3qNS3GQ4VUKA%40mail.gmail.com%3E] > brought up the fact that IBM has bought Alchemy and keys are no longer > available to use Solr's UIMA contrib. > Someone recently made a [similar > comment|https://lucene.apache.org/solr/guide/7_1/uima-integration.html#comment_7174] > to the Solr Ref Guide page and asking for a patch. > I know next to nothing about UIMA, but figured it's worth an issue to > determine what to do here. I think folks are saying it's no longer usable? Or > maybe only usable by people who already have keys (which will possibly expire > at some point)? > Anyone have an idea what needs to be done here? It seems we should have some > kind of answer, but if it's no longer usable perhaps we should retire the > contrib. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12789) UIMA enhancements to allow for dynamic AE detection
[ https://issues.apache.org/jira/browse/SOLR-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron LaBella updated SOLR-12789: - Priority: Major (was: Blocker) > UIMA enhancements to allow for dynamic AE detection > --- > > Key: SOLR-12789 > URL: https://issues.apache.org/jira/browse/SOLR-12789 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Affects Versions: 6.0 >Reporter: Aaron LaBella >Priority: Major > Labels: ready-to-commit > Attachments: SOLR-12789-1.patch, SOLR-12789-2.patch, > SOLR-12789-3.patch > > > I've been sitting on this patch for over 2 years (and likewise it's been > running IN production for the same) ... finally got around to contributing it > back to the community. This change prepares the UIMAUpdateRequestProcessor > to allow subclasses to have additional control over how the analysis engine > is selected. In my case, I wrote a sub-class that allows for *dynamic* > detection of the UIMA analysis engine based on the document fields. ie: a > field in the document can be used to select different UIMA configurations and > rules. > > Can someone please commit this as soon as possible. I don't necessarily need > it to be back-ported, having in 7.4.1 would suffice. > Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr add doc with overwrite=false and presence of UpdateLog
Thanks for the context. I'd like to do a few things: * Document that "overwrite" is a (potentially dangerous) peformance hack for documents that are assumed to be already unique. It is not to be used to deliberately violate the uniqueKey constraint; this is considered erroneous and unsupported use. * Document *and enforce* that "overwrite" does not work with the UpdateLog. User error; let them know. While we maintain the UpdateLog, I don't want to have the complexity burden of considering how to support overwrite=true. I'm not saying it's super complex, only that UpdateLog is already complex and I don't think the value of overwrite is good enough for me to want to maintain the two together. I hope others can appreciate this point; I'm don't wish to be difficult. If someone volunteers to make it work in a way that isn't complex then go for it. *It appears it might work today but I wish to break this.* * Consequently, ConvertedLegacyTest needs fixing. If the intent of the legacy test is to see that the document can be added and violate the uniqueKey, then this test needs to use a config without the UpdateLog. Or we keep the default config (with UpdateLog) and adjust the test's expectations. On Thu, Sep 20, 2018 at 1:42 PM Yonik Seeley wrote: > Yep, It's only for performance. I know a number of people using > overwrite=false when doing bulk indexing, and then often later using normal > adds for incremental changes. > > As far as why "overwrite(Pending|Committed)?" exists at all: it's been > there since Solr was open sourced (SOLR-1), so there wouldn't be a > discussion to find. Lucene had no concept of unique IDs or overwriting at > the time and it was all implemented in Solr-land. The cost to enforce was > significant (and still can be today), and often unneeded when building an > index from a source known to have unique IDs already. > > -Yonik > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
[jira] [Commented] (SOLR-12786) Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
[
https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622459#comment-16622459
]
Cassandra Targett commented on SOLR-12786:
--
>From updated issue description:
bq. Short term we can document how to install jekyll-asciidoc with the exact
version needed:
?? I mentioned earlier that I added this already to the README.txt in the
{{solr/solr-ref-guide}} directory, which is where we've declared everything
else required to build the Ref Guide.
> Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
> --
>
> Key: SOLR-12786
> URL: https://issues.apache.org/jira/browse/SOLR-12786
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
>Affects Versions: master (8.0)
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12786.patch
>
>
> Currently the refguide build requires asciidoctor 1.5.6.2.
> People using {{gem install jekyll-asciidoc}} will end up with version 1.5.7,
> causing different header ID syntax and the build will break.
> Long term we should move to latest asciidoctor.
> Short term we can document how to install jekyll-asciidoc with the exact
> version needed:
> {noformat}
> gem install asciidoctor:1.5.6.2 jekyll-asciidoc
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12746) Ref Guide HTML output should adhere to more standard HTML5
[
https://issues.apache.org/jira/browse/SOLR-12746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622419#comment-16622419
]
Cassandra Targett commented on SOLR-12746:
--
There is now a branch for this work, that is getting close to being ready to
merge:
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=tree;h=refs/heads/jira/solr-12746;hb=refs/heads/jira/solr-12746
Some info:
# These changes require us to add a new {{_templates}} directory to direct
Asciidoctor to use different selectors and classes when building the HTML. I
started out with templates from https://github.com/jirutka/asciidoctor-html5s,
but modified them in many ways to change their classnames to the ones we were
already using to simplify the process of fixing our CSS files.
** I have not yet dug into adding license info to Solr for use of these (or if
I even need to since we aren't distributing the templates themselves), but the
project uses the MIT license so it should be fine whatever we end up needing to
do (TODO).
# The Liquid templates used by Jekyll are still there, and have been modified
to use {{}} and {{}} tags instead of divs to identify the
sections of the page that are content vs navigational elements.
# I tried to simplify some of the layers of divs, but there's possibly more
that could be done. For example, for a paragraph there used to be about 6
nested divs, like: {{column > post-content > main-content > sect1 > sectionbody
> paragraph > p}}, but now it's closer to: {{column > content > sect1 > p}}.
# I threw in some other CSS changes for stuff that has been bugging me -
specifically the padding of 2nd level bullets in the in-page TOC, and changing
the 2nd level bullets to use an open circle instead of "-".
Caveats:
# The templates require that you have Slim installed locally in order to build
the HTML. I've added instructions for this to {{solr-ref-guide/README.txt}} in
the branch, but have not updated the Jenkins build script yet (TODO).
# There is an error output by the Slim engine ({{Slim::Engine: Option :asciidoc
is invalid}}) during the HTML build for every template (so, 30+ times). I
suspect it's related to a part of our Jekyll config that we have to have. There
is supposedly some way to declare to Slim that it should ignore this, but I
haven't yet been able to figure it out yet. I also asked about it on the
Asciidoctor mailing list, but have not yet had a reply (TODO).
> Ref Guide HTML output should adhere to more standard HTML5
> --
>
> Key: SOLR-12746
> URL: https://issues.apache.org/jira/browse/SOLR-12746
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
>
> The default HTML produced by Jekyll/Asciidoctor adds a lot of extra {{}}
> tags to the content which break up our content into very small chunks. This
> is acceptable to a casual website reader as far as it goes, but any Reader
> view in a browser or another type of content extraction system that uses a
> similar "readability" scoring algorithm is going to either miss a lot of
> content or fail to display the page entirely.
> To see what I mean, take a page like
> https://lucene.apache.org/solr/guide/7_4/language-analysis.html and enable
> Reader View in your browser (I used Firefox; Steve Rowe told me offline
> Safari would not even offer the option on the page for him). You will notice
> a lot of missing content. It's almost like someone selected sentences at
> random.
> Asciidoctor has a long-standing issue to provide a better more
> semantic-oriented HTML5 output, but it has not been resolved yet:
> https://github.com/asciidoctor/asciidoctor/issues/242
> Asciidoctor does provide a way to override the default output templates by
> providing your own in Slim, HAML, ERB or any other template language
> supported by Tilt (none of which I know yet). There are some samples
> available via the Asciidoctor project which we can borrow, but it's otherwise
> unknown as of yet what parts of the output are causing the worst of the
> problems. This issue is to explore how to fix it to improve this part of the
> HTML reading experience.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr add doc with overwrite=false and presence of UpdateLog
Yep, It's only for performance. I know a number of people using overwrite=false when doing bulk indexing, and then often later using normal adds for incremental changes. As far as why "overwrite(Pending|Committed)?" exists at all: it's been there since Solr was open sourced (SOLR-1), so there wouldn't be a discussion to find. Lucene had no concept of unique IDs or overwriting at the time and it was all implemented in Solr-land. The cost to enforce was significant (and still can be today), and often unneeded when building an index from a source known to have unique IDs already. -Yonik
Re: Solr add doc with overwrite=false and presence of UpdateLog
I'm certainly fine with any of that. It would be good to get some historical perspective and buy-in from say Hoss or Yonik (CC'ed). Do you guys have any opinion on this? The introduction of the overwrite parameter isn't apparent in CHANGES.txt. It seems to be https://issues.apache.org/jira/browse/SOLR-60 assigned to no version; but that issue is more of a refactoring of two other parameters overwriteCommitted & overwritePending. So in summary there doesn't seem to be any historical issues in JIRA with conversation that can help inform why the feature ought to exist. On Tue, Sep 18, 2018 at 8:17 AM Jan Høydahl wrote: > Seems like the overwrite=false flag is purely for better performance > whenever you KNOW that you are indexing docs that have not been indexed > before. So it would be easy to deprecate the feature and let it always be > true if that plays better with updateLog? > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 18. sep. 2018 kl. 14:02 skrev David Smiley : > > Do you mean write new code for adding a feature for _version_ to behave > like overwrite=false? I suppose anything's possible with new code, though > I'm not sure if it fits semantically since the result of overwrite=false is > the possibility of a duplicated document -- something otherwise impossible. > > > I don't really like the very existence of overwrite=false and don't want > us to take on the burdens of supporting it in dubious cases, like having an > updateLog. > > On Tue, Sep 18, 2018 at 5:09 AM Jan Høydahl wrote: > >> Can't the overwrite=false logic be replaced with some logic using the >> _version_ support, which would also support updateLog? I know you can >> provide a specific version in the update and it will not update if the >> index already contains a newer version, but I'm not sure if there is a >> _version_==null kind of feature? >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> >> 18. sep. 2018 kl. 06:20 skrev David Smiley : >> >> Is supported when there is an UpdateLog? Perhaps >> only when you are darned sure the doc is in fact uniuqe? Maybe we should >> throw an exception if you even try at all with an UpdateLog? >> >> Context: I'm working with Moshe, a contributor, on doc updates for >> nested docs. It's all very much WIP with TODOs but nonetheless >> ConvertedLegacyTest failed due to some oddity. It turns out this ancient >> test deliberately adds docs with overwrite=false that already exist by the >> same ID. Youch! This test very much pre-dated the UpdateLog, but at some >> point the UpdateLog ended up in the default config thus this test ended up >> using it. It *appears* to be accidental luck that the test hasn't been >> failing -- i.e. I doubt this situation above was deliberately made to >> work. We're fiddling with some related code and now it fails. >> >> I'm inclined to think the test is broken by virtue of it using a config >> with an UpdateLog -- something it wasn't originally designed for. >> -- >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> http://www.solrenterprisesearchserver.com >> >> >> -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: > http://www.solrenterprisesearchserver.com > > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
[jira] [Commented] (SOLR-12789) UIMA enhancements to allow for dynamic AE detection
[ https://issues.apache.org/jira/browse/SOLR-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622329#comment-16622329 ] Alexandre Rafalovitch commented on SOLR-12789: -- UIMA has been removed as of Solr 7.5, as it was incredible out of date and the UIMA architecture itself has changed significantly. See SOLR-11694. I am not quite sure there is a viable next step for this. Especially, not as a blocker for a version that is no longer supported beyond security fixes. > UIMA enhancements to allow for dynamic AE detection > --- > > Key: SOLR-12789 > URL: https://issues.apache.org/jira/browse/SOLR-12789 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Affects Versions: 6.0 >Reporter: Aaron LaBella >Priority: Blocker > Labels: ready-to-commit > Attachments: SOLR-12789-1.patch, SOLR-12789-2.patch, > SOLR-12789-3.patch > > > I've been sitting on this patch for over 2 years (and likewise it's been > running IN production for the same) ... finally got around to contributing it > back to the community. This change prepares the UIMAUpdateRequestProcessor > to allow subclasses to have additional control over how the analysis engine > is selected. In my case, I wrote a sub-class that allows for *dynamic* > detection of the UIMA analysis engine based on the document fields. ie: a > field in the document can be used to select different UIMA configurations and > rules. > > Can someone please commit this as soon as possible. I don't necessarily need > it to be back-ported, having in 7.4.1 would suffice. > Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12789) UIMA enhancements to allow for dynamic AE detection
[ https://issues.apache.org/jira/browse/SOLR-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron LaBella updated SOLR-12789: - Description: I've been sitting on this patch for over 2 years (and likewise it's been running IN production for the same) ... finally got around to contributing it back to the community. This change prepares the UIMAUpdateRequestProcessor to allow subclasses to have additional control over how the analysis engine is selected. In my case, I wrote a sub-class that allows for *dynamic* detection of the UIMA analysis engine based on the document fields. ie: a field in the document can be used to select different UIMA configurations and rules. Can someone please commit this as soon as possible. I don't necessarily need it to be back-ported, having in 7.4.1 would suffice. Thanks! was: I've been sitting on this patch for over 2 years (and likewise it's been running IN production for the same) ... finally got around to contributing it back to the community. This change prepares the UIMAUpdateRequestProcessor to allow subclasses to have additional control over how the analysis engine is selected. In my case, I wrote a sub-class that allows for *dynamic* detection of the UIMA analysis engine based on the document fields. ie: a field in the document can be used to select different UIMA configurations and rules. Can someone please commit this as soon as possible. Thanks! > UIMA enhancements to allow for dynamic AE detection > --- > > Key: SOLR-12789 > URL: https://issues.apache.org/jira/browse/SOLR-12789 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Affects Versions: 6.0 >Reporter: Aaron LaBella >Priority: Blocker > Labels: ready-to-commit > Attachments: SOLR-12789-1.patch, SOLR-12789-2.patch, > SOLR-12789-3.patch > > > I've been sitting on this patch for over 2 years (and likewise it's been > running IN production for the same) ... finally got around to contributing it > back to the community. This change prepares the UIMAUpdateRequestProcessor > to allow subclasses to have additional control over how the analysis engine > is selected. In my case, I wrote a sub-class that allows for *dynamic* > detection of the UIMA analysis engine based on the document fields. ie: a > field in the document can be used to select different UIMA configurations and > rules. > > Can someone please commit this as soon as possible. I don't necessarily need > it to be back-ported, having in 7.4.1 would suffice. > Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12790) move ServerWrapper logic in LBHttpSolrClient to a method to allow subclasses override. expose other fields as protected
[ https://issues.apache.org/jira/browse/SOLR-12790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron LaBella updated SOLR-12790: - Description: moved ServerWrapper logic in LBHttpSolrClient.request(...) to a method to allow subclasses to override. expose other fields as protected. This allows sub-classes to apply different logic other than round-robin, when using the LBHttpSolrClient class. In my case, we wish to use an algorithm that *only* uses the first / primary server unless it is unavailable, and then it uses the secondary server(s). Can someone please commit this as soon as possible. I don't necessarily need it to be back-ported, having in 7.4.1 would suffice. Thanks! was:moved ServerWrapper logic in LBHttpSolrClient.request(...) to a method to allow subclasses to override. expose other fields as protected. This allows sub-classes to apply different logic other than round-robin, when using the LBHttpSolrClient class. In my case, we wish to use an algorithm that *only* uses the first / primary server unless it is unavailable, and then it uses the secondary server(s). > move ServerWrapper logic in LBHttpSolrClient to a method to allow subclasses > override. expose other fields as protected > > > Key: SOLR-12790 > URL: https://issues.apache.org/jira/browse/SOLR-12790 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 5.0 >Reporter: Aaron LaBella >Priority: Blocker > Labels: ready-to-commit > Attachments: SOLR-12790-1.patch > > > moved ServerWrapper logic in LBHttpSolrClient.request(...) to a method to > allow subclasses to override. expose other fields as protected. This allows > sub-classes to apply different logic other than round-robin, when using the > LBHttpSolrClient class. In my case, we wish to use an algorithm that *only* > uses the first / primary server unless it is unavailable, and then it uses > the secondary server(s). > > Can someone please commit this as soon as possible. I don't necessarily need > it to be back-ported, having in 7.4.1 would suffice. > Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12790) move ServerWrapper logic in LBHttpSolrClient to a method to allow subclasses override. expose other fields as protected
[ https://issues.apache.org/jira/browse/SOLR-12790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron LaBella updated SOLR-12790: - Description: moved ServerWrapper logic in LBHttpSolrClient.request(...) to a method to allow subclasses to override. expose other fields as protected. This allows sub-classes to apply different logic other than round-robin, when using the LBHttpSolrClient class. In my case, we wish to use an algorithm that *only* uses the first / primary server unless it is unavailable, and then it uses the secondary server(s). (was: moved ServerWrapper logic in LBHttpSolrClient.request(...) to a method to allow subclasses override. expose other fields as protected. This allows sub-classes to apply different logic other than round-robin, when using the LBHttpSolrClient class. In my case, we wish to use an algorithm that *only* uses the first / primary server unless it is unavailable, and then it uses the secondary server(s).) > move ServerWrapper logic in LBHttpSolrClient to a method to allow subclasses > override. expose other fields as protected > > > Key: SOLR-12790 > URL: https://issues.apache.org/jira/browse/SOLR-12790 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 5.0 >Reporter: Aaron LaBella >Priority: Blocker > Labels: ready-to-commit > Attachments: SOLR-12790-1.patch > > > moved ServerWrapper logic in LBHttpSolrClient.request(...) to a method to > allow subclasses to override. expose other fields as protected. This allows > sub-classes to apply different logic other than round-robin, when using the > LBHttpSolrClient class. In my case, we wish to use an algorithm that *only* > uses the first / primary server unless it is unavailable, and then it uses > the secondary server(s). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12790) move ServerWrapper logic in LBHttpSolrClient to a method to allow subclasses override. expose other fields as protected
[ https://issues.apache.org/jira/browse/SOLR-12790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron LaBella updated SOLR-12790: - Attachment: SOLR-12790-1.patch > move ServerWrapper logic in LBHttpSolrClient to a method to allow subclasses > override. expose other fields as protected > > > Key: SOLR-12790 > URL: https://issues.apache.org/jira/browse/SOLR-12790 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 5.0 >Reporter: Aaron LaBella >Priority: Blocker > Labels: ready-to-commit > Attachments: SOLR-12790-1.patch > > > moved ServerWrapper logic in LBHttpSolrClient.request(...) to a method to > allow subclasses override. expose other fields as protected. This allows > sub-classes to apply different logic other than round-robin, when using the > LBHttpSolrClient class. In my case, we wish to use an algorithm that *only* > uses the first / primary server unless it is unavailable, and then it uses > the secondary server(s). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12790) move ServerWrapper logic in LBHttpSolrClient to a method to allow subclasses override. expose other fields as protected
Aaron LaBella created SOLR-12790: Summary: move ServerWrapper logic in LBHttpSolrClient to a method to allow subclasses override. expose other fields as protected Key: SOLR-12790 URL: https://issues.apache.org/jira/browse/SOLR-12790 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: SolrJ Affects Versions: 5.0 Reporter: Aaron LaBella Attachments: SOLR-12790-1.patch moved ServerWrapper logic in LBHttpSolrClient.request(...) to a method to allow subclasses override. expose other fields as protected. This allows sub-classes to apply different logic other than round-robin, when using the LBHttpSolrClient class. In my case, we wish to use an algorithm that *only* uses the first / primary server unless it is unavailable, and then it uses the secondary server(s). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12789) UIMA enhancements to allow for dynamic AE detection
[ https://issues.apache.org/jira/browse/SOLR-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron LaBella updated SOLR-12789: - Description: I've been sitting on this patch for over 2 years (and likewise it's been running IN production for the same) ... finally got around to contributing it back to the community. This change prepares the UIMAUpdateRequestProcessor to allow subclasses to have additional control over how the analysis engine is selected. In my case, I wrote a sub-class that allows for *dynamic* detection of the UIMA analysis engine based on the document fields. ie: a field in the document can be used to select different UIMA configurations and rules. Can someone please commit this as soon as possible. Thanks! was: I've been sitting on this patch for 2 years (and likewise it's been running production for the same) ... finally got around to contributing it back to the community. This change prepares the UIMAUpdateRequestProcessor to allow subclasses to have additional control over hhow the analysis engine is selected. In my case, I wrote a sub-class that allows for *dynamic* detection of the UIMA analysis engine based on the document fields. ie: a field in the document can be used to select different UIMA configurations and rules. Can someone please commit this as soon as possible. Thanks! > UIMA enhancements to allow for dynamic AE detection > --- > > Key: SOLR-12789 > URL: https://issues.apache.org/jira/browse/SOLR-12789 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Affects Versions: 6.0 >Reporter: Aaron LaBella >Priority: Blocker > Labels: ready-to-commit > Attachments: SOLR-12789-1.patch, SOLR-12789-2.patch, > SOLR-12789-3.patch > > > I've been sitting on this patch for over 2 years (and likewise it's been > running IN production for the same) ... finally got around to contributing it > back to the community. This change prepares the UIMAUpdateRequestProcessor > to allow subclasses to have additional control over how the analysis engine > is selected. In my case, I wrote a sub-class that allows for *dynamic* > detection of the UIMA analysis engine based on the document fields. ie: a > field in the document can be used to select different UIMA configurations and > rules. > > Can someone please commit this as soon as possible. > Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12789) UIMA enhancements to allow for dynamic AE detection
[ https://issues.apache.org/jira/browse/SOLR-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622309#comment-16622309 ] Aaron LaBella commented on SOLR-12789: -- There is also a patch in here to add proper support for UIMA feature values which are arrays to map to multivalued fields > UIMA enhancements to allow for dynamic AE detection > --- > > Key: SOLR-12789 > URL: https://issues.apache.org/jira/browse/SOLR-12789 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Affects Versions: 6.0 >Reporter: Aaron LaBella >Priority: Blocker > Labels: ready-to-commit > Attachments: SOLR-12789-1.patch, SOLR-12789-2.patch, > SOLR-12789-3.patch > > > I've been sitting on this patch for 2 years (and likewise it's been running > production for the same) ... finally got around to contributing it back to > the community. This change prepares the UIMAUpdateRequestProcessor to allow > subclasses to have additional control over hhow the analysis engine is > selected. In my case, I wrote a sub-class that allows for *dynamic* > detection of the UIMA analysis engine based on the document fields. ie: a > field in the document can be used to select different UIMA configurations and > rules. > > Can someone please commit this as soon as possible. > Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 1507 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/1507/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/158/consoleText [repro] Revision: 10060a6237ccd2785f6cbe248ca7254028f8eb04 [repro] Repro line: ant test -Dtestcase=TestSimComputePlanAction -Dtests.method=testNodeAdded -Dtests.seed=3A25CF0747D0739C -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=no-NO -Dtests.timezone=America/Cambridge_Bay -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: d7e97fb7f84d8613683a080610f177b7cae2b31a [repro] git fetch [repro] git checkout 10060a6237ccd2785f6cbe248ca7254028f8eb04 [...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] TestSimComputePlanAction [repro] ant compile-test [...truncated 3424 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestSimComputePlanAction" -Dtests.showOutput=onerror -Dtests.seed=3A25CF0747D0739C -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=no-NO -Dtests.timezone=America/Cambridge_Bay -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 1348 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 1/5 failed: org.apache.solr.cloud.autoscaling.sim.TestSimComputePlanAction [repro] git checkout d7e97fb7f84d8613683a080610f177b7cae2b31a [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12789) UIMA enhancements to allow for dynamic AE detection
[ https://issues.apache.org/jira/browse/SOLR-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron LaBella updated SOLR-12789: - Attachment: SOLR-12789-3.patch > UIMA enhancements to allow for dynamic AE detection > --- > > Key: SOLR-12789 > URL: https://issues.apache.org/jira/browse/SOLR-12789 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Affects Versions: 6.0 >Reporter: Aaron LaBella >Priority: Blocker > Labels: ready-to-commit > Attachments: SOLR-12789-1.patch, SOLR-12789-2.patch, > SOLR-12789-3.patch > > > I've been sitting on this patch for 2 years (and likewise it's been running > production for the same) ... finally got around to contributing it back to > the community. This change prepares the UIMAUpdateRequestProcessor to allow > subclasses to have additional control over hhow the analysis engine is > selected. In my case, I wrote a sub-class that allows for *dynamic* > detection of the UIMA analysis engine based on the document fields. ie: a > field in the document can be used to select different UIMA configurations and > rules. > > Can someone please commit this as soon as possible. > Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12789) UIMA enhancements to allow for dynamic AE detection
[ https://issues.apache.org/jira/browse/SOLR-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron LaBella updated SOLR-12789: - Attachment: SOLR-12789-1.patch > UIMA enhancements to allow for dynamic AE detection > --- > > Key: SOLR-12789 > URL: https://issues.apache.org/jira/browse/SOLR-12789 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Affects Versions: 6.0 >Reporter: Aaron LaBella >Priority: Blocker > Labels: ready-to-commit > Attachments: SOLR-12789-1.patch, SOLR-12789-2.patch, > SOLR-12789-3.patch > > > I've been sitting on this patch for 2 years (and likewise it's been running > production for the same) ... finally got around to contributing it back to > the community. This change prepares the UIMAUpdateRequestProcessor to allow > subclasses to have additional control over hhow the analysis engine is > selected. In my case, I wrote a sub-class that allows for *dynamic* > detection of the UIMA analysis engine based on the document fields. ie: a > field in the document can be used to select different UIMA configurations and > rules. > > Can someone please commit this as soon as possible. > Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12789) UIMA enhancements to allow for dynamic AE detection
[ https://issues.apache.org/jira/browse/SOLR-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron LaBella updated SOLR-12789: - Attachment: SOLR-12789-2.patch > UIMA enhancements to allow for dynamic AE detection > --- > > Key: SOLR-12789 > URL: https://issues.apache.org/jira/browse/SOLR-12789 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Affects Versions: 6.0 >Reporter: Aaron LaBella >Priority: Blocker > Labels: ready-to-commit > Attachments: SOLR-12789-1.patch, SOLR-12789-2.patch, > SOLR-12789-3.patch > > > I've been sitting on this patch for 2 years (and likewise it's been running > production for the same) ... finally got around to contributing it back to > the community. This change prepares the UIMAUpdateRequestProcessor to allow > subclasses to have additional control over hhow the analysis engine is > selected. In my case, I wrote a sub-class that allows for *dynamic* > detection of the UIMA analysis engine based on the document fields. ie: a > field in the document can be used to select different UIMA configurations and > rules. > > Can someone please commit this as soon as possible. > Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12789) UIMA enhancements to allow for dynamic AE detection
Aaron LaBella created SOLR-12789: Summary: UIMA enhancements to allow for dynamic AE detection Key: SOLR-12789 URL: https://issues.apache.org/jira/browse/SOLR-12789 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: contrib - UIMA Affects Versions: 6.0 Reporter: Aaron LaBella I've been sitting on this patch for 2 years (and likewise it's been running production for the same) ... finally got around to contributing it back to the community. This change prepares the UIMAUpdateRequestProcessor to allow subclasses to have additional control over hhow the analysis engine is selected. In my case, I wrote a sub-class that allows for *dynamic* detection of the UIMA analysis engine based on the document fields. ie: a field in the document can be used to select different UIMA configurations and rules. Can someone please commit this as soon as possible. Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-7.x - Build # 891 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/891/
2 tests failed.
FAILED: org.apache.solr.cloud.AddReplicaTest.test
Error Message:
core_node6:{"core":"addreplicatest_coll_shard1_replica_n5","base_url":"https://127.0.0.1:42262/solr","node_name":"127.0.0.1:42262_solr","state":"active","type":"NRT","force_set_state":"false"}
Stack Trace:
java.lang.AssertionError:
core_node6:{"core":"addreplicatest_coll_shard1_replica_n5","base_url":"https://127.0.0.1:42262/solr","node_name":"127.0.0.1:42262_solr","state":"active","type":"NRT","force_set_state":"false"}
at
__randomizedtesting.SeedInfo.seed([AB0D1D86CC5B:2359225C62ED7CA3]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.apache.solr.cloud.AddReplicaTest.test(AddReplicaTest.java:85)
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:1742)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
FAILED:
[jira] [Commented] (SOLR-11763) Upgrade Guava to 23.0
[ https://issues.apache.org/jira/browse/SOLR-11763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622269#comment-16622269 ] Kevin Risden commented on SOLR-11763: - Sadly even upgrading to Hadoop 3.x won't help (yet). HADOOP-10101 was committed and then reverted. HADOOP-15272 is the new Jira to upgrade Guava in Hadoop. It is currently targeting Hadoop 3.2.0. > Upgrade Guava to 23.0 > - > > Key: SOLR-11763 > URL: https://issues.apache.org/jira/browse/SOLR-11763 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Markus Jelsma >Assignee: Varun Thacker >Priority: Minor > Attachments: SOLR-11763.patch, SOLR-11763.patch, SOLR-11763.patch > > > Our code is running into version conflicts with Solr's old Guava dependency. > This fixes it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11759) DocExpirationUpdateProcessorFactory causes unauthenticated inter-node requests
[
https://issues.apache.org/jira/browse/SOLR-11759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622267#comment-16622267
]
Jan Høydahl commented on SOLR-11759:
Is this still an issue?
> DocExpirationUpdateProcessorFactory causes unauthenticated inter-node requests
> --
>
> Key: SOLR-11759
> URL: https://issues.apache.org/jira/browse/SOLR-11759
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
> Environment: solr 6.6.0
> jre1.8.0_101
> Ubuntu 14.04
> SolrCloud with zookeeper 3.4.5
>Reporter: Nils Cant
>Priority: Major
>
> When configuring a collection with a DocExpirationUpdateProcessorFactory,
> this causes inter-node calls to no longer authenticate.
> config extract from solrconfig.xml:
> {code:xml}
>
> 60
>
> expiration
>
> {code}
> solr.log exception:
> {code}
> 2017-12-13 17:07:07.328 WARN (autoExpireDocs-22-thread-1) [c:anpr-search
> s:shard1 r:core_node1 x:anpr-search_shard1_replica1]
> o.a.s.u.p.DistributedUpdateProcessor Error sending update to
> http://X.X.X.242:8983/s
> olr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://X.X.X.242:8983/solr/anpr-search_shard1_replica1:
> Expected mime type application/octet-stream but got text/html. <
> html>
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/anpr-search_shard1_replica1/update. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:578)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient.request(ConcurrentUpdateSolrClient.java:430)
> at
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.update.SolrCmdDistributor.doRequest(SolrCmdDistributor.java:299)
> at
> org.apache.solr.update.SolrCmdDistributor.lambda$submit$0(SolrCmdDistributor.java:288)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> 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:745)
> {code}
> The following screenshots show how another collection (vervoermiddelen)
> properly sends the SolrAuth header, while the anrp-search collection doesn't:
> https://imgur.com/a/kJ4Ut
> This causes replica shards to become (and stay) down.
> If I remove the DocExpirationUpdateProcessorFactory configuration from
> solrconfig.xml, the problem doesn't occur.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12788) RecoveryStrategy throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/SOLR-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated SOLR-12788:
-
Description:
I spotted this when trying to reproduce a test failure:
{code}
[junit4] 2> 32176 ERROR
(recoveryExecutor-132-thread-1-processing-n:127.0.0.1:53696_i
x:collection1_shard4_replica_n93 c:collection1 s:shard4 r:core_node94)
[n:127.0.0.1:53696_i c:collection1 s:shard4 r:core_node94
x:collection1_shard4_replica_n93] o.a.s.c.RecoveryStrategy Error getting recent
versions.:java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
[junit4] 2>at java.util.ArrayList.rangeCheck(ArrayList.java:653)
[junit4] 2>at java.util.ArrayList.get(ArrayList.java:429)
[junit4] 2>at
org.apache.solr.cloud.RecoveryStrategy.doSyncOrReplicateRecovery(RecoveryStrategy.java:491)
[junit4] 2>at
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:310)
[junit4] 2>at
org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:294)
[junit4] 2>at
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
[junit4] 2>at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[junit4] 2>at
java.util.concurrent.FutureTask.run(FutureTask.java:266)
[junit4] 2>at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
[junit4] 2>at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[junit4] 2>at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[junit4] 2>at java.lang.Thread.run(Thread.java:745)
{code}
This reproduces consistently with the following command:
{code}
ant test -Dtestcase=ShardRoutingTest -Dtests.method=test
-Dtests.seed=FF7B7D65A8936A3D -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=ar-BH -Dtests.timezone=Indian/Mahe -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
{code}
was:
I spotted this when trying to reproduce a test failure:
{code}
[junit4] 2> 32176 ERROR
(recoveryExecutor-132-thread-1-processing-n:127.0.0.1:53696_i
x:collection1_shard4_replica_n93 c:collection1 s:shard4 r:core_node94)
[n:127.0.0.1:53696_i c:collection1 s:shard4 r:core_node94
x:collection1_shard4_replica_n93] o.a.s.c.RecoveryStrategy Error getting recent
versions.:java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
[junit4] 2>at java.util.ArrayList.rangeCheck(ArrayList.java:653)
[junit4] 2>at java.util.ArrayList.get(ArrayList.java:429)
[junit4] 2>at
org.apache.solr.cloud.RecoveryStrategy.doSyncOrReplicateRecovery(RecoveryStrategy.java:491)
[junit4] 2>at
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:310)
[junit4] 2>at
org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:294)
[junit4] 2>at
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
[junit4] 2>at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[junit4] 2>at
java.util.concurrent.FutureTask.run(FutureTask.java:266)
[junit4] 2>at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
[junit4] 2>at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[junit4] 2>at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[junit4] 2>at java.lang.Thread.run(Thread.java:745)
{code}
This is reproduces consistently with the following command:
{code}
ant test -Dtestcase=ShardRoutingTest -Dtests.method=test
-Dtests.seed=FF7B7D65A8936A3D -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=ar-BH -Dtests.timezone=Indian/Mahe -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
{code}
> RecoveryStrategy throws IndexOutOfBoundsException
> -
>
> Key: SOLR-12788
> URL: https://issues.apache.org/jira/browse/SOLR-12788
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (8.0)
>Reporter: Andrzej Bialecki
>Priority: Major
>
> I spotted this when trying to reproduce a test failure:
> {code}
>[junit4] 2> 32176 ERROR
> (recoveryExecutor-132-thread-1-processing-n:127.0.0.1:53696_i
> x:collection1_shard4_replica_n93 c:collection1 s:shard4 r:core_node94)
> [n:127.0.0.1:53696_i c:collection1 s:shard4 r:core_node94
> x:collection1_shard4_replica_n93] o.a.s.c.RecoveryStrategy Error getting
> recent
[jira] [Created] (SOLR-12788) RecoveryStrategy throws IndexOutOfBoundsException
Andrzej Bialecki created SOLR-12788:
Summary: RecoveryStrategy throws IndexOutOfBoundsException
Key: SOLR-12788
URL: https://issues.apache.org/jira/browse/SOLR-12788
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: master (8.0)
Reporter: Andrzej Bialecki
I spotted this when trying to reproduce a test failure:
{code}
[junit4] 2> 32176 ERROR
(recoveryExecutor-132-thread-1-processing-n:127.0.0.1:53696_i
x:collection1_shard4_replica_n93 c:collection1 s:shard4 r:core_node94)
[n:127.0.0.1:53696_i c:collection1 s:shard4 r:core_node94
x:collection1_shard4_replica_n93] o.a.s.c.RecoveryStrategy Error getting recent
versions.:java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
[junit4] 2>at java.util.ArrayList.rangeCheck(ArrayList.java:653)
[junit4] 2>at java.util.ArrayList.get(ArrayList.java:429)
[junit4] 2>at
org.apache.solr.cloud.RecoveryStrategy.doSyncOrReplicateRecovery(RecoveryStrategy.java:491)
[junit4] 2>at
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:310)
[junit4] 2>at
org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:294)
[junit4] 2>at
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
[junit4] 2>at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[junit4] 2>at
java.util.concurrent.FutureTask.run(FutureTask.java:266)
[junit4] 2>at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
[junit4] 2>at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[junit4] 2>at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[junit4] 2>at java.lang.Thread.run(Thread.java:745)
{code}
This is reproduces consistently with the following command:
{code}
ant test -Dtestcase=ShardRoutingTest -Dtests.method=test
-Dtests.seed=FF7B7D65A8936A3D -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=ar-BH -Dtests.timezone=Indian/Mahe -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8454) Polygon tessellator can get into an infinite loop
[
https://issues.apache.org/jira/browse/LUCENE-8454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622245#comment-16622245
]
ASF subversion and git services commented on LUCENE-8454:
-
Commit 60e8ee717d9cd8d2425c100c21168d6a43b78516 in lucene-solr's branch
refs/heads/branch_7_5 from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=60e8ee7 ]
LUCENE-8454: Fix tessellator to use original polygon vertices.
> Polygon tessellator can get into an infinite loop
> -
>
> Key: LUCENE-8454
> URL: https://issues.apache.org/jira/browse/LUCENE-8454
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8454.patch
>
>
> I was trying to index some shapes using {{LatLonshape}} and for some complex
> shapes, there teselletor goes into an infinite loop. I am providing a test
> showing the problem.
>
> [~nknize], you might be interested on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8454) Polygon tessellator can get into an infinite loop
[
https://issues.apache.org/jira/browse/LUCENE-8454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622234#comment-16622234
]
ASF subversion and git services commented on LUCENE-8454:
-
Commit 0c7543387572eff9a52e733d03f8d95e352be0f8 in lucene-solr's branch
refs/heads/branch_7x from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0c75433 ]
LUCENE-8454: Fix tessellator to use original polygon vertices.
> Polygon tessellator can get into an infinite loop
> -
>
> Key: LUCENE-8454
> URL: https://issues.apache.org/jira/browse/LUCENE-8454
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8454.patch
>
>
> I was trying to index some shapes using {{LatLonshape}} and for some complex
> shapes, there teselletor goes into an infinite loop. I am providing a test
> showing the problem.
>
> [~nknize], you might be interested on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8454) Polygon tessellator can get into an infinite loop
[
https://issues.apache.org/jira/browse/LUCENE-8454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622230#comment-16622230
]
ASF subversion and git services commented on LUCENE-8454:
-
Commit d7e97fb7f84d8613683a080610f177b7cae2b31a in lucene-solr's branch
refs/heads/master from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d7e97fb ]
LUCENE-8454: Fix tessellator to use original polygon vertices.
> Polygon tessellator can get into an infinite loop
> -
>
> Key: LUCENE-8454
> URL: https://issues.apache.org/jira/browse/LUCENE-8454
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8454.patch
>
>
> I was trying to index some shapes using {{LatLonshape}} and for some complex
> shapes, there teselletor goes into an infinite loop. I am providing a test
> showing the problem.
>
> [~nknize], you might be interested on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: Release Solr Reference Guide for 7.5
+1 On Tue, Sep 18, 2018 at 12:32 PM Cassandra Targett wrote: > Please vote to release the Solr Ref Guide for 7.5. > > The PDF artifacts can be downloaded from: > https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-7.5-RC1/ > > $ cat apache-solr-ref-guide-7.5.pdf.sha512 > b41d527e7f8aa92783fccad513c1de2182894045ab89df0cdc03250a4126447463433896851a4cbe09116009182d6ac21b28c9aaa2b075a5fa68f81b9d4c0759 > apache-solr-ref-guide-7.5.pdf > > The PDF for this release is up to 1389 pages (and 16Mb). > > The HTML version is available at: > https://lucene.apache.org/solr/guide/7_5/ > > Here's my +1. > > Cassandra >
[jira] [Updated] (SOLR-12786) Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
[
https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-12786:
---
Description:
Currently the refguide build requires asciidoctor 1.5.6.2.
People using {{gem install jekyll-asciidoc}} will end up with version 1.5.7,
causing different header ID syntax and the build will break.
Long term we should move to latest asciidoctor.
Short term we can document how to install jekyll-asciidoc with the exact
version needed:
{noformat}
gem install asciidoctor:1.5.6.2 jekyll-asciidoc
{noformat}
was:
The refguide build aborts due to this.
Example: "updating-solr-s-include-files" should instead be
"updating-solrs-include-files" since apostrophe is not replaced with dash.
> Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
> --
>
> Key: SOLR-12786
> URL: https://issues.apache.org/jira/browse/SOLR-12786
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
>Affects Versions: master (8.0)
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12786.patch
>
>
> Currently the refguide build requires asciidoctor 1.5.6.2.
> People using {{gem install jekyll-asciidoc}} will end up with version 1.5.7,
> causing different header ID syntax and the build will break.
> Long term we should move to latest asciidoctor.
> Short term we can document how to install jekyll-asciidoc with the exact
> version needed:
> {noformat}
> gem install asciidoctor:1.5.6.2 jekyll-asciidoc
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12786) Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
[
https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-12786:
--
Assignee: (was: Jan Høydahl)
> Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
> --
>
> Key: SOLR-12786
> URL: https://issues.apache.org/jira/browse/SOLR-12786
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
>Affects Versions: master (8.0)
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12786.patch
>
>
> Currently the refguide build requires asciidoctor 1.5.6.2.
> People using {{gem install jekyll-asciidoc}} will end up with version 1.5.7,
> causing different header ID syntax and the build will break.
> Long term we should move to latest asciidoctor.
> Short term we can document how to install jekyll-asciidoc with the exact
> version needed:
> {noformat}
> gem install asciidoctor:1.5.6.2 jekyll-asciidoc
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12786) Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
[ https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-12786: --- Summary: Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure (was: HTML reference guide has invalid links) > Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure > -- > > Key: SOLR-12786 > URL: https://issues.apache.org/jira/browse/SOLR-12786 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Build, documentation >Affects Versions: master (8.0) >Reporter: Jan Høydahl >Priority: Major > Attachments: SOLR-12786.patch > > > The refguide build aborts due to this. > Example: "updating-solr-s-include-files" should instead be > "updating-solrs-include-files" since apostrophe is not replaced with dash. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12786) Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
[ https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-12786: --- Component/s: Build > Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure > -- > > Key: SOLR-12786 > URL: https://issues.apache.org/jira/browse/SOLR-12786 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Build, documentation >Affects Versions: master (8.0) >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: SOLR-12786.patch > > > The refguide build aborts due to this. > Example: "updating-solr-s-include-files" should instead be > "updating-solrs-include-files" since apostrophe is not replaced with dash. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12786) Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure
[ https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-12786: -- Assignee: Jan Høydahl > Upgrade refGuide build to Asciidoctor 1.5.7 and new link structure > -- > > Key: SOLR-12786 > URL: https://issues.apache.org/jira/browse/SOLR-12786 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Build, documentation >Affects Versions: master (8.0) >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: SOLR-12786.patch > > > The refguide build aborts due to this. > Example: "updating-solr-s-include-files" should instead be > "updating-solrs-include-files" since apostrophe is not replaced with dash. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12786) HTML reference guide has invalid links
[
https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622143#comment-16622143
]
Cassandra Targett edited comment on SOLR-12786 at 9/20/18 2:36 PM:
---
Yes, we need to move up at some point. Ideas on how to enforce/check for the
Asciidoctor version are welcome.
>From the discuss.asciidoctor.org thread I pointed to, the 2nd variation of the
>problem is the one that will cause us some ongoing issues - if you look at a
>page like {{format-of-solr.adoc}}, the change makes it somewhat non-intuitive
>on how links are constructed. AFIAK, the only way to force a link format is to
>manually put anchors on every section, which I strive to avoid because it
>complicates making correct links in other ways.
Overall, I'm sorry about this; I thought I'd filed an issue about the version
requirement, but see from the commit I did not. That time period in May was
very hectic for me, so after spending a couple hours figuring out what was
wrong and then deciding what to do about it, I probably then had to move on to
something else and subsequently forgot about filing an issue.
was (Author: ctargett):
Yes, we need to move up at some point. Ideas on how to enforce/check for the
Asciidoctor version are welcome.
>From the discuss.asciidoctor.org thread I pointed to, the 2nd variation of the
>problem is the one that will cause us some ongoing issues - if you look at a
>page like {{format-of-solr.html}}, the change makes it somewhat non-intuitive
>on how links are constructed. AFIAK, the only way to force a link format is to
>manually put anchors on every section, which I strive to avoid because it
>complicates making correct links in other ways.
Overall, I'm sorry about this; I thought I'd filed an issue about the version
requirement, but see from the commit I did not. That time period in May was
very hectic for me, so after spending a couple hours figuring out what was
wrong and then deciding what to do about it, I probably then had to move on to
something else and subsequently forgot about filing an issue.
> HTML reference guide has invalid links
> --
>
> Key: SOLR-12786
> URL: https://issues.apache.org/jira/browse/SOLR-12786
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12786.patch
>
>
> The refguide build aborts due to this.
> Example: "updating-solr-s-include-files" should instead be
> "updating-solrs-include-files" since apostrophe is not replaced with dash.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12786) HTML reference guide has invalid links
[
https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622143#comment-16622143
]
Cassandra Targett commented on SOLR-12786:
--
Yes, we need to move up at some point. Ideas on how to enforce/check for the
Asciidoctor version are welcome.
>From the discuss.asciidoctor.org thread I pointed to, the 2nd variation of the
>problem is the one that will cause us some ongoing issues - if you look at a
>page like {{format-of-solr.html}}, the change makes it somewhat non-intuitive
>on how links are constructed. AFIAK, the only way to force a link format is to
>manually put anchors on every section, which I strive to avoid because it
>complicates making correct links in other ways.
Overall, I'm sorry about this; I thought I'd filed an issue about the version
requirement, but see from the commit I did not. That time period in May was
very hectic for me, so after spending a couple hours figuring out what was
wrong and then deciding what to do about it, I probably then had to move on to
something else and subsequently forgot about filing an issue.
> HTML reference guide has invalid links
> --
>
> Key: SOLR-12786
> URL: https://issues.apache.org/jira/browse/SOLR-12786
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12786.patch
>
>
> The refguide build aborts due to this.
> Example: "updating-solr-s-include-files" should instead be
> "updating-solrs-include-files" since apostrophe is not replaced with dash.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12786) HTML reference guide has invalid links
[
https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622124#comment-16622124
]
Jan Høydahl commented on SOLR-12786:
Yep, you're right. I'm on {{Asciidoctor 1.5.7.1}}. I tried to find that version
requirement, but could not.
Is there no way to configure the rules for translating headers to ID's either?
Anyway - I won't commit this now. But perhaps we can consider to standardise on
the new version at some point?
> HTML reference guide has invalid links
> --
>
> Key: SOLR-12786
> URL: https://issues.apache.org/jira/browse/SOLR-12786
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12786.patch
>
>
> The refguide build aborts due to this.
> Example: "updating-solr-s-include-files" should instead be
> "updating-solrs-include-files" since apostrophe is not replaced with dash.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10.0.1) - Build # 2777 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2777/ Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir Error Message: Captured an uncaught exception in thread: Thread[id=12320, name=cdcr-replicator-4989-thread-1, state=RUNNABLE, group=TGRP-CdcrBidirectionalTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=12320, name=cdcr-replicator-4989-thread-1, state=RUNNABLE, group=TGRP-CdcrBidirectionalTest] Caused by: java.lang.AssertionError: 1612133817950142464 != 1612133817540149248 at __randomizedtesting.SeedInfo.seed([4931982D2F4E5A76]:0) at org.apache.solr.update.CdcrUpdateLog$CdcrLogReader.forwardSeek(CdcrUpdateLog.java:611) at org.apache.solr.handler.CdcrReplicator.run(CdcrReplicator.java:125) at org.apache.solr.handler.CdcrReplicatorScheduler.lambda$start$0(CdcrReplicatorScheduler.java:81) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:844) Build Log: [...truncated 1913 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/core/test/temp/junit4-J2-20180920_125758_45216958027656647622516.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 5 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/core/test/temp/junit4-J1-20180920_125758_4528420855454516004481.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 5 lines...] [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/core/test/temp/junit4-J0-20180920_125758_4535416961615406161810.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 304 lines...] [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J0-20180920_130409_7713336906356271666262.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J2-20180920_130409_77118288147481375209877.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J1-20180920_130409_77110201490783842745807.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 1083 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J2-20180920_130517_87115308976112704082345.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J2: EOF [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J0-20180920_130517_8714140060011897283465.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0
[jira] [Commented] (SOLR-12786) HTML reference guide has invalid links
[
https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622115#comment-16622115
]
Cassandra Targett commented on SOLR-12786:
--
Before you commit this, can you please tell me the version of Asciidoctor that
you are using? This looks very similar to a problem I saw using Asciidoctor
1.5.7 and higher, which changed the way section IDs are created automatically.
In May I changed the {{solr-ref-guide/REAMDE.txt}} to provide instructions to
force the installation of Asciidoctor 1.5.6.2 instead of 1.5.7. The latter
version will be installed by default if you only install the
{{jekyll-asciidoctor}} gem. (See
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=7bb3e5c2482c7b73ed2dd26ff4be4613e7f44872)
The problem with this patch is that _everyone_ will need to be on v1.5.7 after
these changes in your patch. Anyone with an earlier Asciidoctor version will
get errors because the way the section IDs are created will be incorrect for
them. We have no way to enforce this version with build scripts, so I thought
it was simpler to stay on an earlier version for the time being.
> HTML reference guide has invalid links
> --
>
> Key: SOLR-12786
> URL: https://issues.apache.org/jira/browse/SOLR-12786
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12786.patch
>
>
> The refguide build aborts due to this.
> Example: "updating-solr-s-include-files" should instead be
> "updating-solrs-include-files" since apostrophe is not replaced with dash.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12786) HTML reference guide has invalid links
[
https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622115#comment-16622115
]
Cassandra Targett edited comment on SOLR-12786 at 9/20/18 2:16 PM:
---
Before you commit this, can you please tell me the version of Asciidoctor that
you are using? This looks very similar to a problem I saw using Asciidoctor
1.5.7 and higher, which changed the way section IDs are created automatically.
In May I changed the {{solr-ref-guide/REAMDE.txt}} to provide instructions to
force the installation of Asciidoctor 1.5.6.2 instead of 1.5.7. The latter
version will be installed by default if you only install the
{{jekyll-asciidoctor}} gem. (See
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=7bb3e5c2482c7b73ed2dd26ff4be4613e7f44872)
The problem with this patch is that _everyone_ will need to be on v1.5.7 after
these changes in your patch. Anyone with an earlier Asciidoctor version will
get errors because the way the section IDs are created will be incorrect for
them. We have no way to enforce this version with build scripts, so I thought
it was simpler to stay on an earlier version for the time being.
See also this discussion with the Asciidoctor team:
http://discuss.asciidoctor.org/Force-Asciidoctor-version-when-installed-as-a-jekyll-asciidoc-dependency-td6338.html
was (Author: ctargett):
Before you commit this, can you please tell me the version of Asciidoctor that
you are using? This looks very similar to a problem I saw using Asciidoctor
1.5.7 and higher, which changed the way section IDs are created automatically.
In May I changed the {{solr-ref-guide/REAMDE.txt}} to provide instructions to
force the installation of Asciidoctor 1.5.6.2 instead of 1.5.7. The latter
version will be installed by default if you only install the
{{jekyll-asciidoctor}} gem. (See
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=7bb3e5c2482c7b73ed2dd26ff4be4613e7f44872)
The problem with this patch is that _everyone_ will need to be on v1.5.7 after
these changes in your patch. Anyone with an earlier Asciidoctor version will
get errors because the way the section IDs are created will be incorrect for
them. We have no way to enforce this version with build scripts, so I thought
it was simpler to stay on an earlier version for the time being.
> HTML reference guide has invalid links
> --
>
> Key: SOLR-12786
> URL: https://issues.apache.org/jira/browse/SOLR-12786
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12786.patch
>
>
> The refguide build aborts due to this.
> Example: "updating-solr-s-include-files" should instead be
> "updating-solrs-include-files" since apostrophe is not replaced with dash.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8511) MultiFields.getIndexedFields can be optimized to not use getMergedFieldInfos
[ https://issues.apache.org/jira/browse/LUCENE-8511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622107#comment-16622107 ] Adrien Grand commented on LUCENE-8511: -- +1 > MultiFields.getIndexedFields can be optimized to not use getMergedFieldInfos > > > Key: LUCENE-8511 > URL: https://issues.apache.org/jira/browse/LUCENE-8511 > Project: Lucene - Core > Issue Type: Improvement >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE-8511.patch, LUCENE-8511.patch > > > MultiFields.getIndexedFields calls getMergedFieldInfos. But > getMergedFieldInfos is kinda heavy, doing all sorts of stuff that > getIndexedFields doesn't care about. It can simply loop the leaf readers and > collect the results into a Set. Java 8 streams should make easy work of this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8511) MultiFields.getIndexedFields can be optimized to not use getMergedFieldInfos
[ https://issues.apache.org/jira/browse/LUCENE-8511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-8511: - Attachment: LUCENE-8511.patch > MultiFields.getIndexedFields can be optimized to not use getMergedFieldInfos > > > Key: LUCENE-8511 > URL: https://issues.apache.org/jira/browse/LUCENE-8511 > Project: Lucene - Core > Issue Type: Improvement >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE-8511.patch, LUCENE-8511.patch > > > MultiFields.getIndexedFields calls getMergedFieldInfos. But > getMergedFieldInfos is kinda heavy, doing all sorts of stuff that > getIndexedFields doesn't care about. It can simply loop the leaf readers and > collect the results into a Set. Java 8 streams should make easy work of this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8511) MultiFields.getIndexedFields can be optimized to not use getMergedFieldInfos
[ https://issues.apache.org/jira/browse/LUCENE-8511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622098#comment-16622098 ] David Smiley commented on LUCENE-8511: -- I didn't find it to be a bottleneck. I'm trying to reduce the need to merge FieldInfos in general when it's not needed. It's not needed here. I'll put the ops on new lines; sure. getMergedFieldInfos's use of streams could be broken up more too; it's ".findAny" should be on a new line > MultiFields.getIndexedFields can be optimized to not use getMergedFieldInfos > > > Key: LUCENE-8511 > URL: https://issues.apache.org/jira/browse/LUCENE-8511 > Project: Lucene - Core > Issue Type: Improvement >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE-8511.patch > > > MultiFields.getIndexedFields calls getMergedFieldInfos. But > getMergedFieldInfos is kinda heavy, doing all sorts of stuff that > getIndexedFields doesn't care about. It can simply loop the leaf readers and > collect the results into a Set. Java 8 streams should make easy work of this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12782) UninvertingReader can be avoided if there are no fields to uninvert
[
https://issues.apache.org/jira/browse/SOLR-12782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622060#comment-16622060
]
David Smiley commented on SOLR-12782:
-
Ah; Yetus reminds me I should perhaps write a test. I guess I could write a
test that a FieldInfo is reused if it doesn't change. FWIW the patch will soon
be evaluated in a stage like env to observe it reduces FieldInfo creation.
> UninvertingReader can be avoided if there are no fields to uninvert
> ---
>
> Key: SOLR-12782
> URL: https://issues.apache.org/jira/browse/SOLR-12782
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12782.patch, SOLR-12782.patch, SOLR-12782.patch
>
>
> Solr uses UninvertingReader to expose DocValues on fields that don't have
> them, but do have indexed fields that can be inverted via the FieldCache. It
> has an internal constructor that takes the input LeafReader and a mapping of
> field name to UninvertingReader.Type. It builds a new FieldInfos that have
> fields reflecting DocValues. There are two things I'd like to improve here:
> # make this constructor private and instead insist you use a new wrap()
> method that has the opportunity to return the input if there is nothing to
> do. Effectively the logic today would move into this wrap method, and the
> current constructor would be dead simple, and would take the FieldInfos.
> # Do _not_ create a new {{FieldInfo}} object if the existing field is
> suitable (it's DocValuesType can stay the same). The savings here can really
> add up on machines with many indexes & segments. This is in fact what
> motivated the patch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5163) edismax should throw exception when qf refers to nonexistent field
[ https://issues.apache.org/jira/browse/SOLR-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621998#comment-16621998 ] David Smiley commented on SOLR-5163: Aliases can refer to other aliases and it's resolved recursively. Based on the patch here, if an alias refers to a bogus field, then the new checks wouldn't catch it. It's not a blocker to mean but it is a shortcoming. You might also want to see if the field is an alias first to avoid the throw of an exception that may be innocent. FYI ExtendedSolrQueryParser validateCyclicAliasing does some checks vaguely similar to what might be needed. > edismax should throw exception when qf refers to nonexistent field > -- > > Key: SOLR-5163 > URL: https://issues.apache.org/jira/browse/SOLR-5163 > Project: Solr > Issue Type: Bug > Components: query parsers, search >Affects Versions: 4.10.4 >Reporter: Steven Bower >Assignee: David Smiley >Priority: Major > Labels: newdev > Attachments: SOLR-5163.patch, SOLR-5163.patch > > > query: > q=foo AND bar > qf=field1 > qf=field2 > defType=edismax > Where field1 exists and field2 doesn't.. > will treat the AND as a term vs and operator -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5163) edismax should throw exception when qf refers to nonexistent field
[ https://issues.apache.org/jira/browse/SOLR-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621982#comment-16621982 ] Edward Ribeiro commented on SOLR-5163: -- If [~dsmiley] agreed then it's hands down the solution. Go ahead! > edismax should throw exception when qf refers to nonexistent field > -- > > Key: SOLR-5163 > URL: https://issues.apache.org/jira/browse/SOLR-5163 > Project: Solr > Issue Type: Bug > Components: query parsers, search >Affects Versions: 4.10.4 >Reporter: Steven Bower >Assignee: David Smiley >Priority: Major > Labels: newdev > Attachments: SOLR-5163.patch, SOLR-5163.patch > > > query: > q=foo AND bar > qf=field1 > qf=field2 > defType=edismax > Where field1 exists and field2 doesn't.. > will treat the AND as a term vs and operator -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-10.0.1) - Build # 22891 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22891/ Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.handler.component.DistributedFacetPivotSmallTest.test Error Message: Error from server at https://127.0.0.1:45239//collection1: ERROR: [doc=19] Error adding field 'company_t'='microsoft polecat' msg=Multiple values encountered for non multiValued copy field text: microsoft polecat Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:45239//collection1: ERROR: [doc=19] Error adding field 'company_t'='microsoft polecat' msg=Multiple values encountered for non multiValued copy field text: microsoft polecat at __randomizedtesting.SeedInfo.seed([7DD9E85705D02AFD:F58DD78DAB2C4705]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:173) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:152) at org.apache.solr.BaseDistributedSearchTestCase.indexDoc(BaseDistributedSearchTestCase.java:483) at org.apache.solr.BaseDistributedSearchTestCase.index(BaseDistributedSearchTestCase.java:476) at org.apache.solr.handler.component.DistributedFacetPivotSmallTest.test(DistributedFacetPivotSmallTest.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1008) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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
[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 164 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/164/ 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.io.sql.JdbcTest Error Message: Error from server at http://127.0.0.1:41534/solr: KeeperErrorCode = NoNode for /overseer/collection-queue-work/qnr-00 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:41534/solr: KeeperErrorCode = NoNode for /overseer/collection-queue-work/qnr-00 at __randomizedtesting.SeedInfo.seed([E7A16FAFF94A698]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.io.sql.JdbcTest.setupCluster(JdbcTest.java:77) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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) Build Log: [...truncated 15909 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.sql.JdbcTest [junit4] 2> ERROR StatusLogger No Log4j 2 configuration file found. Using default configuration (logging only errors to the console), or user programmatically provided configurations. Set system property 'log4j2.debug' to show Log4j 2 internal initialization logging. See https://logging.apache.org/log4j/2.x/manual/configuration.html for instructions on how to configure Log4j 2 [junit4] 2> Creating dataDir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-7.x/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.io.sql.JdbcTest_E7A16FAFF94A698-001/init-core-data-001 [junit4] 1> 11:58:28.135 [Thread-1] ERROR org.apache.zookeeper.server.ZooKeeperServer - ZKShutdownHandler is not registered, so ZooKeeper server won't take any action on
[jira] [Commented] (SOLR-5163) edismax should throw exception when qf refers to nonexistent field
[ https://issues.apache.org/jira/browse/SOLR-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621953#comment-16621953 ] David Smiley commented on SOLR-5163: Ah; thanks for explaining why you placed the code here; makes sense. I like your test; I'm a fan of doing string comparisons for checking the structure of a Query. It's a one-liner that is very easy to read. Yes it's more fragile but I'll take the readability trade any day. Looks good to me. I'll let the patch review bot take a look then commit it. > edismax should throw exception when qf refers to nonexistent field > -- > > Key: SOLR-5163 > URL: https://issues.apache.org/jira/browse/SOLR-5163 > Project: Solr > Issue Type: Bug > Components: query parsers, search >Affects Versions: 4.10.4 >Reporter: Steven Bower >Assignee: David Smiley >Priority: Major > Labels: newdev > Attachments: SOLR-5163.patch, SOLR-5163.patch > > > query: > q=foo AND bar > qf=field1 > qf=field2 > defType=edismax > Where field1 exists and field2 doesn't.. > will treat the AND as a term vs and operator -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12786) HTML reference guide has invalid links
[ https://issues.apache.org/jira/browse/SOLR-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621951#comment-16621951 ] Jan Høydahl commented on SOLR-12786: Patch attached > HTML reference guide has invalid links > -- > > Key: SOLR-12786 > URL: https://issues.apache.org/jira/browse/SOLR-12786 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: master (8.0) >Reporter: Jan Høydahl >Priority: Major > Attachments: SOLR-12786.patch > > > The refguide build aborts due to this. > Example: "updating-solr-s-include-files" should instead be > "updating-solrs-include-files" since apostrophe is not replaced with dash. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
