[jira] [Commented] (LUCENE-7838) Add a knn classifier based on fuzzy like this
[
https://issues.apache.org/jira/browse/LUCENE-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027295#comment-16027295
]
Tommaso Teofili commented on LUCENE-7838:
-
bq. you added a dependency on the sandbox module from another module. That's
quite surprising to me... I don't think that's legit?
why? As soon as we provide releases of lucene-sandbox I assume we expect people
and other modules to use it.
bq. New inter-module dependencies (of any kind) I think should also deserve
communication on the JIRA issue and I don't see any mention here.
Since this is only impacting master branch I had thought there was no need to
explicitly mention that; on the other hand {{FuzzyLikeThisQuery}} lives in
sandbox therefore I had assumed there was no need to explicitly specify that in
the issue.
bq. I also don't see a CHANGES.txt entry
right, there's no such entry.
bq. I don't see a patch file either but I admit I welcome that
I'm not sure I get your point here, would you have expected a patch ?
> Add a knn classifier based on fuzzy like this
> -
>
> Key: LUCENE-7838
> URL: https://issues.apache.org/jira/browse/LUCENE-7838
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/classification
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: master (7.0)
>
>
> FLT mixes fuzzy and MLT, in the context of Lucene based classification it
> might be useful to add such a fuzziness to a dedicated KNN classifier (based
> on FLT queries).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
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/jdk1.8.0_131) - Build # 6594 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6594/ Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [MockDirectoryWrapper] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347) at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:92) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:753) at org.apache.solr.core.SolrCore.(SolrCore.java:948) at org.apache.solr.core.SolrCore.(SolrCore.java:855) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:973) at org.apache.solr.core.CoreContainer.lambda$load$7(CoreContainer.java:605) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188) 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:748) Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [MockDirectoryWrapper] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347) at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:92) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:753) at org.apache.solr.core.SolrCore.(SolrCore.java:948) at org.apache.solr.core.SolrCore.(SolrCore.java:855) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:973) at org.apache.solr.core.CoreContainer.lambda$load$7(CoreContainer.java:605) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188) 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:748) at __randomizedtesting.SeedInfo.seed([AEFB9D2CE5FB207E]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:303) at sun.reflect.GeneratedMethodAccessor98.invoke(Unknown Source) 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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870) 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.Tes
[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_131) - Build # 3601 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3601/ Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([7580FCCFA64CF716:FDD4C31508B09AEE]:0) at org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test(TestSolrConfigHandlerConcurrent.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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) 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:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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 11510 lines...] [junit4] Suite: org.apache.solr.handler.TestSolrConfigHandlerConcurrent [junit4] 2> Creating dataDir
[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 856 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/856/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.update.HdfsTransactionLog at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130) at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:153) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:110) at org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108) at sun.reflect.GeneratedConstructorAccessor109.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:760) at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:822) at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1088) at org.apache.solr.core.SolrCore.(SolrCore.java:947) at org.apache.solr.core.SolrCore.(SolrCore.java:830) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:930) at org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:565) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:748) Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.update.HdfsTransactionLog at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130) at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:153) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:110) at org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108) at sun.reflect.GeneratedConstructorAccessor109.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:760) at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:822) at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1088) at org.apache.solr.core.SolrCore.(SolrCore.java:947) at org.apache.solr.core.SolrCore.(SolrCore.java:830) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:930) at org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:565) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:748) at __randomizedtesting.SeedInfo.seed([8BD843C9AF5BB93E]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:302) at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source) 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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870) at com.carrotsearch.randomizedtesting.rules.State
Re: A way to tell DIH (IF id already exist in current index THEN SKIP to next file)
Sorry man. Thanks 4 Ur help! El 25 may. 2017 23:36, "David Smiley" escribió: > Hello, > You've reached the wrong list. This is the dev list; you should use the > solr-user list. > ~ David > > On Thu, May 25, 2017 at 10:57 PM Alejandro Rivas Martinez < > alex.rivas...@gmail.com> wrote: > >> Hello! My name is Alejandro and I need your help ASAP!. >> I'm new at SOlr and I have a situation with data import handler. >> Some Context Inform... >> I'm using a multi-core Solr in which each core index different kinds of >> files(one core to Audios, other to Softwares...). I'm using DIH to >> automatically index thousands of files from an ftp servers and extracts >> metadata with tika entity processor and it works Just Fine (absoluteUrlPath >> as unique id). >> I'm using a social networking approach, so users can modify metadata of >> any kind in a Front-end Asp.Net MVC webapp and I'm using SolrNet to >> communicate Solr with .Net. When users finish to edit metadata I update the >> index with the users changes, Commit and So far so good. >> THE TROUBLE-> When I run again data import handler to detect new >> documents in the ftp server, it changes again all the values to default DIH >> config files and the user modification, get lost. >> So Am I doing something wrong, is there a way to tell Data Import Handler >> something like IF id already exist THEN SKIP to next file. Any suggestion >> or information that I need to know to make that requirement happen. >> Thank U so much for your time And so Sorry about my english (It is not my >> native language). >> > -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www. > solrenterprisesearchserver.com >
[jira] [Resolved] (SOLR-10755) delete/refactor (most) solrj deprecations on master
[ https://issues.apache.org/jira/browse/SOLR-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-10755. - Resolution: Fixed > delete/refactor (most) solrj deprecations on master > --- > > Key: SOLR-10755 > URL: https://issues.apache.org/jira/browse/SOLR-10755 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Blocker > Fix For: master (7.0) > > Attachments: SOLR-10755.patch, SOLR-10755.patch, SOLR-10755.patch, > SOLR-10755.patch > > > using this issue to track some work i've done to cleanup deprecations in > solrj for master (7.0) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10755) delete/refactor (most) solrj deprecations on master
[ https://issues.apache.org/jira/browse/SOLR-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027128#comment-16027128 ] ASF subversion and git services commented on SOLR-10755: Commit bc973ecdcfacf39440da06b86139c77935e1e92e in lucene-solr's branch refs/heads/master from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bc973ec ] SOLR-10755: delete/refactor many solrj deprecations > delete/refactor (most) solrj deprecations on master > --- > > Key: SOLR-10755 > URL: https://issues.apache.org/jira/browse/SOLR-10755 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Blocker > Fix For: master (7.0) > > Attachments: SOLR-10755.patch, SOLR-10755.patch, SOLR-10755.patch, > SOLR-10755.patch > > > using this issue to track some work i've done to cleanup deprecations in > solrj for master (7.0) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 893 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/893/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 6 tests failed. FAILED: org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter Error Message: Collection not found: withShardField Stack Trace: org.apache.solr.common.SolrException: Collection not found: withShardField at __randomizedtesting.SeedInfo.seed([B69EDA34A85656DC:E3CE32A604AF992C]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1401) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1094) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160) at org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233) at org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter(CustomCollectionTest.java:141) 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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) 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:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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) a
[jira] [Assigned] (SOLR-10501) numeric PointsFields: need more testing of sortMissing=last|first for
[
https://issues.apache.org/jira/browse/SOLR-10501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe reassigned SOLR-10501:
-
Assignee: Steve Rowe
> numeric PointsFields: need more testing of sortMissing=last|first for
> -
>
> Key: SOLR-10501
> URL: https://issues.apache.org/jira/browse/SOLR-10501
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Steve Rowe
>
> while working on SOLR-10472, i noticed {{sortMissing}} isn't really tested
> for points fields - just some TODO items in the test about this.
> we should beef this up (some other test improvements in SOLR-10472 should
> make this a bit more straight forward)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10761) Switch trie numeric/date fields to points in data-driven-enabled example schemas
[
https://issues.apache.org/jira/browse/SOLR-10761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-10761:
--
Issue Type: Sub-task (was: Task)
Parent: SOLR-9995
> Switch trie numeric/date fields to points in data-driven-enabled example
> schemas
>
>
> Key: SOLR-10761
> URL: https://issues.apache.org/jira/browse/SOLR-10761
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>
> Currently in data-driven-enabled example schemas, the
> {{AddSchemaFieldsUpdateProcessorFactory}} configuration causes trie
> numeric/date fields to be created. These should be switched to point field
> types.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10761) Switch trie numeric/date fields to points in data-driven-enabled example schemas
Steve Rowe created SOLR-10761:
-
Summary: Switch trie numeric/date fields to points in
data-driven-enabled example schemas
Key: SOLR-10761
URL: https://issues.apache.org/jira/browse/SOLR-10761
Project: Solr
Issue Type: Task
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Steve Rowe
Assignee: Steve Rowe
Currently in data-driven-enabled example schemas, the
{{AddSchemaFieldsUpdateProcessorFactory}} configuration causes trie
numeric/date fields to be created. These should be switched to point field
types.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.6-Linux (64bit/jdk1.8.0_131) - Build # 4 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Linux/4/ Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([81427CD7CE637EBE:A65AF068F65D53A]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856) at org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437) 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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) 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:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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)
[jira] [Commented] (SOLR-10503) CurrencyField should be changed from TrieLongField to LongPointField for underlying raw-polyfield
[ https://issues.apache.org/jira/browse/SOLR-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027031#comment-16027031 ] Steve Rowe commented on SOLR-10503: --- bq. perhaps the best solution would be to deprecate CurrencyField and add a CurrencyPointField to replace it – fixing SOLR-10502 at the same time? +1 > CurrencyField should be changed from TrieLongField to LongPointField for > underlying raw-polyfield > - > > Key: SOLR-10503 > URL: https://issues.apache.org/jira/browse/SOLR-10503 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks
[ https://issues.apache.org/jira/browse/SOLR-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027030#comment-16027030 ] Michael Sun commented on SOLR-10317: bq. motivation behind creating yet another benchmarking utility That's a good question. In fact it's one of the reasons that I suggested to start a scoping doc to start conversation early on. (https://issues.apache.org/jira/browse/SOLR-10317?focusedCommentId=16011107&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16011107) Here are my two cents for a few areas that can be improved in addition to increasing test coverage. [~vivek.nar...@uga.edu] can articulate. 1. Currently benchmark tells us how Solr perform but it can also help to tell why Solr perform in this way. A good example of effort in this direction is the telemetry (https://esrally.readthedocs.io/en/latest/telemetry.html) in rally framework. 2. Provide baseline data for capacity planning. For capacity planning, it requires some data such as CPU, disk etc. for specific workloads and benchmark can provide that. 3. Extensibility: a benchmark can be easily extended to include new components. For example, JMeter can be a good load generator for scalability study for Solr cluster with hundreds of nodes and it should be easy to extend current test case to use JMeter to replace existing load generator. This may require an object model at different abstraction level compared to existing benchmarks. 4. Support more Solr setup and data type. For example, wiki data is a good but tweets data can be better in studying Solr performance for real time analytics use cases. 5. Last but not least, as any engineering tool, I was hoping the benchmark suite can standardize Solr performance effort, promote code reuse and facilitate collaboration. This requires good understanding for all use cases and careful design. Of course, this doesn't need to be all done for GoC project. Not to scare [~vivek.nar...@uga.edu] :) Overall, this project is a good initiative and a good venue to continue this discussion. > Solr Nightly Benchmarks > --- > > Key: SOLR-10317 > URL: https://issues.apache.org/jira/browse/SOLR-10317 > Project: Solr > Issue Type: Task >Reporter: Ishan Chattopadhyaya > Labels: gsoc2017, mentor > Attachments: changes-lucene-20160907.json, > changes-solr-20160907.json, managed-schema, > Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, > Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, > solrconfig.xml > > > Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be > found here, https://home.apache.org/~mikemccand/lucenebench/. > Preferably, we need: > # A suite of benchmarks that build Solr from a commit point, start Solr > nodes, both in SolrCloud and standalone mode, and record timing information > of various operations like indexing, querying, faceting, grouping, > replication etc. > # It should be possible to run them either as an independent suite or as a > Jenkins job, and we should be able to report timings as graphs (Jenkins has > some charting plugins). > # The code should eventually be integrated in the Solr codebase, so that it > never goes out of date. > There is some prior work / discussion: > # https://github.com/shalinmangar/solr-perf-tools (Shalin) > # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md > (Ishan/Vivek) > # SOLR-2646 & SOLR-9863 (Mark Miller) > # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless) > # https://github.com/lucidworks/solr-scale-tk (Tim Potter) > There is support for building, starting, indexing/querying and stopping Solr > in some of these frameworks above. However, the benchmarks run are very > limited. Any of these can be a starting point, or a new framework can as well > be used. The motivation is to be able to cover every functionality of Solr > with a corresponding benchmark that is run every night. > Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure > [~shalinmangar] and [~markrmil...@gmail.com] would help here. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10760) Remove trie field types and fields from example schemas
[ https://issues.apache.org/jira/browse/SOLR-10760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated SOLR-10760: -- Issue Type: Sub-task (was: Task) Parent: SOLR-9995 > Remove trie field types and fields from example schemas > --- > > Key: SOLR-10760 > URL: https://issues.apache.org/jira/browse/SOLR-10760 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe > > In order to make points fields the default, we should remove all trie field > types and fields from example schemas. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10718) Configuring Basic auth prevents adding a collection
[
https://issues.apache.org/jira/browse/SOLR-10718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027018#comment-16027018
]
Jan Høydahl commented on SOLR-10718:
I manage to reproduce. And it works in master branch. However, the mechanism
for building HttpClient changed a lot between 6.x and 7.x
(PreemptiveBasicAuthConfigurer vs PreemptiveBasicAuthClientBuilderFactory etc),
so I suppose there is something here that has not been tested properly.
It works fine for the initial call but fails when it is the Overseer that
issues the collection creation from the queue.
> Configuring Basic auth prevents adding a collection
> ---
>
> Key: SOLR-10718
> URL: https://issues.apache.org/jira/browse/SOLR-10718
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 6.5, 6.5.1
>Reporter: Shawn Feldman
>Priority: Minor
> Attachments: repro.sh
>
>
> Configure Basic auth according to documentation
> Add basic auth params
> SOLR_AUTH_TYPE="basic"
> SOLR_AUTHENTICATION_OPTS="-Dbasicauth=solr:SolrRocks"
> Try to add a collection
> Receive a timeout and error in the logs
> {code}
> java.lang.IllegalArgumentException: Credentials may not be null
> at org.apache.http.util.Args.notNull(Args.java:54)
> at org.apache.http.auth.AuthState.update(AuthState.java:113)
> at
> org.apache.solr.client.solrj.impl.PreemptiveAuth.process(PreemptiveAuth.java:56)
> at
> org.apache.http.protocol.ImmutableHttpProcessor.process(ImmutableHttpProcessor.java:132)
> at
> org.apache.http.protocol.HttpRequestExecutor.preProcess(HttpRequestExecutor.java:166)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:485)
> at
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:515)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10760) Remove trie field types and fields from example schemas
Steve Rowe created SOLR-10760: - Summary: Remove trie field types and fields from example schemas Key: SOLR-10760 URL: https://issues.apache.org/jira/browse/SOLR-10760 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Steve Rowe In order to make points fields the default, we should remove all trie field types and fields from example schemas. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+171) - Build # 3599 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3599/ Java: 64bit/jdk-9-ea+171 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.TestRandomRequestDistribution.test Error Message: Shard a1x2_shard1_replica2 received all 10 requests Stack Trace: java.lang.AssertionError: Shard a1x2_shard1_replica2 received all 10 requests at __randomizedtesting.SeedInfo.seed([862F4C3A99CF555B:E7B73E0373338A3]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking(TestRandomRequestDistribution.java:121) at org.apache.solr.cloud.TestRandomRequestDistribution.test(TestRandomRequestDistribution.java:65) 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:563) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) 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:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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.randomizedtes
[jira] [Commented] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[ https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026974#comment-16026974 ] ASF subversion and git services commented on SOLR-10758: Commit f1999b549d759f67a16860d403c50c60671e4186 in lucene-solr's branch refs/heads/branch_6x from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f1999b5 ] SOLR-10758: move CHANGES entry under 6.6 section after backport > Modernize the Solr ref guide's Chinese language analysis coverage > - > > Key: SOLR-10758 > URL: https://issues.apache.org/jira/browse/SOLR-10758 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10758.patch > > > The Chinese analysis coverage in the ref guide is out of date. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[ https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026975#comment-16026975 ] ASF subversion and git services commented on SOLR-10758: Commit 1d2acdbea788bfbc75e4a1a475cf1395c31bd569 in lucene-solr's branch refs/heads/master from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1d2acdb ] SOLR-10758: move CHANGES entry under 6.6 section after backport > Modernize the Solr ref guide's Chinese language analysis coverage > - > > Key: SOLR-10758 > URL: https://issues.apache.org/jira/browse/SOLR-10758 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10758.patch > > > The Chinese analysis coverage in the ref guide is out of date. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10000) Instrument Solr caches
[ https://issues.apache.org/jira/browse/SOLR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe resolved SOLR-1. --- Resolution: Fixed Assignee: Andrzej Bialecki (was: Steve Rowe) > Instrument Solr caches > -- > > Key: SOLR-1 > URL: https://issues.apache.org/jira/browse/SOLR-1 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Shalin Shekhar Mangar >Assignee: Andrzej Bialecki > Fix For: 6.6 > > Attachments: SOLR-1.patch > > > The stats captured for solr caches should be exposed in the new metrics api > and configured reporters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10000) Instrument Solr caches
[ https://issues.apache.org/jira/browse/SOLR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026959#comment-16026959 ] Steve Rowe commented on SOLR-1: --- bq. Does it need to be on master, as well? No, I don't think so, since as [~ab] wrote above: bq. This has been fixed on master as a part of SOLR-9959. We could back-port relevant changes to 6x. So since SOLR-9959 is a superset of the changes on this issue, there is no need to commit this issue's changes to master. > Instrument Solr caches > -- > > Key: SOLR-1 > URL: https://issues.apache.org/jira/browse/SOLR-1 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Shalin Shekhar Mangar >Assignee: Steve Rowe > Fix For: 6.6 > > Attachments: SOLR-1.patch > > > The stats captured for solr caches should be exposed in the new metrics api > and configured reporters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10000) Instrument Solr caches
[ https://issues.apache.org/jira/browse/SOLR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026952#comment-16026952 ] ASF subversion and git services commented on SOLR-1: Commit 692e09835526170ef4701bcac984b3cbe05fa7c8 in lucene-solr's branch refs/heads/branch_6_6 from [~ab] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=692e098 ] SOLR-1: Expose cache statistics using metrics API (partial port from master). Conflicts: solr/CHANGES.txt > Instrument Solr caches > -- > > Key: SOLR-1 > URL: https://issues.apache.org/jira/browse/SOLR-1 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Shalin Shekhar Mangar >Assignee: Steve Rowe > Fix For: 6.6 > > Attachments: SOLR-1.patch > > > The stats captured for solr caches should be exposed in the new metrics api > and configured reporters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10000) Instrument Solr caches
[ https://issues.apache.org/jira/browse/SOLR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026946#comment-16026946 ] Ishan Chattopadhyaya commented on SOLR-1: - Does it need to be on master, as well? > Instrument Solr caches > -- > > Key: SOLR-1 > URL: https://issues.apache.org/jira/browse/SOLR-1 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Shalin Shekhar Mangar >Assignee: Steve Rowe > Fix For: 6.6 > > Attachments: SOLR-1.patch > > > The stats captured for solr caches should be exposed in the new metrics api > and configured reporters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya closed SOLR-10735.
---
Resolution: Fixed
Assignee: Ishan Chattopadhyaya
Fix Version/s: master (7.0)
6.6
Thanks [~thetaphi]! Seems like it was the German locale, indeed!
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Fix For: 6.6, master (7.0)
>
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png, Screenshot from 2017-05-27 02-16-04.png,
> screenshot-with-patch.png, SOLR-10735.patch
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-10000) Instrument Solr caches
[ https://issues.apache.org/jira/browse/SOLR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe reopened SOLR-1: --- Assignee: Steve Rowe (was: Andrzej Bialecki ) Reopening to backport to branch_6_6. Apparently [~ab] didn't notice that the release branch was cut the day before he backported to branch_6x. > Instrument Solr caches > -- > > Key: SOLR-1 > URL: https://issues.apache.org/jira/browse/SOLR-1 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Shalin Shekhar Mangar >Assignee: Steve Rowe > Fix For: 6.6 > > Attachments: SOLR-1.patch > > > The stats captured for solr caches should be exposed in the new metrics api > and configured reporters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10004) javadoc test in smokeTestRelease.py wants to fail
[ https://issues.apache.org/jira/browse/SOLR-10004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026937#comment-16026937 ] ASF subversion and git services commented on SOLR-10004: Commit 4944ddc305ba731bb9011b82bed5a99e36403601 in lucene-solr's branch refs/heads/master from [~ichattopadhyaya] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4944ddc ] SOLR-10004: Placing the experimental tag properly > javadoc test in smokeTestRelease.py wants to fail > - > > Key: SOLR-10004 > URL: https://issues.apache.org/jira/browse/SOLR-10004 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.4 >Reporter: Mike Drob > Attachments: javadoc_results, missing-descriptions.txt, Screenshot > from 2017-05-25 17-29-23.png > > > When running smoke test for 6.4, I got a lot of noise about missing content > related to javadocs. > Attaching a partial output. > We should either fix the check so that this isn't so verbose with failures we > ignore, or fix the failures. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10004) javadoc test in smokeTestRelease.py wants to fail
[ https://issues.apache.org/jira/browse/SOLR-10004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026936#comment-16026936 ] ASF subversion and git services commented on SOLR-10004: Commit 5558e5c0e4c0688d93b7b6ef3caed3230929efc7 in lucene-solr's branch refs/heads/branch_6x from [~ichattopadhyaya] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5558e5c ] SOLR-10004: Placing the experimental tag properly > javadoc test in smokeTestRelease.py wants to fail > - > > Key: SOLR-10004 > URL: https://issues.apache.org/jira/browse/SOLR-10004 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.4 >Reporter: Mike Drob > Attachments: javadoc_results, missing-descriptions.txt, Screenshot > from 2017-05-25 17-29-23.png > > > When running smoke test for 6.4, I got a lot of noise about missing content > related to javadocs. > Attaching a partial output. > We should either fix the check so that this isn't so verbose with failures we > ignore, or fix the failures. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10004) javadoc test in smokeTestRelease.py wants to fail
[ https://issues.apache.org/jira/browse/SOLR-10004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026934#comment-16026934 ] ASF subversion and git services commented on SOLR-10004: Commit e17fee9088547613d40e03d3d6c34e6e34f427a6 in lucene-solr's branch refs/heads/branch_6_6 from [~ichattopadhyaya] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e17fee9 ] SOLR-10004: Placing the experimental tag properly > javadoc test in smokeTestRelease.py wants to fail > - > > Key: SOLR-10004 > URL: https://issues.apache.org/jira/browse/SOLR-10004 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.4 >Reporter: Mike Drob > Attachments: javadoc_results, missing-descriptions.txt, Screenshot > from 2017-05-25 17-29-23.png > > > When running smoke test for 6.4, I got a lot of noise about missing content > related to javadocs. > Attaching a partial output. > We should either fix the check so that this isn't so verbose with failures we > ignore, or fix the failures. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026895#comment-16026895
]
Uwe Schindler edited comment on SOLR-10735 at 5/26/17 10:09 PM:
Maybe it has also to do with the german language, but IMHO the attached patch
is the correct way to fix this.
I'd suggest that we change smoketester to use a folder with whitespace. Should
I open an issue for that? This way we can catch bugs like this faster --
although I never found a way how to run smoketester on Windows _without_
cygwin, so not useable on Policeman Jenkins.
was (Author: thetaphi):
Maybe it has also to do with the german language, but IMHO the attached patch
is the correct way to fix this.
I'd suggest that we change smoketester to use a folder with whitespace. Should
I open an issue for that. This way we can catch bugs like this faster --
although I never found a way how to run smoketester on Windows _without_
cygwin, so not useable on Policeman Jenkins.
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png, Screenshot from 2017-05-27 02-16-04.png,
> screenshot-with-patch.png, SOLR-10735.patch
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026929#comment-16026929
]
Uwe Schindler commented on SOLR-10735:
--
I rebuilt a release with the attached patch. For me this starts in the same
setup as before:
!screenshot-with-patch.png!
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png, Screenshot from 2017-05-27 02-16-04.png,
> screenshot-with-patch.png, SOLR-10735.patch
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[ https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026928#comment-16026928 ] ASF subversion and git services commented on SOLR-10758: Commit 430f6c9be2fdf73982d67b1c4a5ed69bcfd21de1 in lucene-solr's branch refs/heads/branch_6_6 from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=430f6c9 ] SOLR-10758: fix broken internal link to new HMM Chinese Tokenizer section > Modernize the Solr ref guide's Chinese language analysis coverage > - > > Key: SOLR-10758 > URL: https://issues.apache.org/jira/browse/SOLR-10758 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10758.patch > > > The Chinese analysis coverage in the ref guide is out of date. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated SOLR-10735:
-
Attachment: screenshot-with-patch.png
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png, Screenshot from 2017-05-27 02-16-04.png,
> screenshot-with-patch.png, SOLR-10735.patch
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[ https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026926#comment-16026926 ] ASF subversion and git services commented on SOLR-10758: Commit e9a918058b271e1ad69cf786bcc22215db26b4de in lucene-solr's branch refs/heads/branch_6_6 from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e9a9180 ] SOLR-10758: Modernize the Solr ref guide's Chinese language analysis coverage > Modernize the Solr ref guide's Chinese language analysis coverage > - > > Key: SOLR-10758 > URL: https://issues.apache.org/jira/browse/SOLR-10758 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10758.patch > > > The Chinese analysis coverage in the ref guide is out of date. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[ https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026927#comment-16026927 ] ASF subversion and git services commented on SOLR-10758: Commit 82b535039b730a9db0d4e3a6e308750a46e53cff in lucene-solr's branch refs/heads/branch_6_6 from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=82b5350 ] SOLR-10758: Point to Lib Directives in SolrConfig page from the Traditional Chinese ICUTokenizer paragraph. > Modernize the Solr ref guide's Chinese language analysis coverage > - > > Key: SOLR-10758 > URL: https://issues.apache.org/jira/browse/SOLR-10758 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10758.patch > > > The Chinese analysis coverage in the ref guide is out of date. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026924#comment-16026924
]
ASF subversion and git services commented on SOLR-10735:
Commit 732e8331cf984c0ebe02e20f70daacd82817bd4e in lucene-solr's branch
refs/heads/branch_6_6 from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=732e833 ]
SOLR-10735: Fixing windows space directory issue
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png, Screenshot from 2017-05-27 02-16-04.png,
> SOLR-10735.patch
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026923#comment-16026923
]
ASF subversion and git services commented on SOLR-10735:
Commit 995291df788ed75d8430f40bb99cc668de86c6aa in lucene-solr's branch
refs/heads/branch_6x from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=995291d ]
SOLR-10735: Fixing windows space directory issue
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png, Screenshot from 2017-05-27 02-16-04.png,
> SOLR-10735.patch
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-10697) Improve defaults for maxConnectionsPerHost
[
https://issues.apache.org/jira/browse/SOLR-10697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker reopened SOLR-10697:
--
Assignee: Varun Thacker
Hi [~elyograg]
If you follow {{HttpClientUtil#createClient}} and don't pass any params, the
max_connections_per_host is set to 10k
{{cm.setDefaultMaxPerRoute(params.getInt(HttpClientUtil.PROP_MAX_CONNECTIONS_PER_HOST,
1));}}
So maybe {{HttpShardHandlerFactory}} shouldn't even set any defaults and resort
to the defaults from HttpClientUtil?
Also we already have a high PROP_MAX_CONNECTIONS default in
HttpShardHandlerFactory so why not for PROP_MAX_CONNECTIONS_PER_HOST ?
Thoughts?
> Improve defaults for maxConnectionsPerHost
> --
>
> Key: SOLR-10697
> URL: https://issues.apache.org/jira/browse/SOLR-10697
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
>
> Twice recently I've increased
> {{HttpShardHandlerFactory#maxConnectionsPerHost}} at a client and it helped
> improve query latencies a lot.
> Should we increase the default to say 100 ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026917#comment-16026917
]
ASF subversion and git services commented on SOLR-10735:
Commit 45b26e322f1e173c8a19f07700e64daa5475da84 in lucene-solr's branch
refs/heads/master from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=45b26e3 ]
SOLR-10735: Fixing windows space directory issue
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png, Screenshot from 2017-05-27 02-16-04.png,
> SOLR-10735.patch
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 6.6.0 RC3
Sure, Steve. Please go ahead. It seems there will be a re-spin to include SOLR-10735 fix. I'll also take the opportunity to dig into SOLR-10004 a bit more. Apart from the unconventional placement of @lucene.experimental tags that I did there, I want to understand why those descriptions still didn't make it to the javadocs (and hence continued to print a "missing" warning). On Sat, May 27, 2017 at 12:24 AM, Steve Rowe wrote: > Ishan, > > If there is a respin, I’d like to include SOLR-10758 (updates Chinese > analysis in the Solr ref guide, and includes a Lucene test addition in the > analysis/icu module). > > -- > Steve > www.lucidworks.com > > > On May 26, 2017, at 12:45 PM, Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > > > > Not sure if half of Windows users have spaces in their home directory. > If someone marks SOLR-10735 as a blocker and/or provides a fix, I'll be > happy to re-spin. > > > > On Fri, May 26, 2017 at 9:55 PM, Tomas Fernandez Lobbe < > tflo...@apple.com> wrote: > > I didn’t try this myself yet (just got a Windows machine to try it), but > looking at Uwe’s comment here[1], I think this should be a blocker, half > Windows users won’t be able to run the example. > > > > > > [1] https://issues.apache.org/jira/browse/SOLR-10735? > focusedCommentId=16026393&page=com.atlassian.jira. > plugin.system.issuetabpanels:comment-tabpanel#comment-16026393 > > > >> On May 26, 2017, at 8:34 AM, Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> > >> Uwe, do you think this is a blocker? > >> > >> On Fri, May 26, 2017 at 8:43 PM, Uwe Schindler wrote: > >> Hi, > >> > >> > >> > >> on my computer, the Solr one still does not start -see the whitespace > in directory name (my user name): > >> > >> > >> > >> C:\Users\Uwe Schindler\Desktop\solr-6.6.0\bin>solr.cmd start -e > techproducts > >> > >> Creating Solr home directory C:\Users\Uwe Schindler\Desktop\solr-6.6.0\ > example\techproducts\solr > >> > >> > >> > >> Starting up Solr on port 8983 using command: > >> > >> C:\Users\Uwe Schindler\Desktop\solr-6.6.0\bin\solr.cmd start -p 8983 > -s "C:\Users\Uwe Schindler\Desktop\solr-6.6.0\example\techproducts\solr" > >> > >> > >> > >> > >> > >> ERROR: Failed to start Solr using command: C:\Users\Uwe > Schindler\Desktop\solr-6.6.0\bin\solr.cmd start -p 8983 -s "C:\Users\Uwe > Schindler\Desktop\solr-6.6.0\example\techproducts\solr" Exception : > org.apache.commons.exec.ExecuteException: Execution failed (Exit value: > -559038737. Caused by java.io.IOException: Cannot run program > "C:\Users\Uwe" (in directory "."): CreateProcess error=193, %1 ist keine > zulässige Win32-Anwendung) > >> > >> > >> > >> > >> > >> C:\Users\Uwe Schindler\Desktop\solr-6.6.0\bin> > >> > >> > >> > >> I will post this to the issue. Starting Solr without example works, but > you then have no core to quickly do tests. > >> > >> > >> > >> FYI, I added a Linux and Windows build of branch_6_6 to Policeman > Jenkins a minute ago. > >> > >> > >> > >> Uwe > >> > >> > >> > >> - > >> > >> Uwe Schindler > >> > >> Achterdiek 19, D-28357 Bremen > >> > >> http://www.thetaphi.de > >> > >> eMail: u...@thetaphi.de > >> > >> > >> > >> From: Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com] > >> Sent: Friday, May 26, 2017 9:43 AM > >> To: dev@lucene.apache.org > >> Subject: [VOTE] Release Lucene/Solr 6.6.0 RC3 > >> > >> > >> > >> Please vote for release candidate 3 for Lucene/Solr 6.6.0 > >> > >> The artifacts can be downloaded from: > >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC3- > revbfb1ee42b2edbc2f2dea49b9d0e3201069d6e781 > >> > >> You can run the smoke tester directly with this command: > >> > >> python3 -u dev-tools/scripts/smokeTestRelease.py \ > >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC3- > revbfb1ee42b2edbc2f2dea49b9d0e3201069d6e781 > >> > >> Here's my +1 > >> SUCCESS! [1:16:00.055493] > >> > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Commented] (SOLR-10233) Add support for different replica types in Solr
[
https://issues.apache.org/jira/browse/SOLR-10233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026905#comment-16026905
]
ASF subversion and git services commented on SOLR-10233:
Commit 8f92fb4722709bec34b4c0330afb7cabba86e350 in lucene-solr's branch
refs/heads/master from Tomas Fernandez Lobbe
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8f92fb4 ]
SOLR-10233: Correctly set maxShardsPerNode in BackupRestoreTestCase when using
createNodeSet and replica types
> Add support for different replica types in Solr
> ---
>
> Key: SOLR-10233
> URL: https://issues.apache.org/jira/browse/SOLR-10233
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Fix For: master (7.0)
>
> Attachments: 11431.consoleText.txt, SOLR-10233.patch,
> SOLR-10233.patch, SOLR-10233.patch, SOLR-10233.patch, SOLR-10233.patch
>
>
> For the majority of the cases, current SolrCloud's distributed indexing is
> great. There is a subset of use cases for which the legacy Master/Slave
> replication may fit better:
> * Don’t require NRT
> * LIR can become an issue, prefer availability of reads vs consistency or NRT
> * High number of searches (requiring many search nodes)
> SOLR-9835 is adding replicas that don’t do indexing, just update their
> transaction log. This Jira is to extend that idea and provide the following
> replica types:
> * *Realtime:* Writes updates to transaction log and indexes locally. Replicas
> of type “realtime” support NRT (soft commits) and RTG. Any _realtime_ replica
> can become a leader. This is the only type supported in SolrCloud at this
> time and will be the default.
> * *Append:* Writes to transaction log, but not to index, uses replication.
> Any _append_ replica can become leader (by first applying all local
> transaction log elements). If a replica is of type _append_ but is also the
> leader, it will behave as a _realtime_. This is exactly what SOLR-9835 is
> proposing (non-live replicas)
> * *Passive:* Doesn’t index or writes to transaction log. Just replicates from
> _realtime_ or _append_ replicas. Passive replicas can’t become shard leaders
> (i.e., if there are only passive replicas in the collection at some point,
> updates will fail same as if there is no leaders, queries continue to work),
> so they don’t even participate in elections.
> When the leader replica of the shard receives an update, it will distribute
> it to all _realtime_ and _append_ replicas, the same as it does today. It
> won't distribute to _passive_ replicas.
> By using a combination of _append_ and _passive_ replicas, one can achieve an
> equivalent of the legacy Master/Slave architecture in SolrCloud mode with
> most of its benefits, including high availability of writes.
> h2. API (v1 style)
> {{/admin/collections?action=CREATE…&*realtimeReplicas=X&appendReplicas=Y&passiveReplicas=Z*}}
> {{/admin/collections?action=ADDREPLICA…&*type=\[realtime/append/passive\]*}}
> * “replicationFactor=” will translate to “realtime=“ for back compatibility
> * if _passive_ > 0, _append_ or _realtime_ need to be >= 1 (can’t be all
> passives)
> h2. Placement Strategies
> By using replica placement rules, one should be able to dedicate nodes to
> search-only and write-only workloads. For example:
> {code}
> shard:*,replica:*,type:passive,fleet:slaves
> {code}
> where “type” is a new condition supported by the rule engine, and
> “fleet:slaves” is a regular tag. Note that rules are only applied when the
> replicas are created, so a later change in tags won't affect existing
> replicas. Also, rules are per collection, so each collection could contain
> it's own different rules.
> Note that on the server side Solr also needs to know how to distribute the
> shard requests (maybe ShardHandler?) if we want to hit only a subset of
> replicas (i.e. *passive *replicas only, or similar rules)
> h2. SolrJ
> SolrCloud client could be smart to prefer _passive_ replicas for search
> requests when available (and if configured to do so). _Passive_ replicas
> can’t respond RTG requests, so those should go to _realtime_ replicas.
> h2. Cluster/Collection state
> {code}
> {"gettingstarted":{
> "replicationFactor":"1",
> "router":{"name":"compositeId"},
> "maxShardsPerNode":"2",
> "autoAddReplicas":"false",
> "shards":{
> "shard1":{
> "range":"8000-",
> "state":"active",
> "replicas":{
> "core_node5":{
> "core":"gettingstarted_shard1_replica1",
> "base_url":"http://127.0.0.1:8983/solr";,
> "node_name":"127.0.0.1:8983_solr",
>
[jira] [Commented] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026895#comment-16026895
]
Uwe Schindler commented on SOLR-10735:
--
Maybe it has also to do with the german language, but IMHO the attached patch
is the correct way to fix this.
I'd suggest that we change smoketester to use a folder with whitespace. Should
I open an issue for that. This way we can catch bugs like this faster --
although I never found a way how to run smoketester on Windows _without_
cygwin, so not useable on Policeman Jenkins.
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png, Screenshot from 2017-05-27 02-16-04.png,
> SOLR-10735.patch
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-10735:
Attachment: Screenshot from 2017-05-27 02-16-04.png
I tried the PowerShell, but couldn't reproduce as well.
!Screenshot from 2017-05-27 02-16-04.png!
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png, Screenshot from 2017-05-27 02-16-04.png,
> SOLR-10735.patch
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026874#comment-16026874
]
Jan Høydahl commented on SOLR-10735:
I tried on my Win10 Pro Microsoft Windows \[Version 10.0.10240\], Java
1.8.0_131, running in cmd.exe, and could not reproduce:
{noformat}
C:\Users\janms\apache solr\solr-6.5.1>bin\solr -e techproducts -V
[...]
Starting up Solr on port 8983 using command:
C:\Users\janms\apache solr\solr-6.5.1\bin\solr.cmd start -p 8983 -s
"C:\Users\janms\apache solr\solr-6.5.1\example\techproducts\solr"
{noformat}
The printout above suggests that this is the string parsed by common exec, but
it succeeds all the same. But if I try to copy-paste that same string into
CMD.exe, I get
{noformat}
C:\Users\janms\apache solr\solr-6.5.1>C:\Users\janms\apache
solr\solr-6.5.1\bin\solr.cmd start -p 8983 -s "C:\Users\janms\apache
solr\solr-6.5.1\example\techproducts\solr"
'C:\Users\janms\apache' is not recognized as an internal or external command,
operable program or batch file.
{noformat}
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png, SOLR-10735.patch
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Solr-reference-guide-6.x - Build # 16 - Failure
I pushed a fix. "ant build-site build-pdf” from solr/solr-ref-guide/ succeeds
for me now. (Forgot to do that previously for the included sanity checks.)
--
Steve
www.lucidworks.com
> On May 26, 2017, at 4:41 PM, Apache Jenkins Server
> wrote:
>
> Build: https://builds.apache.org/job/Solr-reference-guide-6.x/16/
>
> Log:
> Started by timer
> [EnvInject] - Loading node environment variables.
> Building remotely on H19 (git-websites) in workspace
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x
>> git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>> git config remote.origin.url git://git.apache.org/lucene-solr.git #
>> timeout=10
> Cleaning workspace
>> git rev-parse --verify HEAD # timeout=10
> Resetting working tree
>> git reset --hard # timeout=10
>> git clean -fdx # timeout=10
> Fetching upstream changes from git://git.apache.org/lucene-solr.git
>> git --version # timeout=10
>> git fetch --tags --progress git://git.apache.org/lucene-solr.git
>> +refs/heads/*:refs/remotes/origin/*
>> git rev-parse refs/remotes/origin/branch_6x^{commit} # timeout=10
>> git rev-parse refs/remotes/origin/origin/branch_6x^{commit} # timeout=10
> Checking out Revision 1e6ef417549f45c815d99291f085f2319b54b4fa
> (refs/remotes/origin/branch_6x)
>> git config core.sparsecheckout # timeout=10
>> git checkout -f 1e6ef417549f45c815d99291f085f2319b54b4fa
>> git rev-list 1968c67790b9b4405b993d290e2e04e3baef6751 # timeout=10
> No emails were triggered.
> [Solr-reference-guide-6.x] $ /bin/bash -xe /tmp/hudson4569023647973112020.sh
> + echo 'Set ruby path to avoid writing to /usr directory'
> Set ruby path to avoid writing to /usr directory
> + export RUBY_PATH=/home/jenkins/shared/.rvm
> + RUBY_PATH=/home/jenkins/shared/.rvm
> + export GEM_HOME=/home/jenkins/shared/.rvm/gems
> + GEM_HOME=/home/jenkins/shared/.rvm/gems
> + curl -sSL https://get.rvm.io
> + bash -s -- --path /home/jenkins/shared/.rvm
> Downloading https://github.com/rvm/rvm/archive/master.tar.gz
>
> Upgrading the RVM installation in /home/jenkins/shared/.rvm/
>RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile
> /home/jenkins/.bashrc /home/jenkins/.zshrc.
>RVM sourcing line found in /home/jenkins/.profile
> /home/jenkins/.bash_profile /home/jenkins/.zlogin.
> Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
>
> # jenkins,
> #
> # Thank you for using RVM!
> # We sincerely hope that RVM helps to make your life easier and more
> enjoyable!!!
> #
> # ~Wayne, Michal & team.
>
> In case of problems: https://rvm.io/help and https://twitter.com/rvm_io
>
> Upgrade Notes:
>
> * It looks like some old stuff is laying around RVM, you can cleanup with:
> rvm cleanup all
>
> * No new notes to display.
>
> + mkdir -p /home/jenkins/shared/.rvm/gems/gems
> + gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll
> jekyll-asciidoc pygments.rb
> Successfully installed jekyll-3.4.3
> Successfully installed jekyll-asciidoc-2.1.0
> Successfully installed pygments.rb-1.1.2
> 3 gems installed
> + export
> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
> +
> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
> + cd solr/solr-ref-guide
> + ant clean build-pdf build-site
> Buildfile:
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x/solr/solr-ref-guide/build.xml
>
> clean:
>
> build-init:
>[mkdir] Created dir:
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x/solr/build/solr-ref-guide/content
> [echo] Copying all non template files from src ...
> [copy] Copying 343 files to
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x/solr/build/solr-ref-guide/content
> [echo] Copy (w/prop replacement) any template files from src...
> [copy] Copying 1 file to
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x/solr/build/solr-ref-guide/content
>
> ivy-availability-check:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 ::
> http://ant.apache.org/ivy/ ::
> [ivy:configure] :: loading settings :: file =
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x/lucene/top-level-ivy-settings.xml
>
> resolve:
> [ivy:retrieve]
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve] ERRORS
> [ivy:retrieve]unknown resolver null
> [ivy:retrieve]unknown resolver null
> [ivy:retrieve]unknown resolver null
> [ivy:retrieve]unknown resolver null
> [ivy:retrieve]unknown resolver null
> [ivy:retrieve]unknown resolver null
> [ivy:retrieve]
> [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
>
> build-tools-jar:
>[mkdir] Created dir:
> /home/jen
[jira] [Updated] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-10735:
Attachment: SOLR-10735.patch
I've tried putting quotes around the Solr command in the SolrCLI place which
Jan pointed to, and it works for me. So, if that works for Uwe as well, we're
all good. The patch for branch_6_6 is attached.
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png, SOLR-10735.patch
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[ https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026833#comment-16026833 ] ASF subversion and git services commented on SOLR-10758: Commit 4e32ab35f98d2933aec708af387a7eed02e02792 in lucene-solr's branch refs/heads/branch_6x from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4e32ab3 ] SOLR-10758: fix broken internal link to new HMM Chinese Tokenizer section > Modernize the Solr ref guide's Chinese language analysis coverage > - > > Key: SOLR-10758 > URL: https://issues.apache.org/jira/browse/SOLR-10758 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10758.patch > > > The Chinese analysis coverage in the ref guide is out of date. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[ https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026834#comment-16026834 ] ASF subversion and git services commented on SOLR-10758: Commit 9fbc9db1c17d9fe5a7281f89a4bb18e18f38fceb in lucene-solr's branch refs/heads/master from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9fbc9db ] SOLR-10758: fix broken internal link to new HMM Chinese Tokenizer section > Modernize the Solr ref guide's Chinese language analysis coverage > - > > Key: SOLR-10758 > URL: https://issues.apache.org/jira/browse/SOLR-10758 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10758.patch > > > The Chinese analysis coverage in the ref guide is out of date. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026821#comment-16026821
]
Tomás Fernández Löbbe commented on SOLR-10735:
--
Same here, tested with Windows 10 Home on "C:\Users\Tomas Fernandez
Lobb\Downloads\solr-6.6.0" and it worked for me. Not sure what's going on.
bq. Instead of ugly string magic we should use CommandLine.addArgument() or JRE
builtin launcher..
+1, but how do we test? Only Uwe was able to reproduce so far, any ideas why?
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026811#comment-16026811
]
Jan Høydahl commented on SOLR-10735:
I think this is the offender:
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L2944
On normal solr start {{-script}} is not passed. but for example it is, and as u
can see, not quoted.
Instead of ugly string magic we should use {{CommandLine.addArgument()}} or JRE
builtin launcher..
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Solr-reference-guide-6.x - Build # 16 - Failure
Build: https://builds.apache.org/job/Solr-reference-guide-6.x/16/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H19 (git-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url git://git.apache.org/lucene-solr.git #
> timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress git://git.apache.org/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/branch_6x^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/branch_6x^{commit} # timeout=10
Checking out Revision 1e6ef417549f45c815d99291f085f2319b54b4fa
(refs/remotes/origin/branch_6x)
> git config core.sparsecheckout # timeout=10
> git checkout -f 1e6ef417549f45c815d99291f085f2319b54b4fa
> git rev-list 1968c67790b9b4405b993d290e2e04e3baef6751 # timeout=10
No emails were triggered.
[Solr-reference-guide-6.x] $ /bin/bash -xe /tmp/hudson4569023647973112020.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s -- --path /home/jenkins/shared/.rvm
Downloading https://github.com/rvm/rvm/archive/master.tar.gz
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
# jenkins,
#
# Thank you for using RVM!
# We sincerely hope that RVM helps to make your life easier and more
enjoyable!!!
#
# ~Wayne, Michal & team.
In case of problems: https://rvm.io/help and https://twitter.com/rvm_io
Upgrade Notes:
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
* No new notes to display.
+ mkdir -p /home/jenkins/shared/.rvm/gems/gems
+ gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll
jekyll-asciidoc pygments.rb
Successfully installed jekyll-3.4.3
Successfully installed jekyll-asciidoc-2.1.0
Successfully installed pygments.rb-1.1.2
3 gems installed
+ export
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ cd solr/solr-ref-guide
+ ant clean build-pdf build-site
Buildfile:
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x/solr/solr-ref-guide/build.xml
clean:
build-init:
[mkdir] Created dir:
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x/solr/build/solr-ref-guide/content
[echo] Copying all non template files from src ...
[copy] Copying 343 files to
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x/solr/build/solr-ref-guide/content
[echo] Copy (w/prop replacement) any template files from src...
[copy] Copying 1 file to
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x/solr/build/solr-ref-guide/content
ivy-availability-check:
ivy-fail:
ivy-configure:
[ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 ::
http://ant.apache.org/ivy/ ::
[ivy:configure] :: loading settings :: file =
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x/lucene/top-level-ivy-settings.xml
resolve:
[ivy:retrieve]
[ivy:retrieve] :: problems summary ::
[ivy:retrieve] ERRORS
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver null
[ivy:retrieve]
[ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
build-tools-jar:
[mkdir] Created dir:
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x/solr/build/solr-ref-guide/classes
[javac] Compiling 3 source files to
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x/solr/build/solr-ref-guide/classes
[jar] Building jar:
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.x/solr/build/solr-ref-guide/solr-ref-guide-tools.jar
build-nav-data-files:
[java] Building up tree of all known pages
[java] Creating
/home/jenkins/jenkins-sla
[jira] [Commented] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026798#comment-16026798
]
Ishan Chattopadhyaya commented on SOLR-10735:
-
My E: is an NTFS drive. Could it be that some other filesystem (FAT32) could be
causing problems?
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026796#comment-16026796
]
Ishan Chattopadhyaya commented on SOLR-10735:
-
Same as above when I try this using the RC3 zip file.
Uwe, what do you think we should do? Is there a quick fix that you propose that
we can make (to the solr.cmd) to make it work for users who might be facing
issues like you are facing?
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-10735:
Attachment: Screenshot from 2017-05-27 01-49-43.png
It worked fine for me with for the path similar to Uwe's. I'm on Windows 10.
!Screenshot from 2017-05-27 01-49-43.png!
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png, Screenshot from
> 2017-05-27 01-49-43.png
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7845) spatial RPT optimization when query by point or common date range
[ https://issues.apache.org/jira/browse/LUCENE-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved LUCENE-7845. -- Resolution: Fixed > spatial RPT optimization when query by point or common date range > - > > Key: LUCENE-7845 > URL: https://issues.apache.org/jira/browse/LUCENE-7845 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: David Smiley >Assignee: David Smiley > Fix For: master (7.0) > > Attachments: LUCENE_7845_query_by_point_optimization.patch > > > If the query to an RPT index is a 2D point, or if using > NumerBrangePrefixTreeStrategy / DateRangePrefixTree (Solr DateRangeField) if > the query is a grid cell (a common date range unit like some particular day), > then we can do some optimizations, especially if the data is pointsOnly. If > the data is pointsOnly the strategy can return a TermQuery, if the data isn't > then we can at least tweak the prefixGridScanLevel. This is motivated by two > scenarios: > * indexing polygons and doing lookups by a point (AKA reverse geocoding) > * indexing date instances and doing date range faceting. Solr's code for this > has a fast path for a TermQuery, although more is needed beyond this issue to > get there. > _This development was funded by the Harvard Center for Geographic Analysis as > part of the HHypermap project_ -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-7838) Add a knn classifier based on fuzzy like this
[ https://issues.apache.org/jira/browse/LUCENE-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley reopened LUCENE-7838: -- Ah... you added a dependency on the sandbox module from another module. That's quite surprising to me... I don't think that's legit? New inter-module dependencies (of any kind) I think should also deserve communication on the JIRA issue and I don't see any mention here. I also don't see a CHANGES.txt entry. I don't see a patch file either but I admit I welcome that :-) > Add a knn classifier based on fuzzy like this > - > > Key: LUCENE-7838 > URL: https://issues.apache.org/jira/browse/LUCENE-7838 > Project: Lucene - Core > Issue Type: Bug > Components: modules/classification >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: master (7.0) > > > FLT mixes fuzzy and MLT, in the context of Lucene based classification it > might be useful to add such a fuzziness to a dedicated KNN classifier (based > on FLT queries). -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[ https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026758#comment-16026758 ] ASF subversion and git services commented on SOLR-10758: Commit 1e6ef417549f45c815d99291f085f2319b54b4fa in lucene-solr's branch refs/heads/branch_6x from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1e6ef41 ] SOLR-10758: Point to Lib Directives in SolrConfig page from the Traditional Chinese ICUTokenizer paragraph. > Modernize the Solr ref guide's Chinese language analysis coverage > - > > Key: SOLR-10758 > URL: https://issues.apache.org/jira/browse/SOLR-10758 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10758.patch > > > The Chinese analysis coverage in the ref guide is out of date. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[ https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026759#comment-16026759 ] ASF subversion and git services commented on SOLR-10758: Commit 6bbdfbc7c1b64a4ad399509c4d77b30741c5845c in lucene-solr's branch refs/heads/master from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6bbdfbc ] SOLR-10758: Point to Lib Directives in SolrConfig page from the Traditional Chinese ICUTokenizer paragraph. > Modernize the Solr ref guide's Chinese language analysis coverage > - > > Key: SOLR-10758 > URL: https://issues.apache.org/jira/browse/SOLR-10758 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10758.patch > > > The Chinese analysis coverage in the ref guide is out of date. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7845) spatial RPT optimization when query by point or common date range
[ https://issues.apache.org/jira/browse/LUCENE-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026752#comment-16026752 ] ASF subversion and git services commented on LUCENE-7845: - Commit d4f87b4a36ca50c4361d7ec4e0858b18d9eaebe8 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d4f87b4 ] LUCENE-7845: RPT query by point (or simple date interval) optimization > spatial RPT optimization when query by point or common date range > - > > Key: LUCENE-7845 > URL: https://issues.apache.org/jira/browse/LUCENE-7845 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: David Smiley >Assignee: David Smiley > Fix For: master (7.0) > > Attachments: LUCENE_7845_query_by_point_optimization.patch > > > If the query to an RPT index is a 2D point, or if using > NumerBrangePrefixTreeStrategy / DateRangePrefixTree (Solr DateRangeField) if > the query is a grid cell (a common date range unit like some particular day), > then we can do some optimizations, especially if the data is pointsOnly. If > the data is pointsOnly the strategy can return a TermQuery, if the data isn't > then we can at least tweak the prefixGridScanLevel. This is motivated by two > scenarios: > * indexing polygons and doing lookups by a point (AKA reverse geocoding) > * indexing date instances and doing date range faceting. Solr's code for this > has a fast path for a TermQuery, although more is needed beyond this issue to > get there. > _This development was funded by the Harvard Center for Geographic Analysis as > part of the HHypermap project_ -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10749) Should ref guide asciidoc files' line length be limited?
[
https://issues.apache.org/jira/browse/SOLR-10749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026751#comment-16026751
]
Steve Rowe commented on SOLR-10749:
---
Now that I know where the setting is, toggling soft wraps in IntelliJ takes
like 5 seconds, and the experience is very smooth: whole words begin on the
next line, as opposed to being broken in the middle; and the JavaFX-based
preview alignment is maintained automatically.
I'm guessing [~ctargett] wants to avoid the need for constant line length
adjustment busy-work, which could easily dwarf the amount of time it takes to
turn on soft wrapping.
bq. And I practically never (not even once a year) have to use this IDE feature
otherwise in my work.
Yeah that was my motivation for the changes I initially made on SOLR-10379, but
now that we're all going to be regular ref guide contributors, I'm guessing
that the frequency with which we need to do this will increase to the point
that it won't feel like a burden.
> Should ref guide asciidoc files' line length be limited?
>
>
> Key: SOLR-10749
> URL: https://issues.apache.org/jira/browse/SOLR-10749
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Minor
>
> From [~dsmiley] and [~janhoy] on SOLR-10290:
> {quote}
> David: Can we auto-linewrap the asciidoc content we've imported somehow? The
> lines are super-long in my IDE (IntelliJ). I can toggle the active editor's
> "soft wrap" at least (View menu, then Active Editor menu).
> Jan: Yea, those lines are long
> {quote}
> From a conversation [~ctargett] and I had on SOLR-10379:
> {quote}
> Steve: I updated the ref guide docs. While I was at it, I installed and used
> the IntelliJ plugin named "Wrap To Column" to wrap at 120 chars (a.k.a. "fill
> paragraph") in the two .adoc files I edited.
> Cassandra: What is the point of this, or even, the big deal about asking your
> IDE to do soft wraps instead?
> Steve: Not all editors support soft-wrapping. There is project consensus to
> wrap code at 120-chars; why make an exception for these doc files?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10755) delete/refactor (most) solrj deprecations on master
[ https://issues.apache.org/jira/browse/SOLR-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-10755: Attachment: SOLR-10755.patch i've updated the SolrTestCaseJ4 javadocs to be more explicit about the possible randomization of the clients (the CloudSolrClient methods already have this possibility for where they route updates) plan on commiting to master later today unless there are objections > delete/refactor (most) solrj deprecations on master > --- > > Key: SOLR-10755 > URL: https://issues.apache.org/jira/browse/SOLR-10755 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Blocker > Fix For: master (7.0) > > Attachments: SOLR-10755.patch, SOLR-10755.patch, SOLR-10755.patch, > SOLR-10755.patch > > > using this issue to track some work i've done to cleanup deprecations in > solrj for master (7.0) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10753) Add array Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026698#comment-16026698
]
Hoss Man commented on SOLR-10753:
-
hmmm... ok, sorry for the noise ... not sure what happened.
> Add array Stream Evaluator
> --
>
> Key: SOLR-10753
> URL: https://issues.apache.org/jira/browse/SOLR-10753
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10753.patch
>
>
> The *array* Stream Evaluator returns an array of numbers. It can contain
> numbers and evaluators that return numbers.
> Syntax:
> {code}
> a = array(1, 2, 3, 4, 5, 6)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10751) Master/Slave IndexVersion conflict
[
https://issues.apache.org/jira/browse/SOLR-10751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026695#comment-16026695
]
Tomás Fernández Löbbe commented on SOLR-10751:
--
OK, I see now why this hasn't been a problem so far. Note that the "delete my
index" only happens in case of a "forced replication". Forced replications in
Master/Slave can only happen in a retry, which should not happen if the master
is returning version 0 (unless I'm misunderstanding something here, this code
should never be executed if you are running Master/Slave). In SolrCloud mode, a
forced replication can happen if the last attempt to replicate was
unsuccessful. Until now the replication in SolrCloud was only for recovery, and
Cloud mode it's "OK" to have different versions of the index, plus, in the
particular test example I described in the issue, the replication would have
been followed by the application of the buffered updates, so indices would be
soon in sync. This becomes an issue only now that we have TLOG and PULL
replicas.
In any case, we need to fix it now for the new scenario. I also like your #2
option (#1 sounds like too big of a change), and It should be easy to
implement, although NRT replicas still need this logic I believe.
> Master/Slave IndexVersion conflict
> --
>
> Key: SOLR-10751
> URL: https://issues.apache.org/jira/browse/SOLR-10751
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (7.0)
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10751.patch
>
>
> I’ve been looking at some failures in the replica types tests. One strange
> failure I noticed is, master and slave share the same version, but have
> different generation. The IndexFetcher code does more or less this:
> {code}
> masterVersion = fetchMasterVersion()
> masterGeneration = fetchMasterGeneration()
> if (masterVersion == 0 && slaveGeneration != 0 && forceReplication) {
>delete my index
>commit locally
>return
> }
> if (masterVersion != slaveVersion) {
> fetchIndexFromMaster(masterGeneration)
> } else {
> //do nothing, master and slave are in sync.
> }
> {code}
> The problem I see happens with this sequence of events:
> delete index in master (not a DBQ=*:*, I mean a complete removal of the index
> files and reload of the core)
> replication happens in slave (sees a version 0, deletes local index and
> commit)
> add document in master and commit
> if the commit in master and in the slave happen at the same millisecond*,
> they both end up with the same version, but different indices.
> I think that in addition of checking for the same version, we should validate
> that slave and master have the same generation and If not, consider them not
> in sync, and proceed to the replication.
> True, this is a situation that's difficult to happen in a real prod
> environment and it's more likely to affect tests, but I think the change
> makes sense.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10753) Add array Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026681#comment-16026681
]
Joel Bernstein commented on SOLR-10753:
---
I committed a fix for this a little while back. It should be working fine in
master now.
> Add array Stream Evaluator
> --
>
> Key: SOLR-10753
> URL: https://issues.apache.org/jira/browse/SOLR-10753
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10753.patch
>
>
> The *array* Stream Evaluator returns an array of numbers. It can contain
> numbers and evaluators that return numbers.
> Syntax:
> {code}
> a = array(1, 2, 3, 4, 5, 6)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 6.6.0 RC3
Ishan, If there is a respin, I’d like to include SOLR-10758 (updates Chinese analysis in the Solr ref guide, and includes a Lucene test addition in the analysis/icu module). -- Steve www.lucidworks.com > On May 26, 2017, at 12:45 PM, Ishan Chattopadhyaya > wrote: > > Not sure if half of Windows users have spaces in their home directory. If > someone marks SOLR-10735 as a blocker and/or provides a fix, I'll be happy to > re-spin. > > On Fri, May 26, 2017 at 9:55 PM, Tomas Fernandez Lobbe > wrote: > I didn’t try this myself yet (just got a Windows machine to try it), but > looking at Uwe’s comment here[1], I think this should be a blocker, half > Windows users won’t be able to run the example. > > > [1] > https://issues.apache.org/jira/browse/SOLR-10735?focusedCommentId=16026393&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16026393 > >> On May 26, 2017, at 8:34 AM, Ishan Chattopadhyaya >> wrote: >> >> Uwe, do you think this is a blocker? >> >> On Fri, May 26, 2017 at 8:43 PM, Uwe Schindler wrote: >> Hi, >> >> >> >> on my computer, the Solr one still does not start -see the whitespace in >> directory name (my user name): >> >> >> >> C:\Users\Uwe Schindler\Desktop\solr-6.6.0\bin>solr.cmd start -e techproducts >> >> Creating Solr home directory C:\Users\Uwe >> Schindler\Desktop\solr-6.6.0\example\techproducts\solr >> >> >> >> Starting up Solr on port 8983 using command: >> >> C:\Users\Uwe Schindler\Desktop\solr-6.6.0\bin\solr.cmd start -p 8983 -s >> "C:\Users\Uwe Schindler\Desktop\solr-6.6.0\example\techproducts\solr" >> >> >> >> >> >> ERROR: Failed to start Solr using command: C:\Users\Uwe >> Schindler\Desktop\solr-6.6.0\bin\solr.cmd start -p 8983 -s "C:\Users\Uwe >> Schindler\Desktop\solr-6.6.0\example\techproducts\solr" Exception : >> org.apache.commons.exec.ExecuteException: Execution failed (Exit value: >> -559038737. Caused by java.io.IOException: Cannot run program "C:\Users\Uwe" >> (in directory "."): CreateProcess error=193, %1 ist keine zulässige >> Win32-Anwendung) >> >> >> >> >> >> C:\Users\Uwe Schindler\Desktop\solr-6.6.0\bin> >> >> >> >> I will post this to the issue. Starting Solr without example works, but you >> then have no core to quickly do tests. >> >> >> >> FYI, I added a Linux and Windows build of branch_6_6 to Policeman Jenkins a >> minute ago. >> >> >> >> Uwe >> >> >> >> - >> >> Uwe Schindler >> >> Achterdiek 19, D-28357 Bremen >> >> http://www.thetaphi.de >> >> eMail: u...@thetaphi.de >> >> >> >> From: Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com] >> Sent: Friday, May 26, 2017 9:43 AM >> To: dev@lucene.apache.org >> Subject: [VOTE] Release Lucene/Solr 6.6.0 RC3 >> >> >> >> Please vote for release candidate 3 for Lucene/Solr 6.6.0 >> >> The artifacts can be downloaded from: >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC3-revbfb1ee42b2edbc2f2dea49b9d0e3201069d6e781 >> >> You can run the smoke tester directly with this command: >> >> python3 -u dev-tools/scripts/smokeTestRelease.py \ >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC3-revbfb1ee42b2edbc2f2dea49b9d0e3201069d6e781 >> >> Here's my +1 >> SUCCESS! [1:16:00.055493] >> > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[ https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe resolved SOLR-10758. --- Resolution: Fixed Assignee: Steve Rowe Fix Version/s: 6.7 master (7.0) > Modernize the Solr ref guide's Chinese language analysis coverage > - > > Key: SOLR-10758 > URL: https://issues.apache.org/jira/browse/SOLR-10758 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10758.patch > > > The Chinese analysis coverage in the ref guide is out of date. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[ https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026667#comment-16026667 ] ASF subversion and git services commented on SOLR-10758: Commit b23aab5482f109d6c70470e1902d9e61474aeb1c in lucene-solr's branch refs/heads/master from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b23aab5 ] SOLR-10758: Modernize the Solr ref guide's Chinese language analysis coverage > Modernize the Solr ref guide's Chinese language analysis coverage > - > > Key: SOLR-10758 > URL: https://issues.apache.org/jira/browse/SOLR-10758 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe > Attachments: SOLR-10758.patch > > > The Chinese analysis coverage in the ref guide is out of date. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[ https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1602#comment-1602 ] ASF subversion and git services commented on SOLR-10758: Commit 1c7a6c16f1656cd6aaddbb1aa67791bed006846e in lucene-solr's branch refs/heads/branch_6x from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1c7a6c1 ] SOLR-10758: Modernize the Solr ref guide's Chinese language analysis coverage > Modernize the Solr ref guide's Chinese language analysis coverage > - > > Key: SOLR-10758 > URL: https://issues.apache.org/jira/browse/SOLR-10758 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe > Attachments: SOLR-10758.patch > > > The Chinese analysis coverage in the ref guide is out of date. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS] Lucene-Solr-master-Windows () - Build # 6592 - Failure!
Sorry, my fault when adding Java 9 EA to Windows. Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de] > Sent: Friday, May 26, 2017 8:41 PM > To: dev@lucene.apache.org > Subject: [JENKINS] Lucene-Solr-master-Windows () - Build # 6592 - Failure! > > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6592/ > Java: > > No tests ran. > > Build Log: > [...truncated 6 lines...] > ERROR: SEVERE ERROR occurs > org.jenkinsci.lib.envinject.EnvInjectException: Failed to evaluate the script > at > org.jenkinsci.plugins.envinject.service.EnvInjectEnvVars.executeGroovyScript > (EnvInjectEnvVars.java:232) > at > org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironmentJobProper > tyObject(EnvInjectListener.java:188) > at > org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironment(EnvInject > Listener.java:48) > at > hudson.model.AbstractBuild$AbstractBuildExecution.createLauncher(Abstra > ctBuild.java:528) > at > hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java: > 448) > at hudson.model.Run.execute(Run.java:1735) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) > at > hudson.model.ResourceController.execute(ResourceController.java:97) > at hudson.model.Executor.run(Executor.java:415) > Caused by: groovy.lang.MissingPropertyException: No such property: > jdk9ClientExtraArgs for class: windows-random-java8 > at > org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecode > Adapter.java:53) > at > org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(Pogo > GetPropertySite.java:52) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetPr > operty(AbstractCallSite.java:307) > at windows-random-java8.run(windows-random-java8.groovy:20) > at groovy.lang.GroovyShell.evaluate(GroovyShell.java:585) > at groovy.lang.GroovyShell.evaluate(GroovyShell.java:632) > at groovy.lang.Script.evaluate(Script.java:221) > at groovy.lang.Script$evaluate.callCurrent(Unknown Source) > at > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSit > eArray.java:52) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCal > lSite.java:154) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCal > lSite.java:166) > at Script1.run(Script1.groovy:1) > at groovy.lang.GroovyShell.evaluate(GroovyShell.java:585) > at groovy.lang.GroovyShell.evaluate(GroovyShell.java:623) > at groovy.lang.GroovyShell.evaluate(GroovyShell.java:594) > at > org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript.evalu > ate(SecureGroovyScript.java:170) > at > org.jenkinsci.plugins.envinject.service.EnvInjectEnvVars.executeGroovyScript > (EnvInjectEnvVars.java:230) > ... 8 more > ERROR: Step ‘Archive the artifacts’ failed: no workspace for Lucene-Solr- > master-Windows #6592 > ERROR: Step ‘Scan for compiler warnings’ failed: no workspace for Lucene- > Solr-master-Windows #6592 > ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for > Lucene-Solr-master-Windows #6592 > Email was triggered for: Failure - Any > Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.6-Windows () - Build # 2 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Windows/2/ Java: No tests ran. Build Log: [...truncated 10 lines...] ERROR: SEVERE ERROR occurs org.jenkinsci.lib.envinject.EnvInjectException: Failed to evaluate the script at org.jenkinsci.plugins.envinject.service.EnvInjectEnvVars.executeGroovyScript(EnvInjectEnvVars.java:232) at org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironmentJobPropertyObject(EnvInjectListener.java:188) at org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironment(EnvInjectListener.java:48) at hudson.model.AbstractBuild$AbstractBuildExecution.createLauncher(AbstractBuild.java:528) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:448) at hudson.model.Run.execute(Run.java:1735) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:415) Caused by: groovy.lang.MissingPropertyException: No such property: jdk9ClientExtraArgs for class: windows-random-java8 at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:53) at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:52) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:307) at windows-random-java8.run(windows-random-java8.groovy:20) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:585) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:632) at groovy.lang.Script.evaluate(Script.java:221) at groovy.lang.Script$evaluate.callCurrent(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:166) at Script1.run(Script1.groovy:1) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:585) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:623) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:594) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript.evaluate(SecureGroovyScript.java:170) at org.jenkinsci.plugins.envinject.service.EnvInjectEnvVars.executeGroovyScript(EnvInjectEnvVars.java:230) ... 8 more ERROR: Step ‘Archive the artifacts’ failed: no workspace for Lucene-Solr-6.6-Windows #2 ERROR: Step ‘Scan for compiler warnings’ failed: no workspace for Lucene-Solr-6.6-Windows #2 ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for Lucene-Solr-6.6-Windows #2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-Windows () - Build # 917 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/917/ Java: No tests ran. Build Log: [...truncated 8 lines...] ERROR: SEVERE ERROR occurs org.jenkinsci.lib.envinject.EnvInjectException: Failed to evaluate the script at org.jenkinsci.plugins.envinject.service.EnvInjectEnvVars.executeGroovyScript(EnvInjectEnvVars.java:232) at org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironmentJobPropertyObject(EnvInjectListener.java:188) at org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironment(EnvInjectListener.java:48) at hudson.model.AbstractBuild$AbstractBuildExecution.createLauncher(AbstractBuild.java:528) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:448) at hudson.model.Run.execute(Run.java:1735) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:415) Caused by: groovy.lang.MissingPropertyException: No such property: jdk9ClientExtraArgs for class: windows-random-java8 at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:53) at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:52) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:307) at windows-random-java8.run(windows-random-java8.groovy:20) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:585) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:632) at groovy.lang.Script.evaluate(Script.java:221) at groovy.lang.Script$evaluate.callCurrent(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:166) at Script1.run(Script1.groovy:1) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:585) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:623) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:594) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript.evaluate(SecureGroovyScript.java:170) at org.jenkinsci.plugins.envinject.service.EnvInjectEnvVars.executeGroovyScript(EnvInjectEnvVars.java:230) ... 8 more ERROR: Step ‘Archive the artifacts’ failed: no workspace for Lucene-Solr-6.x-Windows #917 ERROR: Step ‘Scan for compiler warnings’ failed: no workspace for Lucene-Solr-6.x-Windows #917 ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for Lucene-Solr-6.x-Windows #917 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows () - Build # 6592 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6592/ Java: No tests ran. Build Log: [...truncated 6 lines...] ERROR: SEVERE ERROR occurs org.jenkinsci.lib.envinject.EnvInjectException: Failed to evaluate the script at org.jenkinsci.plugins.envinject.service.EnvInjectEnvVars.executeGroovyScript(EnvInjectEnvVars.java:232) at org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironmentJobPropertyObject(EnvInjectListener.java:188) at org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironment(EnvInjectListener.java:48) at hudson.model.AbstractBuild$AbstractBuildExecution.createLauncher(AbstractBuild.java:528) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:448) at hudson.model.Run.execute(Run.java:1735) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:415) Caused by: groovy.lang.MissingPropertyException: No such property: jdk9ClientExtraArgs for class: windows-random-java8 at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:53) at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:52) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:307) at windows-random-java8.run(windows-random-java8.groovy:20) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:585) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:632) at groovy.lang.Script.evaluate(Script.java:221) at groovy.lang.Script$evaluate.callCurrent(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:166) at Script1.run(Script1.groovy:1) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:585) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:623) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:594) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript.evaluate(SecureGroovyScript.java:170) at org.jenkinsci.plugins.envinject.service.EnvInjectEnvVars.executeGroovyScript(EnvInjectEnvVars.java:230) ... 8 more ERROR: Step ‘Archive the artifacts’ failed: no workspace for Lucene-Solr-master-Windows #6592 ERROR: Step ‘Scan for compiler warnings’ failed: no workspace for Lucene-Solr-master-Windows #6592 ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for Lucene-Solr-master-Windows #6592 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4031 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4031/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.solr.cloud.ReplaceNodeTest.test Error Message: Error from server at http://127.0.0.1:57310/solr: create the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:57310/solr: create the collection time out:180s at __randomizedtesting.SeedInfo.seed([35A315C212BE37E:8B0E0E868FD78E86]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:281) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:270) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:481) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:411) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1398) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1139) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1074) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.ReplaceNodeTest.test(ReplaceNodeTest.java:74) 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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) 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:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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(TestRuleAssertionsRequi
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+168) - Build # 19716 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19716/
Java: 64bit/jdk-9-ea+168 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC
3 tests failed.
FAILED: org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testArray
Error Message:
Stack Trace:
java.lang.NullPointerException
at
__randomizedtesting.SeedInfo.seed([E1550964D681674A:47734100E0D95525]:0)
at
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testArray(StreamExpressionTest.java:5751)
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:563)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
FAILED: org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test
Error Message:
Expected 2 of 3 replicas to be active but only found 1;
[core_node2:{"core":"c8n_1x3_lf_shard1_replica_n1","base_url":"http://127.0.0.1:42287/wpk/r","node_name":"127.0.0.1:42287_wpk%2Fr","state":"active","type":"NRT","leader":"true"}];
clusterState:
DocCollection(c8n_1x3_lf//collections/c8n_1x3_lf/state.json/17)={
"pullReplicas":"0", "replicationFactor":
[jira] [Commented] (LUCENE-7854) Indexing custom term frequencies
[
https://issues.apache.org/jira/browse/LUCENE-7854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026639#comment-16026639
]
Uwe Schindler commented on LUCENE-7854:
---
Finally we get this. Great work. Just this morning I was thinking about this. I
have a current customer who needs this. The only way how they can do it is term
repetition.
I will look into the patch later, I am looking forward to see this fixed. We
just need some additional Timely that can be used in Solr to give the numbers
in the terms like we do for the payload case.
> Indexing custom term frequencies
>
>
> Key: LUCENE-7854
> URL: https://issues.apache.org/jira/browse/LUCENE-7854
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: LUCENE-7854.patch
>
>
> When you index a field with {{IndexOptions.DOCS_AND_FREQS}}, Lucene will
> store just the docID and term frequency (how many times that term occurred in
> that document) for all documents that have a given term.
> We compute that term frequency by counting how many times a given token
> appeared in the field during analysis.
> But it can be useful, in expert use cases, to customize what Lucene stores as
> the term frequency, e.g. to hold custom scoring signals that are a function
> of term and document (this is my use case). Users have also asked for this
> before, e.g. see
> https://stackoverflow.com/questions/26605090/lucene-overwrite-term-frequency-at-index-time.
> One way to do this today is to stuff your custom data into a {{byte[]}}
> payload. But that's quite inefficient, forcing you to index positions, and
> pay the overhead of retrieving payloads at search time.
> Another approach is "token stuffing": just enumerate the same token N times
> where N is the custom number you want to store, but that's also inefficient
> when N gets high.
> I think we can make this simple to do in Lucene. I have a working version,
> using my own custom indexing chain, but the required changes are quite simple
> so I think we can add it to Lucene's default indexing chain?
> I created a new token attribute, {{TermDocFrequencyAttribute}}, and tweaked
> the indexing chain to use that attribute's value as the term frequency if
> it's present, and if the index options are {{DOCS_AND_FREQS}} for that field.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10753) Add array Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026636#comment-16026636
]
Hoss Man commented on SOLR-10753:
-
following fails reliably with NPE...
{noformat}
ant test -Dtestcase=StreamExpressionTest -Dtests.method=testArray
-Dtests.seed=FF67716FF72EA807 -Dtests.slow=true -Dtests.locale=hu-HU
-Dtests.timezone=PNT -Dtests.asserts=true -Dtests.file.encoding=UTF-8
...
[junit4] ERROR 0.16s | StreamExpressionTest.testArray <<<
[junit4]> Throwable #1: java.lang.NullPointerException
[junit4]>at
__randomizedtesting.SeedInfo.seed([FF67716FF72EA807:5941390BC1769A68]:0)
[junit4]>at
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testArray(StreamExpressionTest.java:5751)
[junit4]>at java.lang.Thread.run(Thread.java:745)
{noformat}
Seed doesn't seem to matter, same failure reproduces for this test method any
way i try it.
> Add array Stream Evaluator
> --
>
> Key: SOLR-10753
> URL: https://issues.apache.org/jira/browse/SOLR-10753
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10753.patch
>
>
> The *array* Stream Evaluator returns an array of numbers. It can contain
> numbers and evaluators that return numbers.
> Syntax:
> {code}
> a = array(1, 2, 3, 4, 5, 6)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7854) Indexing custom term frequencies
[
https://issues.apache.org/jira/browse/LUCENE-7854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026630#comment-16026630
]
Mike Sokolov commented on LUCENE-7854:
--
I had wanted this in the past for indexing collaborative filtering similarity
scores as a sparse matrix. In that case, say you want to index
document-document similarity, basically some function SIM(doc1,doc2). The full
matrix is too enormous to store, so you only record the top N most similar
docs. One way to store this is to index the LHS in one field, and all the
related document ids as terms in another field. Then you can use Lucene's
queries to perform weighted averages if you several documents and so on, as
well as mixing with other term constraints, but you really want to manipulate
the frequencies in order to represent the SIM function.
> Indexing custom term frequencies
>
>
> Key: LUCENE-7854
> URL: https://issues.apache.org/jira/browse/LUCENE-7854
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: LUCENE-7854.patch
>
>
> When you index a field with {{IndexOptions.DOCS_AND_FREQS}}, Lucene will
> store just the docID and term frequency (how many times that term occurred in
> that document) for all documents that have a given term.
> We compute that term frequency by counting how many times a given token
> appeared in the field during analysis.
> But it can be useful, in expert use cases, to customize what Lucene stores as
> the term frequency, e.g. to hold custom scoring signals that are a function
> of term and document (this is my use case). Users have also asked for this
> before, e.g. see
> https://stackoverflow.com/questions/26605090/lucene-overwrite-term-frequency-at-index-time.
> One way to do this today is to stuff your custom data into a {{byte[]}}
> payload. But that's quite inefficient, forcing you to index positions, and
> pay the overhead of retrieving payloads at search time.
> Another approach is "token stuffing": just enumerate the same token N times
> where N is the custom number you want to store, but that's also inefficient
> when N gets high.
> I think we can make this simple to do in Lucene. I have a working version,
> using my own custom indexing chain, but the required changes are quite simple
> so I think we can add it to Lucene's default indexing chain?
> I created a new token attribute, {{TermDocFrequencyAttribute}}, and tweaked
> the indexing chain to use that attribute's value as the term frequency if
> it's present, and if the index options are {{DOCS_AND_FREQS}} for that field.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Strange bug with 32 bit JDKs on Ubuntu 16.04 with Linux Kernel 4.8
Hi Rory, In addition to the Ubuntu bug, I started testing Java 9 EA on Windows VMs on our test server (at usual place: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/). Because of the inability to get a ZIP package without Windows Installer, I refuse to update this or maintain this for longer time, so please excuse that I am late. But as Java 9 GA gets close, I installed build 171 on Windows and running the usual tests. But I will not update to any later builds, as this is just too hard to do. To make this better in the future, please, please, please ask the Windows Maintainers to just provide ZIP or TARGZ images also for Windows (in addition to the Windows Installer). The damn installer makes maintenance hard! There is really no need to have a windows installer to run the JDK for development purposes. This also makes updating the other JDKs hard. As there is no need for browser plugins anymore, why does it need an installer!??. Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Friday, May 26, 2017 7:37 PM > To: 'Rory O'Donnell' > Subject: Strange bug with 32 bit JDKs on Ubuntu 16.04 with Linux Kernel 4.8 > > Hi Rory, > > While installing the Jenkins test server on new hardware with latest Ubuntu > 16.04 LTS I figured out that the 32 bit JDKs (all of them, does not matter > which one: Java 7, Java 8, Java 9) fail to run. > I figured out that this is a bug in Linux kernel 4.8 (at least the Ubuntu > one). > With Linux 4.10 it works again. But by default Ubuntu 16.04 long term version > installs with Kernel 4.8. Of course 64bit JDKs work fine. Here is the bug: > > https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1693854 > > It would be good if you could forwards this to the right people/mailing > lists. It > basically breaks running 32bit Javas on 64bit Ubuntu operating systems with > Linux Kernel 4.8! I am 100% sure this is not Oracle's/OpenJDK's problem, but > maybe you should take place in this Ubuntu issue, as this may break many > people still running 32 bit browsers/32 bit webstarts. > > Uwe > > - > Uwe Schindler > Achterdiek 19, D-28357 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10755) delete/refactor (most) solrj deprecations on master
[ https://issues.apache.org/jira/browse/SOLR-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026623#comment-16026623 ] Hoss Man commented on SOLR-10755: - bq. It's a downer that they suffer the same downside that prompted the initial SolrClient ctor change though- the number of SolrClient parameters that can be provided/omitted causes us to end up with tons of these near-duplicate methods I don't view that as a downside ... these are convinience methods for tests that "don't care" about most of the particulars of their client -- giving us the flexibility to randomize them. if a test *does* care they can use the Builders directly (and many do) > delete/refactor (most) solrj deprecations on master > --- > > Key: SOLR-10755 > URL: https://issues.apache.org/jira/browse/SOLR-10755 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Blocker > Fix For: master (7.0) > > Attachments: SOLR-10755.patch, SOLR-10755.patch, SOLR-10755.patch > > > using this issue to track some work i've done to cleanup deprecations in > solrj for master (7.0) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10751) Master/Slave IndexVersion conflict
[
https://issues.apache.org/jira/browse/SOLR-10751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026620#comment-16026620
]
Hoss Man commented on SOLR-10751:
-
bq. so, "0" is not really the version of the index, but it's that the master
responds to the slaves when there is no replicable index.
And to elaborate on our IRC conversation, at the point where we were theorizing
why the master might return "0" (before tomas had found this particular bit of
code and verified it matched our theory) -- i posed the following straw man
suggestion(s) for dealing with this special "sentinal" value of "i have no
index"...
# We could change solr core/updateHanlder initialization so there is _never_ a
situation where a solr core is responding to requests, but has no index /
commitPoint -- thus completely eliminating the need for the sentinal value &
special case logic on slaves, because they will always have _something_ they
can fetch
#* ie: on startup, if no index, create & commit immediately
# we could "fix" the semantics of replication on the slave side...
#* if the master returns indexVersion==0, the slave treats that as a "master
has nothing to replicate, i should do nothing" (and possibly 'fail' if the
replication was explicitly requested vs/timmer based)
#* as opposed to current logic which is "master has nothing to replicate, i
will blindly create my own arbitrary index indepdent of master (via deleteAll)
I still think either one of these options would be a good idea -- depending on
what we want the semantics to be:
# Should a situation where an external force blows away the master index (or
someone forces a node w/o an index to be a leader) cause slaves/replicas to
*immediately* purge all data?
# Or should slaves/replicas keep what they've got until the master/leader
actually has something for them to replicate?
Personally i think #2 makes more sense.
As a practical example: Assume someone is doing classic master/slave
replication and their master has a hardware failure. the slaves are still
serving queries just fine. rather then swap out an existing slave to be the
new master the admin creates an entirely new serve to be the master and plans
on rebuilding the index -- but by reusing the master.company.com hostname, the
new node starts recieving /replication requests immediately from the existing
slaves. Should those slaves really be immediately deleting all docs from their
local indexes even though the master is explicitly telling them "i have nothing
for you to replicate" ? ... that sounds like a bug to me.
On the flip side: if chaos has rained down on a SolrCloud cluster, and a new
leader w/o any index at all has popped up -- i think it's "ok" for replicas to
serve stale data until the leader has new data for them ... but if think that
in the cloud case it's important that all replicas should _immediately_
"recover" the "theoretically empty if it did exist" version of the index from
their leader, then perhaps the leader election code should involve a special
case to force a commit on the leader if it has no existing commit points?
Either way, i *ALSO* have the vague impression that tomas's primary suggestion
of always checking generation is correct as well ... but it seems so obvious
i'm not sure if there is some good why the code doesn't already do that that
i'm oblivious too?
> Master/Slave IndexVersion conflict
> --
>
> Key: SOLR-10751
> URL: https://issues.apache.org/jira/browse/SOLR-10751
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (7.0)
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10751.patch
>
>
> I’ve been looking at some failures in the replica types tests. One strange
> failure I noticed is, master and slave share the same version, but have
> different generation. The IndexFetcher code does more or less this:
> {code}
> masterVersion = fetchMasterVersion()
> masterGeneration = fetchMasterGeneration()
> if (masterVersion == 0 && slaveGeneration != 0 && forceReplication) {
>delete my index
>commit locally
>return
> }
> if (masterVersion != slaveVersion) {
> fetchIndexFromMaster(masterGeneration)
> } else {
> //do nothing, master and slave are in sync.
> }
> {code}
> The problem I see happens with this sequence of events:
> delete index in master (not a DBQ=*:*, I mean a complete removal of the index
> files and reload of the core)
> replication happens in slave (sees a version 0, deletes local index and
> commit)
> add document in master and commit
> if the commit in master and in the slave happen at the same millisecond*,
> they both end up with the same version, but different indices.
> I thi
[jira] [Commented] (SOLR-10233) Add support for different replica types in Solr
[
https://issues.apache.org/jira/browse/SOLR-10233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026614#comment-16026614
]
Tomás Fernández Löbbe commented on SOLR-10233:
--
This Jenkins failure[1] may be related to this change. I'll take a look.
[1] https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19713/
> Add support for different replica types in Solr
> ---
>
> Key: SOLR-10233
> URL: https://issues.apache.org/jira/browse/SOLR-10233
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Fix For: master (7.0)
>
> Attachments: 11431.consoleText.txt, SOLR-10233.patch,
> SOLR-10233.patch, SOLR-10233.patch, SOLR-10233.patch, SOLR-10233.patch
>
>
> For the majority of the cases, current SolrCloud's distributed indexing is
> great. There is a subset of use cases for which the legacy Master/Slave
> replication may fit better:
> * Don’t require NRT
> * LIR can become an issue, prefer availability of reads vs consistency or NRT
> * High number of searches (requiring many search nodes)
> SOLR-9835 is adding replicas that don’t do indexing, just update their
> transaction log. This Jira is to extend that idea and provide the following
> replica types:
> * *Realtime:* Writes updates to transaction log and indexes locally. Replicas
> of type “realtime” support NRT (soft commits) and RTG. Any _realtime_ replica
> can become a leader. This is the only type supported in SolrCloud at this
> time and will be the default.
> * *Append:* Writes to transaction log, but not to index, uses replication.
> Any _append_ replica can become leader (by first applying all local
> transaction log elements). If a replica is of type _append_ but is also the
> leader, it will behave as a _realtime_. This is exactly what SOLR-9835 is
> proposing (non-live replicas)
> * *Passive:* Doesn’t index or writes to transaction log. Just replicates from
> _realtime_ or _append_ replicas. Passive replicas can’t become shard leaders
> (i.e., if there are only passive replicas in the collection at some point,
> updates will fail same as if there is no leaders, queries continue to work),
> so they don’t even participate in elections.
> When the leader replica of the shard receives an update, it will distribute
> it to all _realtime_ and _append_ replicas, the same as it does today. It
> won't distribute to _passive_ replicas.
> By using a combination of _append_ and _passive_ replicas, one can achieve an
> equivalent of the legacy Master/Slave architecture in SolrCloud mode with
> most of its benefits, including high availability of writes.
> h2. API (v1 style)
> {{/admin/collections?action=CREATE…&*realtimeReplicas=X&appendReplicas=Y&passiveReplicas=Z*}}
> {{/admin/collections?action=ADDREPLICA…&*type=\[realtime/append/passive\]*}}
> * “replicationFactor=” will translate to “realtime=“ for back compatibility
> * if _passive_ > 0, _append_ or _realtime_ need to be >= 1 (can’t be all
> passives)
> h2. Placement Strategies
> By using replica placement rules, one should be able to dedicate nodes to
> search-only and write-only workloads. For example:
> {code}
> shard:*,replica:*,type:passive,fleet:slaves
> {code}
> where “type” is a new condition supported by the rule engine, and
> “fleet:slaves” is a regular tag. Note that rules are only applied when the
> replicas are created, so a later change in tags won't affect existing
> replicas. Also, rules are per collection, so each collection could contain
> it's own different rules.
> Note that on the server side Solr also needs to know how to distribute the
> shard requests (maybe ShardHandler?) if we want to hit only a subset of
> replicas (i.e. *passive *replicas only, or similar rules)
> h2. SolrJ
> SolrCloud client could be smart to prefer _passive_ replicas for search
> requests when available (and if configured to do so). _Passive_ replicas
> can’t respond RTG requests, so those should go to _realtime_ replicas.
> h2. Cluster/Collection state
> {code}
> {"gettingstarted":{
> "replicationFactor":"1",
> "router":{"name":"compositeId"},
> "maxShardsPerNode":"2",
> "autoAddReplicas":"false",
> "shards":{
> "shard1":{
> "range":"8000-",
> "state":"active",
> "replicas":{
> "core_node5":{
> "core":"gettingstarted_shard1_replica1",
> "base_url":"http://127.0.0.1:8983/solr";,
> "node_name":"127.0.0.1:8983_solr",
> "state":"active",
> "leader":"true",
> **"type": "realtime"**},
> "core_node10":{
> "core":"gettingstarted_shard1_replica2",
> "
[jira] [Updated] (SOLR-10759) TestUseDocValuesAsStored sometimes fails
[
https://issues.apache.org/jira/browse/SOLR-10759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-10759:
-
Attachment: TestUseDocValuesAsStored.log
Full log for that same failure attached
> TestUseDocValuesAsStored sometimes fails
>
>
> Key: SOLR-10759
> URL: https://issues.apache.org/jira/browse/SOLR-10759
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomás Fernández Löbbe
> Attachments: TestUseDocValuesAsStored.log
>
>
> Here is the stacktrace of a failure in Jenkins
> {noformat}
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Linux/2/
> Java: 32bit/jdk-9-ea+168 -server -XX:+UseG1GC
> 1 tests failed.
> FAILED:
> org.apache.solr.schema.TestUseDocValuesAsStored.testMultipleSearchResults
> Error Message:
> mismatch: 'myid1'!='myid' @ response/docs/[0]/id
> Stack Trace:
> java.lang.RuntimeException: mismatch: 'myid1'!='myid' @ response/docs/[0]/id
> at
> __randomizedtesting.SeedInfo.seed([A1148D4E62AFDC3A:933E8AD09A51F8E3]:0)
> at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:983)
> at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:930)
> at
> org.apache.solr.schema.TestUseDocValuesAsStored.testMultipleSearchResults(TestUseDocValuesAsStored.java:243)
> 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:563)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
> 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:916)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
> 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
[jira] [Comment Edited] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[
https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026607#comment-16026607
]
Steve Rowe edited comment on SOLR-10758 at 5/26/17 6:05 PM:
Patch:
* On the Language Analysis page:
** Removes the CJK section, along with the no-longer-present CJKTokenizer.
** Renames the Chinese section to Traditional Chinese (there is already a
Simplified Chinese section).
** Adds coverage of {{CJKBigramFilter}}, linked to the Traditional Chinese
section when used with {{StandardTokenizer}}.
** Mentions the possibility of using the default {{ICUTokenizer}} configuration
with both Traditional and Simplified Chinese.
** Adds internal links from the Japanese section to the individual component
sections.
* Adds a test for Traditional Chinese to Lucene's {{TestICUTokenizerCJK}}.
I plan to commit as soon as precommit passes.
was (Author: steve_rowe):
Patch:
* On the Language Analysis page:
** Removes non-existent CJKTokenizer.
** Renames the Chinese section to Traditional Chinese (there is already a
Simplified Chinese section).
** Adds coverage of {{CJKBigramFilter}}, linked to the Traditional Chinese
section when used with {{StandardTokenizer}}.
** Mentions the possibility of using the default {{ICUTokenizer}} configuration
with both Traditional and Simplified Chinese.
** Adds internal links from the Japanese section to the individual component
sections.
* Adds a test for Traditional Chinese to Lucene's {{TestICUTokenizerCJK}}.
I plan to commit as soon as precommit passes.
> Modernize the Solr ref guide's Chinese language analysis coverage
> -
>
> Key: SOLR-10758
> URL: https://issues.apache.org/jira/browse/SOLR-10758
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-10758.patch
>
>
> The Chinese analysis coverage in the ref guide is out of date.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[
https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026607#comment-16026607
]
Steve Rowe edited comment on SOLR-10758 at 5/26/17 6:04 PM:
Patch:
* On the Language Analysis page:
** Removes non-existent CJKTokenizer.
** Renames the Chinese section to Traditional Chinese (there is already a
Simplified Chinese section).
** Adds coverage of {{CJKBigramFilter}}, linked to the Traditional Chinese
section when used with {{StandardTokenizer}}.
** Mentions the possibility of using the default {{ICUTokenizer}} configuration
with both Traditional and Simplified Chinese.
** Adds internal links from the Japanese section to the individual component
sections.
* Adds a test for Traditional Chinese to Lucene's {{TestICUTokenizerCJK}}.
I plan to commit as soon as precommit passes.
was (Author: steve_rowe):
Patch:
* On the Language Analysis page:
** Removes non-existent CJKTokenizer.
** Renames the Chinese section to Traditional Chinese (there is already a
Simplified Chinese section).
* Adds coverage of {{CJKBigramFilter}}, linked to the Traditional Chinese
section when used with {{StandardTokenizer}}.
* Mentions the possibility of using the default {{ICUTokenizer}} configuration
with both Traditional and Simplified Chinese.
* Adds internal links from the Japanese section to the individual component
sections.
* Adds a test for Traditional Chinese to Lucene's {{TestICUTokenizerCJK}}.
I plan to commit as soon as precommit passes.
> Modernize the Solr ref guide's Chinese language analysis coverage
> -
>
> Key: SOLR-10758
> URL: https://issues.apache.org/jira/browse/SOLR-10758
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-10758.patch
>
>
> The Chinese analysis coverage in the ref guide is out of date.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
[
https://issues.apache.org/jira/browse/SOLR-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-10758:
--
Attachment: SOLR-10758.patch
Patch:
* On the Language Analysis page:
** Removes non-existent CJKTokenizer.
** Renames the Chinese section to Traditional Chinese (there is already a
Simplified Chinese section).
* Adds coverage of {{CJKBigramFilter}}, linked to the Traditional Chinese
section when used with {{StandardTokenizer}}.
* Mentions the possibility of using the default {{ICUTokenizer}} configuration
with both Traditional and Simplified Chinese.
* Adds internal links from the Japanese section to the individual component
sections.
* Adds a test for Traditional Chinese to Lucene's {{TestICUTokenizerCJK}}.
I plan to commit as soon as precommit passes.
> Modernize the Solr ref guide's Chinese language analysis coverage
> -
>
> Key: SOLR-10758
> URL: https://issues.apache.org/jira/browse/SOLR-10758
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-10758.patch
>
>
> The Chinese analysis coverage in the ref guide is out of date.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10755) delete/refactor (most) solrj deprecations on master
[ https://issues.apache.org/jira/browse/SOLR-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026599#comment-16026599 ] Jason Gerlowski commented on SOLR-10755: > personally i think these methods provide a nice syntactic sugar in tests, and > give us wiggle room to add more testing of randomized client options in the > future You're right of course, they could provide value at some point. It's a downer that they suffer the same downside that prompted the initial SolrClient ctor change though- the number of SolrClient parameters that can be provided/omitted causes us to end up with tons of these near-duplicate methods. But if that doesn't bother anyone, it's fine with me. Just wanted to mention it as I created most of those methods initially and feel partially responsible for the mess I made :-p (Relatedly, I wish I'd known about SolrTestCaseJ4 being "external" back then, but you learn something new every day) > delete/refactor (most) solrj deprecations on master > --- > > Key: SOLR-10755 > URL: https://issues.apache.org/jira/browse/SOLR-10755 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Blocker > Fix For: master (7.0) > > Attachments: SOLR-10755.patch, SOLR-10755.patch, SOLR-10755.patch > > > using this issue to track some work i've done to cleanup deprecations in > solrj for master (7.0) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10755) delete/refactor (most) solrj deprecations on master
[ https://issues.apache.org/jira/browse/SOLR-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026599#comment-16026599 ] Jason Gerlowski edited comment on SOLR-10755 at 5/26/17 6:00 PM: - bq. personally i think these methods provide a nice syntactic sugar in tests, and give us wiggle room to add more testing of randomized client options in the future You're right of course, they could provide value at some point. It's a downer that they suffer the same downside that prompted the initial SolrClient ctor change though- the number of SolrClient parameters that can be provided/omitted causes us to end up with tons of these near-duplicate methods. But if that doesn't bother anyone, it's fine with me. Just wanted to mention it as I created most of those methods initially and feel partially responsible for the mess I made :-p (Relatedly, I wish I'd known about SolrTestCaseJ4 being "external" back then, but you learn something new every day) was (Author: gerlowskija): > personally i think these methods provide a nice syntactic sugar in tests, and > give us wiggle room to add more testing of randomized client options in the > future You're right of course, they could provide value at some point. It's a downer that they suffer the same downside that prompted the initial SolrClient ctor change though- the number of SolrClient parameters that can be provided/omitted causes us to end up with tons of these near-duplicate methods. But if that doesn't bother anyone, it's fine with me. Just wanted to mention it as I created most of those methods initially and feel partially responsible for the mess I made :-p (Relatedly, I wish I'd known about SolrTestCaseJ4 being "external" back then, but you learn something new every day) > delete/refactor (most) solrj deprecations on master > --- > > Key: SOLR-10755 > URL: https://issues.apache.org/jira/browse/SOLR-10755 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Blocker > Fix For: master (7.0) > > Attachments: SOLR-10755.patch, SOLR-10755.patch, SOLR-10755.patch > > > using this issue to track some work i've done to cleanup deprecations in > solrj for master (7.0) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10759) TestUseDocValuesAsStored sometimes fails
Tomás Fernández Löbbe created SOLR-10759:
Summary: TestUseDocValuesAsStored sometimes fails
Key: SOLR-10759
URL: https://issues.apache.org/jira/browse/SOLR-10759
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Tomás Fernández Löbbe
Here is the stacktrace of a failure in Jenkins
{noformat}
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Linux/2/
Java: 32bit/jdk-9-ea+168 -server -XX:+UseG1GC
1 tests failed.
FAILED:
org.apache.solr.schema.TestUseDocValuesAsStored.testMultipleSearchResults
Error Message:
mismatch: 'myid1'!='myid' @ response/docs/[0]/id
Stack Trace:
java.lang.RuntimeException: mismatch: 'myid1'!='myid' @ response/docs/[0]/id
at
__randomizedtesting.SeedInfo.seed([A1148D4E62AFDC3A:933E8AD09A51F8E3]:0)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:983)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:930)
at
org.apache.solr.schema.TestUseDocValuesAsStored.testMultipleSearchResults(TestUseDocValuesAsStored.java:243)
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:563)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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.ca
[jira] [Created] (SOLR-10758) Modernize the Solr ref guide's Chinese language analysis coverage
Steve Rowe created SOLR-10758: - Summary: Modernize the Solr ref guide's Chinese language analysis coverage Key: SOLR-10758 URL: https://issues.apache.org/jira/browse/SOLR-10758 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Steve Rowe The Chinese analysis coverage in the ref guide is out of date. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10747) Allow /stream handler to execute Stream Evaluators directly
[ https://issues.apache.org/jira/browse/SOLR-10747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026575#comment-16026575 ] Joel Bernstein commented on SOLR-10747: --- I fixed up the failing test as part of this commit: https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d1436c4 > Allow /stream handler to execute Stream Evaluators directly > --- > > Key: SOLR-10747 > URL: https://issues.apache.org/jira/browse/SOLR-10747 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Fix For: master (7.0) > > Attachments: SOLR-10747.patch > > > Currently the /stream handler only executes Streaming Expressions that > compile to TupleStreams. This ticket will allow the /stream handler to > execute Streaming Expressions that compile StreamEvaluators. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10754) Add hist Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026568#comment-16026568
]
ASF subversion and git services commented on SOLR-10754:
Commit d1436c48230795ed77611466dce6bf7ab850442d in lucene-solr's branch
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d1436c4 ]
SOLR-10754: Add hist Stream Evaluator
> Add hist Stream Evaluator
> --
>
> Key: SOLR-10754
> URL: https://issues.apache.org/jira/browse/SOLR-10754
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-10754.patch
>
>
> The *hist* Streaming Evaluator with create a histogram from a vector of
> numbers.
> Syntax:
> {code}
> h = hist(colA, bins)
> {code}
> Implementation provided by Apache Commons Math
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks
[ https://issues.apache.org/jira/browse/SOLR-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026567#comment-16026567 ] Ishan Chattopadhyaya commented on SOLR-10317: - Can you please explain the test methodology for measuring QPS? What is the field type (Trie or Point / Int or Double or Long or Float)? Firing the same query again and again is useless. Is that what you're trying? Also, what is the latency? bq. Why is the motivation behind creating yet another benchmarking utility? Can you please answer this ^ ? bq. I think the central question is why you chose one over the other? Can you please answer this ^ ? > Solr Nightly Benchmarks > --- > > Key: SOLR-10317 > URL: https://issues.apache.org/jira/browse/SOLR-10317 > Project: Solr > Issue Type: Task >Reporter: Ishan Chattopadhyaya > Labels: gsoc2017, mentor > Attachments: changes-lucene-20160907.json, > changes-solr-20160907.json, managed-schema, > Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, > Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, > solrconfig.xml > > > Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be > found here, https://home.apache.org/~mikemccand/lucenebench/. > Preferably, we need: > # A suite of benchmarks that build Solr from a commit point, start Solr > nodes, both in SolrCloud and standalone mode, and record timing information > of various operations like indexing, querying, faceting, grouping, > replication etc. > # It should be possible to run them either as an independent suite or as a > Jenkins job, and we should be able to report timings as graphs (Jenkins has > some charting plugins). > # The code should eventually be integrated in the Solr codebase, so that it > never goes out of date. > There is some prior work / discussion: > # https://github.com/shalinmangar/solr-perf-tools (Shalin) > # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md > (Ishan/Vivek) > # SOLR-2646 & SOLR-9863 (Mark Miller) > # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless) > # https://github.com/lucidworks/solr-scale-tk (Tim Potter) > There is support for building, starting, indexing/querying and stopping Solr > in some of these frameworks above. However, the benchmarks run are very > limited. Any of these can be a starting point, or a new framework can as well > be used. The motivation is to be able to cover every functionality of Solr > with a corresponding benchmark that is run every night. > Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure > [~shalinmangar] and [~markrmil...@gmail.com] would help here. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10755) delete/refactor (most) solrj deprecations on master
[ https://issues.apache.org/jira/browse/SOLR-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-10755: Attachment: SOLR-10755.patch patch updated to current master & passing precommit. still testing > delete/refactor (most) solrj deprecations on master > --- > > Key: SOLR-10755 > URL: https://issues.apache.org/jira/browse/SOLR-10755 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Blocker > Fix For: master (7.0) > > Attachments: SOLR-10755.patch, SOLR-10755.patch, SOLR-10755.patch > > > using this issue to track some work i've done to cleanup deprecations in > solrj for master (7.0) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10755) delete/refactor (most) solrj deprecations on master
[ https://issues.apache.org/jira/browse/SOLR-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026563#comment-16026563 ] Hoss Man commented on SOLR-10755: - bq. One comment/suggestion/question: good question/suggestion ... but... # those methods aren't marked deprecated, so we can't remove them (SolrTestCaseJ4 is not an "internal" class -- the test-framework is intended/suggested for client app & plugin developers to use) # personally i think these methods provide a nice syntactic sugar in tests, and give us wiggle room to add more testing of randomized client options in the future (example: enabling/disable gzip encoding or keep alive options) so i'd be -0 to marking them deprecated moving forward # even if they were already marked deprecated, the number of changes involved would be huge, and i don't wnat to bog down this jira (or any other jira that's focused specifically on remove deprecations from _solrj_) with any more work. > delete/refactor (most) solrj deprecations on master > --- > > Key: SOLR-10755 > URL: https://issues.apache.org/jira/browse/SOLR-10755 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Blocker > Fix For: master (7.0) > > Attachments: SOLR-10755.patch, SOLR-10755.patch > > > using this issue to track some work i've done to cleanup deprecations in > solrj for master (7.0) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10747) Allow /stream handler to execute Stream Evaluators directly
[ https://issues.apache.org/jira/browse/SOLR-10747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026560#comment-16026560 ] Joel Bernstein commented on SOLR-10747: --- Yeah, I just noticed this. I'll push a fix shortly. > Allow /stream handler to execute Stream Evaluators directly > --- > > Key: SOLR-10747 > URL: https://issues.apache.org/jira/browse/SOLR-10747 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Fix For: master (7.0) > > Attachments: SOLR-10747.patch > > > Currently the /stream handler only executes Streaming Expressions that > compile to TupleStreams. This ticket will allow the /stream handler to > execute Streaming Expressions that compile StreamEvaluators. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10747) Allow /stream handler to execute Stream Evaluators directly
[
https://issues.apache.org/jira/browse/SOLR-10747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026556#comment-16026556
]
Steve Rowe commented on SOLR-10747:
---
My Jenkins found two reproducing seeds for NPE failures in
{{StreamExpressionTest.testArray()}}:
{noformat}
Checking out Revision 3e70745c79efeedd03beebb76b8266eb67a784ae
(refs/remotes/origin/master)
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=StreamExpressionTest -Dtests.method=testArray
-Dtests.seed=737B8254588D11B6 -Dtests.slow=true -Dtests.locale=es-DO
-Dtests.timezone=Asia/Macau -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.09s J2 | StreamExpressionTest.testArray <<<
[junit4]> Throwable #1: java.lang.NullPointerException
[junit4]>at
__randomizedtesting.SeedInfo.seed([737B8254588D11B6:D55DCA306ED523D9]:0)
[junit4]>at
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testArray(StreamExpressionTest.java:5751)
{noformat}
{noformat}
Checking out Revision 3e70745c79efeedd03beebb76b8266eb67a784ae
(refs/remotes/origin/master)
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=StreamExpressionTest -Dtests.method=testArray
-Dtests.seed=3778E227559C8388 -Dtests.slow=true -Dtests.locale=et
-Dtests.timezone=America/Indiana/Knox -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 0.09s J1 | StreamExpressionTest.testArray <<<
[junit4]> Throwable #1: java.lang.NullPointerException
[junit4]>at
__randomizedtesting.SeedInfo.seed([3778E227559C8388:915EAA4363C4B1E7]:0)
[junit4]>at
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testArray(StreamExpressionTest.java:5751)
{noformat}
> Allow /stream handler to execute Stream Evaluators directly
> ---
>
> Key: SOLR-10747
> URL: https://issues.apache.org/jira/browse/SOLR-10747
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10747.patch
>
>
> Currently the /stream handler only executes Streaming Expressions that
> compile to TupleStreams. This ticket will allow the /stream handler to
> execute Streaming Expressions that compile StreamEvaluators.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 359 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/359/ 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.update.HdfsTransactionLog at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130) at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:153) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:110) at org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108) at sun.reflect.GeneratedConstructorAccessor175.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:760) at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:822) at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1088) at org.apache.solr.core.SolrCore.(SolrCore.java:947) at org.apache.solr.core.SolrCore.(SolrCore.java:830) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:930) at org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:565) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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) Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.update.HdfsTransactionLog at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130) at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:153) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:110) at org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108) at sun.reflect.GeneratedConstructorAccessor175.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:760) at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:822) at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1088) at org.apache.solr.core.SolrCore.(SolrCore.java:947) at org.apache.solr.core.SolrCore.(SolrCore.java:830) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:930) at org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:565) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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) at __randomizedtesting.SeedInfo.seed([7A24FE0CE24005B]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:302) at sun.reflect.GeneratedMethodAccessor62.invoke(Unknown Source) 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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-10755) delete/refactor (most) solrj deprecations on master
[
https://issues.apache.org/jira/browse/SOLR-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026552#comment-16026552
]
Jason Gerlowski commented on SOLR-10755:
+1, especially for removing the deprecated {{SolrClient}} constructors.
One comment/suggestion/question:
{{SolrTestCaseJ4}} has a big collection of overloaded
getHttpSolrClient/getLBHttpSolrClient/getCloudSolrClient methods. These were
created back when the SolrClient builders were introduced to ensure that the
tests covered client construction using the builders as well as the many
director-constructor-use. With most of the {{SolrClient}} constructors going
away in this patch, I'm not sure that the get*SolrClient methods serve a
purpose anymore, and can be deleted. Would it make sense to clean that up as a
part of this JIRA?
(That'd expand the scope of this JIRA a bit, so it might also make sense to
create a follow-on JIRA that can get picked up whenever. Happy to help on a
patch if we split this into a separate JIRA.)
> delete/refactor (most) solrj deprecations on master
> ---
>
> Key: SOLR-10755
> URL: https://issues.apache.org/jira/browse/SOLR-10755
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10755.patch, SOLR-10755.patch
>
>
> using this issue to track some work i've done to cleanup deprecations in
> solrj for master (7.0)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks
[ https://issues.apache.org/jira/browse/SOLR-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026549#comment-16026549 ] Vivek Narang commented on SOLR-10317: - Hello [~ichattopadhyaya], After getting inspired by source code in SolrMeter I have come up with the logic to do a kind of a stress test where I am estimating the QPS for a set of numeric queries (as an example for now.). Please access [http://212.47.227.9/dev/NumericQueryBenchmarkCloud.html]. I am observing a strange co-incidence - The QPS measured for a query looking for a specific number is lowest and the QPS measured for a query looking for all those numbers greater than a number. Is there an explanation for this? QPS(Field:Number) < QPS (Field:[Number1 TO Number2]) < QPS(Field:[* TO Number]) < QPS(Field:[Number TO *]) This has been observed over a set of commits and not one commit. > Solr Nightly Benchmarks > --- > > Key: SOLR-10317 > URL: https://issues.apache.org/jira/browse/SOLR-10317 > Project: Solr > Issue Type: Task >Reporter: Ishan Chattopadhyaya > Labels: gsoc2017, mentor > Attachments: changes-lucene-20160907.json, > changes-solr-20160907.json, managed-schema, > Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, > Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, > solrconfig.xml > > > Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be > found here, https://home.apache.org/~mikemccand/lucenebench/. > Preferably, we need: > # A suite of benchmarks that build Solr from a commit point, start Solr > nodes, both in SolrCloud and standalone mode, and record timing information > of various operations like indexing, querying, faceting, grouping, > replication etc. > # It should be possible to run them either as an independent suite or as a > Jenkins job, and we should be able to report timings as graphs (Jenkins has > some charting plugins). > # The code should eventually be integrated in the Solr codebase, so that it > never goes out of date. > There is some prior work / discussion: > # https://github.com/shalinmangar/solr-perf-tools (Shalin) > # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md > (Ishan/Vivek) > # SOLR-2646 & SOLR-9863 (Mark Miller) > # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless) > # https://github.com/lucidworks/solr-scale-tk (Tim Potter) > There is support for building, starting, indexing/querying and stopping Solr > in some of these frameworks above. However, the benchmarks run are very > limited. Any of these can be a starting point, or a new framework can as well > be used. The motivation is to be able to cover every functionality of Solr > with a corresponding benchmark that is run every night. > Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure > [~shalinmangar] and [~markrmil...@gmail.com] would help here. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10735) Solr is broken when directory with spaces used on Windows
[
https://issues.apache.org/jira/browse/SOLR-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026543#comment-16026543
]
Uwe Schindler commented on SOLR-10735:
--
{noformat}
Failed to start Solr using command: C:\Users\Uwe
Schindler\Desktop\solr-6.6.0\bin\solr.cmd start -p 8983 -s "C:\Users\Uwe
Schindler\Desktop\solr-6.6.0\example\techproducts\solr"
{noformat}
It tries to run the solr.cmd file without adding {{"}} around the command
itsself. There is nothing more to say.
> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
> Attachments: Screenshot from 2017-05-24 21-00-29.png
>
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace
> directory names, which is standard on Windows. It does give an error message
> not while server startup, but when trying to create the techproducts core. I
> am about to open issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
