[jira] [Commented] (LUCENE-6776) Randomized planet model shows up additional XYZBounds errors
[ https://issues.apache.org/jira/browse/LUCENE-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728565#comment-14728565 ] Karl Wright commented on LUCENE-6776: - The failure is, once again, a single point that is outside the XYZBounds computed for the shape. Stay tuned for further analysis, probably later this morning. Either there's a mathematical error, or the calculation itself is too problematic in its current form due to error bars. > Randomized planet model shows up additional XYZBounds errors > > > Key: LUCENE-6776 > URL: https://issues.apache.org/jira/browse/LUCENE-6776 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial >Reporter: Karl Wright > Attachments: LUCENE-6776.patch > > > Adding randomized PlanetModel construction causes points to be generated > inside a shape that are outside XYZBounds. [~mikemccand] please take note. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6776) Randomized planet model shows up additional XYZBounds errors
[
https://issues.apache.org/jira/browse/LUCENE-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated LUCENE-6776:
Attachment: LUCENE-6776.patch
This patch demonstrates the failure pretty much immediately, with:
{code}
ant test -Dtestcase=TestGeo3DPointField -Dtests.method=testGeo3DRelations
-Dtests.seed=5B916E77D4C84BE5 -Dtests.slow=true -Dtests.locale=sv
-Dtests.timezone=Pacific/Norfolk -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
{code}
> Randomized planet model shows up additional XYZBounds errors
>
>
> Key: LUCENE-6776
> URL: https://issues.apache.org/jira/browse/LUCENE-6776
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial
>Reporter: Karl Wright
> Attachments: LUCENE-6776.patch
>
>
> Adding randomized PlanetModel construction causes points to be generated
> inside a shape that are outside XYZBounds. [~mikemccand] please take note.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6479) Create utility to generate Classifier's confusion matrix
[
https://issues.apache.org/jira/browse/LUCENE-6479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728558#comment-14728558
]
Tommaso Teofili commented on LUCENE-6479:
-
thanks [~shalinmangar] :)
> Create utility to generate Classifier's confusion matrix
>
>
> Key: LUCENE-6479
> URL: https://issues.apache.org/jira/browse/LUCENE-6479
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/classification
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Trunk
>
>
> In order to debug and compare accuracy of {{Classifiers}} it's often useful
> to print the related [confusion
> matrix|http://en.wikipedia.org/wiki/Confusion_matrix] so it'd be good to
> provide such an utility class/method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6776) Randomized planet model shows up additional XYZBounds errors
Karl Wright created LUCENE-6776: --- Summary: Randomized planet model shows up additional XYZBounds errors Key: LUCENE-6776 URL: https://issues.apache.org/jira/browse/LUCENE-6776 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: Karl Wright Adding randomized PlanetModel construction causes points to be generated inside a shape that are outside XYZBounds. [~mikemccand] please take note. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6479) Create utility to generate Classifier's confusion matrix
[
https://issues.apache.org/jira/browse/LUCENE-6479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728541#comment-14728541
]
ASF subversion and git services commented on LUCENE-6479:
-
Commit 1700933 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1700933 ]
LUCENE-6479: Fix precommit by using named thread factory
> Create utility to generate Classifier's confusion matrix
>
>
> Key: LUCENE-6479
> URL: https://issues.apache.org/jira/browse/LUCENE-6479
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/classification
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Trunk
>
>
> In order to debug and compare accuracy of {{Classifiers}} it's often useful
> to print the related [confusion
> matrix|http://en.wikipedia.org/wiki/Confusion_matrix] so it'd be good to
> provide such an utility class/method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60) - Build # 14096 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14096/ Java: 64bit/jdk1.8.0_60 -XX:+UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 27173 lines...] -check-forbidden-all: [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8 [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8 [forbidden-apis] Reading API signatures: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/base.txt [forbidden-apis] Reading API signatures: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/lucene.txt [forbidden-apis] Loading classes to check... [forbidden-apis] Scanning for API signatures and dependencies... [forbidden-apis] Forbidden method invocation: java.util.concurrent.Executors#newFixedThreadPool(int) [Spawns threads with vague names; use a custom thread factory (Lucene's NamedThreadFactory, Solr's DefaultSolrThreadFactory) and name threads so that you can tell (by its name) which executor it is associated with] [forbidden-apis] in org.apache.lucene.classification.utils.ConfusionMatrixGenerator (ConfusionMatrixGenerator.java:65) [forbidden-apis] Scanned 26 (and 341 related) class file(s) for forbidden API invocations (in 0.03s), 1 error(s). BUILD FAILED /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:775: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:117: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:114: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2162: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2394: Check for forbidden API calls failed, see log. Total time: 51 minutes 35 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6435) java.util.ConcurrentModificationException: Removal from the cache failed error in SimpleNaiveBayesClassifier
[
https://issues.apache.org/jira/browse/LUCENE-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728521#comment-14728521
]
Tommaso Teofili commented on LUCENE-6435:
-
enable _SNCTest#testPerformance_ (comment @Ignore) and you should see that
happening (it performs classification evaluation on 100 randomly generated
indexed docs).
> java.util.ConcurrentModificationException: Removal from the cache failed
> error in SimpleNaiveBayesClassifier
>
>
> Key: LUCENE-6435
> URL: https://issues.apache.org/jira/browse/LUCENE-6435
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/classification
>Affects Versions: 5.1
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Trunk
>
>
> While using {{SimpleNaiveBayesClassifier}} on a very large index (all Italian
> Wikipedia articles) I see the following code triggering a
> {{ConcurrentModificationException}} when evicting the {{Query}} from the
> {{LRUCache}}.
> {code}
> BooleanQuery booleanQuery = new BooleanQuery();
> BooleanQuery subQuery = new BooleanQuery();
> for (String textFieldName : textFieldNames) {
> subQuery.add(new BooleanClause(new TermQuery(new Term(textFieldName,
> word)), BooleanClause.Occur.SHOULD));
> }
> booleanQuery.add(new BooleanClause(subQuery, BooleanClause.Occur.MUST));
> booleanQuery.add(new BooleanClause(new TermQuery(new Term(classFieldName,
> c)), BooleanClause.Occur.MUST));
> //...
> TotalHitCountCollector totalHitCountCollector = new
> TotalHitCountCollector();
> indexSearcher.search(booleanQuery, totalHitCountCollector);
> return totalHitCountCollector.getTotalHits();
> {code}
> this is the complete stacktrace:
> {code}
> java.util.ConcurrentModificationException: Removal from the cache failed!
> This is probably due to a query which has been modified after having been put
> into the cache or a badly implemented clone(). Query class: [class
> org.apache.lucene.search.BooleanQuery], query: [#text:panoram #cat:1356]
> at
> __randomizedtesting.SeedInfo.seed([B6513DEC3681FEF5:138235BE33532634]:0)
> at
> org.apache.lucene.search.LRUQueryCache.evictIfNecessary(LRUQueryCache.java:285)
> at
> org.apache.lucene.search.LRUQueryCache.putIfAbsent(LRUQueryCache.java:268)
> at
> org.apache.lucene.search.LRUQueryCache$CachingWrapperWeight.scorer(LRUQueryCache.java:569)
> at
> org.apache.lucene.search.ConstantScoreWeight.scorer(ConstantScoreWeight.java:82)
> at org.apache.lucene.search.Weight.bulkScorer(Weight.java:137)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:560)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:367)
> at
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.getWordFreqForClass(SimpleNaiveBayesClassifier.java:288)
> at
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.calculateLogLikelihood(SimpleNaiveBayesClassifier.java:248)
> at
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.assignClassNormalizedList(SimpleNaiveBayesClassifier.java:169)
> at
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.assignClass(SimpleNaiveBayesClassifier.java:125)
> at
> org.apache.lucene.classification.WikipediaTest.testItalianWikipedia(WikipediaTest.java:126)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.ran
[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 355 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/355/ All tests passed Build Log: [...truncated 27278 lines...] -check-forbidden-all: [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8 [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8 [forbidden-apis] Reading API signatures: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/base.txt [forbidden-apis] Reading API signatures: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/lucene.txt [forbidden-apis] Loading classes to check... [forbidden-apis] Scanning for API signatures and dependencies... [forbidden-apis] Forbidden method invocation: java.util.concurrent.Executors#newFixedThreadPool(int) [Spawns threads with vague names; use a custom thread factory (Lucene's NamedThreadFactory, Solr's DefaultSolrThreadFactory) and name threads so that you can tell (by its name) which executor it is associated with] [forbidden-apis] in org.apache.lucene.classification.utils.ConfusionMatrixGenerator (ConfusionMatrixGenerator.java:65) [forbidden-apis] Scanned 26 (and 341 related) class file(s) for forbidden API invocations (in 0.04s), 1 error(s). BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:775: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:117: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/build.xml:114: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/common-build.xml:2162: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/common-build.xml:2394: Check for forbidden API calls failed, see log. Total time: 65 minutes 53 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Sending artifact delta relative to Lucene-Solr-Tests-trunk-Java8 #353 Archived 1 artifacts Archive block size is 32768 Received 0 blocks and 464 bytes Compression is 0.0% Took 99 ms Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_60) - Build # 5225 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5225/ Java: 32bit/jdk1.8.0_60 -client -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.search.TestStressUserVersions.testStressReorderVersions Error Message: Captured an uncaught exception in thread: Thread[id=21986, name=READER3, state=RUNNABLE, group=TGRP-TestStressUserVersions] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=21986, name=READER3, state=RUNNABLE, group=TGRP-TestStressUserVersions] at __randomizedtesting.SeedInfo.seed([E91ADE7A45E625A0:F5DCE76C4F2DA12D]:0) Caused by: java.lang.RuntimeException: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([E91ADE7A45E625A0]:0) at org.apache.solr.search.TestStressUserVersions$2.run(TestStressUserVersions.java:302) Caused by: java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.search.TestStressUserVersions$2.run(TestStressUserVersions.java:293) Build Log: [...truncated 10982 lines...] [junit4] Suite: org.apache.solr.search.TestStressUserVersions [junit4] 2> Creating dataDir: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.search.TestStressUserVersions_E91ADE7A45E625A0-001\init-core-data-001 [junit4] 2> 2920998 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) [junit4] 2> 2920999 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.SolrTestCaseJ4 initCore [junit4] 2> 2921000 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory: 'C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\' [junit4] 2> 2921000 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.c.SolrResourceLoader Adding 'file:/C:/Users/JenkinsSlave/workspace/Lucene-Solr-trunk-Windows/solr/core/src/test-files/solr/collection1/lib/classes/' to classloader [junit4] 2> 2921000 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.c.SolrResourceLoader Adding 'file:/C:/Users/JenkinsSlave/workspace/Lucene-Solr-trunk-Windows/solr/core/src/test-files/solr/collection1/lib/README' to classloader [junit4] 2> 2921028 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.c.SolrConfig current version of requestparams : -1 [junit4] 2> 2921032 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.c.SolrConfig Using Lucene MatchVersion: 6.0.0 [junit4] 2> 2921039 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.c.Config Loaded SolrConfig: solrconfig-externalversionconstraint.xml [junit4] 2> 2921040 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.s.IndexSchema Reading Solr Schema from C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\schema15.xml [junit4] 2> 2921057 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.s.IndexSchema [null] Schema name=test [junit4] 2> 2921147 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.s.IndexSchema default search field in schema is text [junit4] 2> 2921149 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.s.IndexSchema unique key field: id [junit4] 2> 2921151 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.s.FileExchangeRateProvider Reloading exchange rates from file currency.xml [junit4] 2> 2921154 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.s.FileExchangeRateProvider Reloading exchange rates from file currency.xml [junit4] 2> 2921164 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx) [junit4] 2> 2921164 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.c.SolrResourceLoader using system property solr.solr.home: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr [junit4] 2> 2921164 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory: 'C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\' [junit4] 2> 2921182 INFO (SUITE-TestStressUserVersions-seed#[E91ADE7A45E625A0]-worker) [] o.a.s.c.CoreContainer New CoreCont
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_60) - Build # 13815 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13815/
Java: 32bit/jdk1.8.0_60 -client -XX:+UseConcMarkSweepGC
2 tests failed.
FAILED:
junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest
Error Message:
Suite timeout exceeded (>= 720 msec).
Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([6F868A9DC83BC151]:0)
FAILED: org.apache.solr.security.BasicAuthIntegrationTest.testBasics
Error Message:
Test abandoned because suite timeout was reached.
Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([6F868A9DC83BC151]:0)
Build Log:
[...truncated 11018 lines...]
[junit4] Suite: org.apache.solr.security.BasicAuthIntegrationTest
[junit4] 2> 90518 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[6F868A9DC83BC151]) []
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
[junit4] 2> 90519 INFO (Thread-255) [] o.a.s.c.ZkTestServer client
port:0.0.0.0/0.0.0.0:0
[junit4] 2> 90519 INFO (Thread-255) [] o.a.s.c.ZkTestServer Starting
server
[junit4] 2> 90619 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[6F868A9DC83BC151]) []
o.a.s.c.ZkTestServer start zk server on port:43596
[junit4] 2> 90620 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[6F868A9DC83BC151]) []
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
[junit4] 2> 90620 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[6F868A9DC83BC151]) []
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
[junit4] 2> 90640 INFO (zkCallback-179-thread-1) []
o.a.s.c.c.ConnectionManager Watcher
org.apache.solr.common.cloud.ConnectionManager@1fdfdf4 name:ZooKeeperConnection
Watcher:127.0.0.1:43596 got event WatchedEvent state:SyncConnected type:None
path:null path:null type:None
[junit4] 2> 90640 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[6F868A9DC83BC151]) []
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
[junit4] 2> 90641 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[6F868A9DC83BC151]) []
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
[junit4] 2> 90641 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[6F868A9DC83BC151]) []
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
[junit4] 2> 90651 INFO (jetty-launcher-178-thread-3) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 90651 INFO (jetty-launcher-178-thread-5) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 90651 INFO (jetty-launcher-178-thread-1) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 90651 INFO (jetty-launcher-178-thread-2) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 90651 INFO (jetty-launcher-178-thread-4) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 90653 INFO (jetty-launcher-178-thread-3) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@137a54e{/solr,null,AVAILABLE}
[junit4] 2> 90656 INFO (jetty-launcher-178-thread-5) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@1da8c28{/solr,null,AVAILABLE}
[junit4] 2> 90656 INFO (jetty-launcher-178-thread-2) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@6e43d4{/solr,null,AVAILABLE}
[junit4] 2> 90657 INFO (jetty-launcher-178-thread-1) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@1c92ab2{/solr,null,AVAILABLE}
[junit4] 2> 90657 INFO (jetty-launcher-178-thread-4) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@17a3386{/solr,null,AVAILABLE}
[junit4] 2> 90658 INFO (jetty-launcher-178-thread-5) []
o.e.j.s.ServerConnector Started
ServerConnector@1a1cdc8{HTTP/1.1}{127.0.0.1:46337}
[junit4] 2> 90658 INFO (jetty-launcher-178-thread-1) []
o.e.j.s.ServerConnector Started
ServerConnector@1408726{HTTP/1.1}{127.0.0.1:49623}
[junit4] 2> 90659 INFO (jetty-launcher-178-thread-3) []
o.e.j.s.ServerConnector Started
ServerConnector@9625eb{HTTP/1.1}{127.0.0.1:57707}
[junit4] 2> 90658 INFO (jetty-launcher-178-thread-2) []
o.e.j.s.ServerConnector Started
ServerConnector@17a5057{HTTP/1.1}{127.0.0.1:58856}
[junit4] 2> 90658 INFO (jetty-launcher-178-thread-4) []
o.e.j.s.ServerConnector Started
ServerConnector@3a3e5e{HTTP/1.1}{127.0.0.1:33111}
[junit4] 2> 90660 INFO (jetty-launcher-178-thread-2) []
o.e.j.s.Server Started @92064ms
[junit4] 2> 90660 INFO (jetty-launcher-178-thread-3) []
o.e.j.s.Server Started @92063ms
[junit4] 2> 90660 INFO (jetty-launcher-178-thread-1) []
o.e.j.s.Server Started @92063ms
[junit4] 2> 90659 INFO (jetty-launcher-178-thread-5) []
o.e.j.s.Server Started @92063ms
[junit4] 2> 90660 INFO (jetty-launcher-178-thread-
[jira] [Commented] (SOLR-8002) Field aliases support for SQL queries
[ https://issues.apache.org/jira/browse/SOLR-8002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728447#comment-14728447 ] Susheel Kumar commented on SOLR-8002: - Sure, Joel. Let me start looking into the patch SOLR-7669. > Field aliases support for SQL queries > - > > Key: SOLR-8002 > URL: https://issues.apache.org/jira/browse/SOLR-8002 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: Trunk >Reporter: Susheel Kumar > > Currently field aliases are not supported for SQL queries against SQL > Handler. E.g. below SQL query > select id,name as product_name from techproducts limit 20 > currently fails as data returned contains still "name" as the field/column > key than product_name -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3491 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3491/
2 tests failed.
REGRESSION: org.apache.solr.security.BasicAuthIntegrationTest.testBasics
Error Message:
Test abandoned because suite timeout was reached.
Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([E7DCBA19D655900E]:0)
FAILED:
junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest
Error Message:
Suite timeout exceeded (>= 720 msec).
Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([E7DCBA19D655900E]:0)
Build Log:
[...truncated 11496 lines...]
[junit4] Suite: org.apache.solr.security.BasicAuthIntegrationTest
[junit4] 2> 1905174 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[E7DCBA19D655900E]) []
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
[junit4] 2> 1905175 INFO (Thread-7667) [] o.a.s.c.ZkTestServer client
port:0.0.0.0/0.0.0.0:0
[junit4] 2> 1905175 INFO (Thread-7667) [] o.a.s.c.ZkTestServer
Starting server
[junit4] 2> 1905275 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[E7DCBA19D655900E]) []
o.a.s.c.ZkTestServer start zk server on port:59238
[junit4] 2> 1905275 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[E7DCBA19D655900E]) []
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
[junit4] 2> 1905305 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[E7DCBA19D655900E]) []
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
[junit4] 2> 1905317 INFO (zkCallback-2442-thread-1) []
o.a.s.c.c.ConnectionManager Watcher
org.apache.solr.common.cloud.ConnectionManager@5fb50137
name:ZooKeeperConnection Watcher:127.0.0.1:59238 got event WatchedEvent
state:SyncConnected type:None path:null path:null type:None
[junit4] 2> 1905317 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[E7DCBA19D655900E]) []
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
[junit4] 2> 1905318 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[E7DCBA19D655900E]) []
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
[junit4] 2> 1905318 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[E7DCBA19D655900E]) []
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
[junit4] 2> 1905331 INFO (jetty-launcher-2441-thread-1) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 1905331 INFO (jetty-launcher-2441-thread-3) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 1905332 INFO (jetty-launcher-2441-thread-2) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 1905334 INFO (jetty-launcher-2441-thread-2) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@3724dcae{/solr,null,AVAILABLE}
[junit4] 2> 1905335 INFO (jetty-launcher-2441-thread-2) []
o.e.j.s.ServerConnector Started
ServerConnector@55143fca{HTTP/1.1}{127.0.0.1:49896}
[junit4] 2> 1905335 INFO (jetty-launcher-2441-thread-2) []
o.e.j.s.Server Started @1908568ms
[junit4] 2> 1905336 INFO (jetty-launcher-2441-thread-2) []
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr,
hostPort=49896}
[junit4] 2> 1905336 INFO (jetty-launcher-2441-thread-2) []
o.a.s.s.SolrDispatchFilter SolrDispatchFilter.init():
sun.misc.Launcher$AppClassLoader@4e0add57
[junit4] 2> 1905336 INFO (jetty-launcher-2441-thread-2) []
o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory:
'/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/solr/build/solr-core/test/J1/temp/solr.security.BasicAuthIntegrationTest_E7DCBA19D655900E-001/tempDir-001/'
[junit4] 2> 1905389 INFO (jetty-launcher-2441-thread-2) []
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
[junit4] 2> 1905418 INFO (jetty-launcher-2441-thread-5) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 1905442 INFO (jetty-launcher-2441-thread-4) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 1905503 INFO (jetty-launcher-2441-thread-4) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@c4ad908{/solr,null,AVAILABLE}
[junit4] 2> 1905504 INFO (jetty-launcher-2441-thread-4) []
o.e.j.s.ServerConnector Started
ServerConnector@5eea286{HTTP/1.1}{127.0.0.1:51124}
[junit4] 2> 1905504 INFO (jetty-launcher-2441-thread-4) []
o.e.j.s.Server Started @1908737ms
[junit4] 2> 1905504 INFO (jetty-launcher-2441-thread-4) []
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostPort=51124,
hostContext=/solr}
[junit4] 2> 1905504 INFO (jetty-launcher-2441-thread-4) []
o.a.s.s.SolrDispatchFilter SolrDispatchFilter.init():
sun.misc.Launcher$AppClassLoader@4e0add57
[junit4] 2> 1905504 INFO (jetty-launcher-2441-thread-4) []
o.a.s.c.SolrResourceLoader new SolrResourceLoader for direc
[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 19 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/19/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
1 tests failed.
FAILED: org.apache.solr.cloud.TestCloudPivotFacet.test
Error Message:
init query failed:
{main(facet=true&facet.pivot=%7B%21stats%3Dst3%7Dbogus_not_in_any_doc_s&facet.pivot=%7B%21stats%3Dst2%7Dpivot_tl1%2Cpivot_l%2Cpivot_z_s1&facet.limit=17&facet.offset=7&facet.pivot.mincount=544),extra(rows=0&q=*%3A*&fq=id%3A%5B*+TO+401%5D&stats=true&stats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_x_s&stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Ddense_pivot_i&stats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Dpivot_i&_test_min=544)}:
No live SolrServers available to handle this
request:[http://127.0.0.1:64669/collection1, http://127.0.0.1:59542/collection1]
Stack Trace:
java.lang.RuntimeException: init query failed:
{main(facet=true&facet.pivot=%7B%21stats%3Dst3%7Dbogus_not_in_any_doc_s&facet.pivot=%7B%21stats%3Dst2%7Dpivot_tl1%2Cpivot_l%2Cpivot_z_s1&facet.limit=17&facet.offset=7&facet.pivot.mincount=544),extra(rows=0&q=*%3A*&fq=id%3A%5B*+TO+401%5D&stats=true&stats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_x_s&stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Ddense_pivot_i&stats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Dpivot_i&_test_min=544)}:
No live SolrServers available to handle this
request:[http://127.0.0.1:64669/collection1, http://127.0.0.1:59542/collection1]
at
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:260)
at
org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:233)
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:497)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
co
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60) - Build # 14095 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14095/ Java: 32bit/jdk1.8.0_60 -server -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication Error Message: Index: 0, Size: 0 Stack Trace: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at __randomizedtesting.SeedInfo.seed([1FE787FC5C139B91:E89469A49AFB3477]:0) at java.util.ArrayList.rangeCheck(ArrayList.java:653) at java.util.ArrayList.get(ArrayList.java:429) at org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1239) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 9564 lines...] [junit4] Suite: org.apache.solr.handler.TestReplicationHandler [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicati
[jira] [Updated] (SOLR-7795) Fold Interval Faceting into Range Faceting
[
https://issues.apache.org/jira/browse/SOLR-7795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-7795:
Attachment: SOLR-7795.patch
Updated to trunk. Improved pivot unit test. I think the patch is ready. I'll
commit it shortly
> Fold Interval Faceting into Range Faceting
> --
>
> Key: SOLR-7795
> URL: https://issues.apache.org/jira/browse/SOLR-7795
> Project: Solr
> Issue Type: Task
>Reporter: Tomás Fernández Löbbe
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-7795.patch, SOLR-7795.patch, SOLR-7795.patch,
> SOLR-7795.patch, SOLR-7795.patch
>
>
> Now that range faceting supports a "filter" and a "dv" method, and that
> interval faceting is supported on fields with {{docValues=false}}, I think we
> should make it so that interval faceting is just a different way of
> specifying ranges in range faceting, allowing users to indicate specific
> ranges.
> I propose we use the same syntax for intervals, but under the "range"
> parameter family:
> {noformat}
> facet.range=price&
> f.price.facet.range.set=[0,10]&
> f.price.facet.range.set=(10,100]
> {noformat}
> The counts for those ranges would come in the response also inside of the
> "range_facets" section. I'm not sure if it's better to include the ranges in
> the "counts" section, or in a different section (intervals?sets?buckets?).
> I'm open to suggestions.
> {code}
> "facet_ranges":{
> "price":{
> "counts":[
> "[0,10]",3,
> "(10,100]",2]
>}
> }
> {code}
> or…
> {code}
> "facet_ranges":{
> "price":{
> "intervals":[
> "[0,10]",3,
> "(10,100]",2]
>}
> }
> {code}
> We should support people specifying both things on the same field.
> Once this is done, "interval faceting" could be deprecated, as all it's
> functionality is now possible through range queries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_60) - Build # 13814 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13814/
Java: 32bit/jdk1.8.0_60 -server -XX:+UseConcMarkSweepGC
2 tests failed.
FAILED:
junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest
Error Message:
Suite timeout exceeded (>= 720 msec).
Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([681B890FA5129076]:0)
FAILED: org.apache.solr.security.BasicAuthIntegrationTest.testBasics
Error Message:
Test abandoned because suite timeout was reached.
Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([681B890FA5129076]:0)
Build Log:
[...truncated 11326 lines...]
[junit4] Suite: org.apache.solr.security.BasicAuthIntegrationTest
[junit4] 2> 664452 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[681B890FA5129076]) []
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
[junit4] 2> 664453 INFO (Thread-1910) [] o.a.s.c.ZkTestServer client
port:0.0.0.0/0.0.0.0:0
[junit4] 2> 664453 INFO (Thread-1910) [] o.a.s.c.ZkTestServer
Starting server
[junit4] 2> 664553 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[681B890FA5129076]) []
o.a.s.c.ZkTestServer start zk server on port:57711
[junit4] 2> 664553 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[681B890FA5129076]) []
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
[junit4] 2> 664553 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[681B890FA5129076]) []
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
[junit4] 2> 664594 INFO (zkCallback-605-thread-1) []
o.a.s.c.c.ConnectionManager Watcher
org.apache.solr.common.cloud.ConnectionManager@63588b name:ZooKeeperConnection
Watcher:127.0.0.1:57711 got event WatchedEvent state:SyncConnected type:None
path:null path:null type:None
[junit4] 2> 664595 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[681B890FA5129076]) []
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
[junit4] 2> 664595 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[681B890FA5129076]) []
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
[junit4] 2> 664595 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[681B890FA5129076]) []
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
[junit4] 2> 664650 INFO (jetty-launcher-604-thread-3) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 664650 INFO (jetty-launcher-604-thread-2) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 664651 INFO (jetty-launcher-604-thread-4) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 664651 INFO (jetty-launcher-604-thread-5) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 664651 INFO (jetty-launcher-604-thread-1) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 664652 INFO (jetty-launcher-604-thread-2) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@16d21d4{/solr,null,AVAILABLE}
[junit4] 2> 664653 INFO (jetty-launcher-604-thread-4) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@f1d4cd{/solr,null,AVAILABLE}
[junit4] 2> 664653 INFO (jetty-launcher-604-thread-5) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@91a060{/solr,null,AVAILABLE}
[junit4] 2> 664653 INFO (jetty-launcher-604-thread-3) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@166e8ba{/solr,null,AVAILABLE}
[junit4] 2> 664654 INFO (jetty-launcher-604-thread-1) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@63d09c{/solr,null,AVAILABLE}
[junit4] 2> 664655 INFO (jetty-launcher-604-thread-3) []
o.e.j.s.ServerConnector Started
ServerConnector@bd05f6{HTTP/1.1}{127.0.0.1:49609}
[junit4] 2> 664655 INFO (jetty-launcher-604-thread-1) []
o.e.j.s.ServerConnector Started
ServerConnector@656377{HTTP/1.1}{127.0.0.1:38578}
[junit4] 2> 664655 INFO (jetty-launcher-604-thread-3) []
o.e.j.s.Server Started @666542ms
[junit4] 2> 664655 INFO (jetty-launcher-604-thread-5) []
o.e.j.s.ServerConnector Started
ServerConnector@140e3fc{HTTP/1.1}{127.0.0.1:57672}
[junit4] 2> 664655 INFO (jetty-launcher-604-thread-2) []
o.e.j.s.ServerConnector Started
ServerConnector@cf26ad{HTTP/1.1}{127.0.0.1:47530}
[junit4] 2> 664655 INFO (jetty-launcher-604-thread-5) []
o.e.j.s.Server Started @666542ms
[junit4] 2> 664655 INFO (jetty-launcher-604-thread-3) []
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr,
hostPort=49609}
[junit4] 2> 664655 INFO (jetty-launcher-604-thread-1) []
o.e.j.s.Server Started @666542ms
[junit4] 2> 664655 INFO (jetty-launcher-604-thread-5) []
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=
[JENKINS] Lucene-Solr-SmokeRelease-trunk - Build # 266 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-trunk/266/ No tests ran. Build Log: [...truncated 52519 lines...] prepare-release-no-sign: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist [copy] Copying 461 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 245 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.8 JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.1 MB in 0.01 sec (10.0 MB/sec) [smoker] check changes HTML... [smoker] download lucene-6.0.0-src.tgz... [smoker] 28.2 MB in 0.05 sec (605.0 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-6.0.0.tgz... [smoker] 65.0 MB in 0.10 sec (620.8 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-6.0.0.zip... [smoker] 75.4 MB in 0.12 sec (620.0 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-6.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 5872 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-6.0.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 5872 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-6.0.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run "ant validate" [smoker] [smoker] command "export JAVA_HOME="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8" PATH="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8/bin:$PATH" JAVACMD="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8/bin/java"; ant validate" failed: [smoker] Buildfile: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/lucene-6.0.0/build.xml [smoker] [smoker] common.compile-tools: [smoker] [smoker] ivy-availability-check: [smoker] [smoker] ivy-fail: [smoker] [smoker] ivy-configure: [smoker] [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: http://ant.apache.org/ivy/ :: [smoker] [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/lucene-6.0.0/ivy-settings.xml [smoker] [smoker] resolve: [smoker] [smoker] init: [smoker] [smoker] compile-core: [smoker] [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/lucene-6.0.0/build/tools/classes/java [smoker] [javac] Compiling 7 source files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/lucene-6.0.0/build/tools/classes/java [smoker] [copy] Copying 1 file to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/lucene-6.0.0/build/tools/classes/java [smoker] [smoker] compile-tools: [smoker] [smoker] compile-tools: [smoker] [smoker] common.compile-tools: [smoker] [smoker] ivy-availability-check: [smoker] [smoker] ivy-fail: [smoker] [smoker] ivy-configure: [smoker] [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/lucene-6.0.0/ivy-settings.xml [smoker] [smoker] resolve: [smoker] [smoker] init: [smoker] [smoker] compile-core: [smoker] [smoker] compile-tools: [smoker] [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/lucene-6.0.0/build/analysis/common/classes/tools [smoker] [javac] Compiling 1 source file to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/lucene-6.0.0/build/analysis/common/classes/tools [smoker] [smoker] ivy-availability-check: [smoker] [smoker] ivy-fail: [smoker] [smoker] ivy-configure: [smoker] [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lu
[jira] [Updated] (SOLR-8001) Using value sources on a multi-valued field can result in an exception if no data
[
https://issues.apache.org/jira/browse/SOLR-8001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-8001:
---
Affects Version/s: 5.3
> Using value sources on a multi-valued field can result in an exception if no
> data
> -
>
> Key: SOLR-8001
> URL: https://issues.apache.org/jira/browse/SOLR-8001
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3
>Reporter: David Smiley
>Assignee: Hoss Man
>Priority: Minor
> Attachments: SOLR-8001.patch
>
>
> SOLR-2522 Introduced the ability to reference a multi-valued field with doc
> values in a function query (value source) such as like this (an example using
> it for sorting): {{sort=field(myMultiValField,min) asc}}. In the event that
> the document has no values for this field, this feature behaves nicely in the
> aforementioned example. And it does if you reference in a 'fl' (as a
> DocTransformer): {{fl=id,myMultiValField:field(myMultiValField,min)}}. In
> that case, the returned document simply doesn't have a name-value pair.
> *But*, if you sort on a more complex function that incorporates this, then
> you get an ArrayIndexOutOfBoundsException. Such as this:
> {{sort=sum(otherField,field(myMultiValField,min)) asc}} There may be other
> conditions where this same exception will be thrown; not sure.
> The root cause can either be considered one of two things (or both) I think:
> * The longVal, intVal, etc. methods on FunctionValues need to be prepared for
> the possibility that the document has no data, in which case it should return
> a default value. This means TrieLongField (& friends) are erroneous.
> * ValueSource.ValueSourceComparator could/should (?) call {{exists}} before
> calling {{doubleVal}} in the various methods where it does.
>
> A workarround for Solr 5.3 users that should work in any situation is to wrap
> the {{field}} function in a {{def}} function since that forces an existence
> check before attempting to access the value (ie: use
> {{sort=def(field(mult_field,min),0)+asc}} instead of
> {{sort=field(mult_field,min)+asc}})
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8001) Using value sources on a multi-valued field can result in an exception if no data
[
https://issues.apache.org/jira/browse/SOLR-8001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-8001:
---
Description:
SOLR-2522 Introduced the ability to reference a multi-valued field with doc
values in a function query (value source) such as like this (an example using
it for sorting): {{sort=field(myMultiValField,min) asc}}. In the event that
the document has no values for this field, this feature behaves nicely in the
aforementioned example. And it does if you reference in a 'fl' (as a
DocTransformer): {{fl=id,myMultiValField:field(myMultiValField,min)}}. In that
case, the returned document simply doesn't have a name-value pair. *But*, if
you sort on a more complex function that incorporates this, then you get an
ArrayIndexOutOfBoundsException. Such as this:
{{sort=sum(otherField,field(myMultiValField,min)) asc}} There may be other
conditions where this same exception will be thrown; not sure.
The root cause can either be considered one of two things (or both) I think:
* The longVal, intVal, etc. methods on FunctionValues need to be prepared for
the possibility that the document has no data, in which case it should return a
default value. This means TrieLongField (& friends) are erroneous.
* ValueSource.ValueSourceComparator could/should (?) call {{exists}} before
calling {{doubleVal}} in the various methods where it does.
A workarround for Solr 5.3 users that should work in any situation is to wrap
the {{field}} function in a {{def}} function since that forces an existence
check before attempting to access the value (ie: use
{{sort=def(field(mult_field,min),0)+asc}} instead of
{{sort=field(mult_field,min)+asc}})
was:
SOLR-2522 Introduced the ability to reference a multi-valued field with doc
values in a function query (value source) such as like this (an example using
it for sorting): {{sort=field(myMultiValField,min) asc}}. In the event that
the document has no values for this field, this feature behaves nicely in the
aforementioned example. And it does if you reference in a 'fl' (as a
DocTransformer): {{fl=id,myMultiValField:field(myMultiValField,min)}}. In that
case, the returned document simply doesn't have a name-value pair. *But*, if
you sort on a more complex function that incorporates this, then you get an
ArrayIndexOutOfBoundsException. Such as this:
{{sort=sum(otherField,field(myMultiValField,min)) asc}} There may be other
conditions where this same exception will be thrown; not sure.
The root cause can either be considered one of two things (or both) I think:
* The longVal, intVal, etc. methods on FunctionValues need to be prepared for
the possibility that the document has no data, in which case it should return a
default value. This means TrieLongField (& friends) are erroneous.
* ValueSource.ValueSourceComparator could/should (?) call {{exists}} before
calling {{doubleVal}} in the various methods where it does.
> Using value sources on a multi-valued field can result in an exception if no
> data
> -
>
> Key: SOLR-8001
> URL: https://issues.apache.org/jira/browse/SOLR-8001
> Project: Solr
> Issue Type: Bug
>Reporter: David Smiley
>Assignee: Hoss Man
>Priority: Minor
> Attachments: SOLR-8001.patch
>
>
> SOLR-2522 Introduced the ability to reference a multi-valued field with doc
> values in a function query (value source) such as like this (an example using
> it for sorting): {{sort=field(myMultiValField,min) asc}}. In the event that
> the document has no values for this field, this feature behaves nicely in the
> aforementioned example. And it does if you reference in a 'fl' (as a
> DocTransformer): {{fl=id,myMultiValField:field(myMultiValField,min)}}. In
> that case, the returned document simply doesn't have a name-value pair.
> *But*, if you sort on a more complex function that incorporates this, then
> you get an ArrayIndexOutOfBoundsException. Such as this:
> {{sort=sum(otherField,field(myMultiValField,min)) asc}} There may be other
> conditions where this same exception will be thrown; not sure.
> The root cause can either be considered one of two things (or both) I think:
> * The longVal, intVal, etc. methods on FunctionValues need to be prepared for
> the possibility that the document has no data, in which case it should return
> a default value. This means TrieLongField (& friends) are erroneous.
> * ValueSource.ValueSourceComparator could/should (?) call {{exists}} before
> calling {{doubleVal}} in the various methods where it does.
>
> A workarround for Solr 5.3 users that should work in any situation is to wrap
> the {{field}} function in a {{def}} function since that forces an existence
> check before attempting to access the value (ie: use
[jira] [Commented] (SOLR-8005) when some docs have no values, sorting on field(multivalued_field,min/max) has inconsistent ordering compared to sorting on same effective values in a single valued fiel
[
https://issues.apache.org/jira/browse/SOLR-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728201#comment-14728201
]
Hoss Man commented on SOLR-8005:
FWIW: i initially thought the best "fix" would be for the various impls of
"getSingleValueSource" in Solr field types to override
SortedSetFieldSource.getSortField to call {{setMissingValue(0)}} as part of the
constructor -- but SortedSetSortField only supports STRING_FIRST and
STRING_LAST as valid options for setMissingValue ... which in hind sight made
perfect sence, since SortedSetSortField uses a TermOrdValComparator under the
covers and never actually inspects/decodes any bytes.
> when some docs have no values, sorting on field(multivalued_field,min/max)
> has inconsistent ordering compared to sorting on same effective values in a
> single valued field
> --
>
> Key: SOLR-8005
> URL: https://issues.apache.org/jira/browse/SOLR-8005
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.4
>Reporter: Hoss Man
>
> While working on tests for SOLR-8001 i realized that because the multivalued
> min/max selector function (ie: {{field(multivalued_field_name,min)}} produces
> a ValueSource which is a {{SortedSetFieldSource}} instance, and because
> SortedSetFieldSource uses SortedSetSortField when sorting, then in situations
> where some documents do not have any value at all in the multivalued field
> the sort order will be inconsistent compared to sorting on a single valued
> numeric field containing the same "effective" min/max value (where docs w/o a
> value act as if the value is "0" by default).
> ie: {{sort=min_of_multivalued_field_name+asc}} vs
> {{sort=field(multivalued_field_name,min)+asc}} will not sort identically.
>
> I don't have any immediate ideas for a "fix" to make these situations more
> equivilent, but the current known workarround for people that want equivilent
> behavior is to wrap the {{field}} function in a {{def}} function selecting a
> default value of {{0}} -- ie:
> {{sort=def(field(multivalued_field_name,min))+asc}}.
> If the function is already wrapped in some other numeric function, then the
> behavior (combined with the existing bug fix in SOLR-8001) should already be
> equivilent -- ie: {{sort=sum(32,min_of_multivalued_field_name)+asc}} vs
> {{sort=sum(32,field(multivalued_field_name,min))+asc}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8001) Using value sources on a multi-valued field can result in an exception if no data
[
https://issues.apache.org/jira/browse/SOLR-8001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-8001:
---
Attachment: SOLR-8001.patch
David: please check out the attached patch and let me know if this is what you
had in mind.
NOTE: I discovered that the sort *order* when using this function on docs w/o
values is inconsistent with the order when using a single valued field
(containing the same effictive value) and filed that as a seperate bug since i
can't think of a clear solution at the moment: SOLR-8005
> Using value sources on a multi-valued field can result in an exception if no
> data
> -
>
> Key: SOLR-8001
> URL: https://issues.apache.org/jira/browse/SOLR-8001
> Project: Solr
> Issue Type: Bug
>Reporter: David Smiley
>Assignee: Hoss Man
>Priority: Minor
> Attachments: SOLR-8001.patch
>
>
> SOLR-2522 Introduced the ability to reference a multi-valued field with doc
> values in a function query (value source) such as like this (an example using
> it for sorting): {{sort=field(myMultiValField,min) asc}}. In the event that
> the document has no values for this field, this feature behaves nicely in the
> aforementioned example. And it does if you reference in a 'fl' (as a
> DocTransformer): {{fl=id,myMultiValField:field(myMultiValField,min)}}. In
> that case, the returned document simply doesn't have a name-value pair.
> *But*, if you sort on a more complex function that incorporates this, then
> you get an ArrayIndexOutOfBoundsException. Such as this:
> {{sort=sum(otherField,field(myMultiValField,min)) asc}} There may be other
> conditions where this same exception will be thrown; not sure.
> The root cause can either be considered one of two things (or both) I think:
> * The longVal, intVal, etc. methods on FunctionValues need to be prepared for
> the possibility that the document has no data, in which case it should return
> a default value. This means TrieLongField (& friends) are erroneous.
> * ValueSource.ValueSourceComparator could/should (?) call {{exists}} before
> calling {{doubleVal}} in the various methods where it does.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8005) when some docs have no values, sorting on field(multivalued_field,min/max) has inconsistent ordering compared to sorting on same effective values in a single valued field
Hoss Man created SOLR-8005:
--
Summary: when some docs have no values, sorting on
field(multivalued_field,min/max) has inconsistent ordering compared to sorting
on same effective values in a single valued field
Key: SOLR-8005
URL: https://issues.apache.org/jira/browse/SOLR-8005
Project: Solr
Issue Type: Bug
Affects Versions: 5.4
Reporter: Hoss Man
While working on tests for SOLR-8001 i realized that because the multivalued
min/max selector function (ie: {{field(multivalued_field_name,min)}} produces a
ValueSource which is a {{SortedSetFieldSource}} instance, and because
SortedSetFieldSource uses SortedSetSortField when sorting, then in situations
where some documents do not have any value at all in the multivalued field the
sort order will be inconsistent compared to sorting on a single valued numeric
field containing the same "effective" min/max value (where docs w/o a value act
as if the value is "0" by default).
ie: {{sort=min_of_multivalued_field_name+asc}} vs
{{sort=field(multivalued_field_name,min)+asc}} will not sort identically.
I don't have any immediate ideas for a "fix" to make these situations more
equivilent, but the current known workarround for people that want equivilent
behavior is to wrap the {{field}} function in a {{def}} function selecting a
default value of {{0}} -- ie:
{{sort=def(field(multivalued_field_name,min))+asc}}.
If the function is already wrapped in some other numeric function, then the
behavior (combined with the existing bug fix in SOLR-8001) should already be
equivilent -- ie: {{sort=sum(32,min_of_multivalued_field_name)+asc}} vs
{{sort=sum(32,field(multivalued_field_name,min))+asc}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6775) Improve MorfologikFilterFactory to allow arbitrary dictionaries from ResourceLoader
[ https://issues.apache.org/jira/browse/LUCENE-6775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-6775: -- Attachment: LUCENE-6775.patch Load the dictionary-resource up front in factory. > Improve MorfologikFilterFactory to allow arbitrary dictionaries from > ResourceLoader > --- > > Key: LUCENE-6775 > URL: https://issues.apache.org/jira/browse/LUCENE-6775 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: Trunk, 5.4 > > Attachments: LUCENE-6775.patch, LUCENE-6775.patch > > > Followup issue for LUCENE-6774: The filter ctor already allows to pass any > dictionary to the filter, but you have no chance to configure this through > the Factory (CustomAnalyzer/Solr/Elasticsearch/...). This will add 2 > parameters to the factory (exclusive with the dictionary string specifying > language, default "pl"), to load FSA (dictionary) and corresponding property > file (metadata/featureData). This dictionary could be placed, e.g. in Solr's > conf dir and loaded, because this would be done via ResourceLoader. > Alternatively the language could still be passed, but must be part of JAR > file distribution. Currently this defaults to "pl" at the moment and plain > Lucene does not allow more, unless you add own JAR files. So practically, the > parameter is useless for a pure, uncustomized Lucene-Impl. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6479) Create utility to generate Classifier's confusion matrix
[
https://issues.apache.org/jira/browse/LUCENE-6479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728132#comment-14728132
]
ASF subversion and git services commented on LUCENE-6479:
-
Commit 1700914 from [~teofili] in branch 'dev/trunk'
[ https://svn.apache.org/r1700914 ]
LUCENE-6479 - improved cm testing, added stats, minor fixes
> Create utility to generate Classifier's confusion matrix
>
>
> Key: LUCENE-6479
> URL: https://issues.apache.org/jira/browse/LUCENE-6479
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/classification
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Trunk
>
>
> In order to debug and compare accuracy of {{Classifiers}} it's often useful
> to print the related [confusion
> matrix|http://en.wikipedia.org/wiki/Confusion_matrix] so it'd be good to
> provide such an utility class/method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6775) Improve MorfologikFilterFactory to allow arbitrary dictionaries from ResourceLoader
[ https://issues.apache.org/jira/browse/LUCENE-6775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-6775: -- Attachment: LUCENE-6775.patch Factory + tests. > Improve MorfologikFilterFactory to allow arbitrary dictionaries from > ResourceLoader > --- > > Key: LUCENE-6775 > URL: https://issues.apache.org/jira/browse/LUCENE-6775 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: Trunk, 5.4 > > Attachments: LUCENE-6775.patch > > > Followup issue for LUCENE-6774: The filter ctor already allows to pass any > dictionary to the filter, but you have no chance to configure this through > the Factory (CustomAnalyzer/Solr/Elasticsearch/...). This will add 2 > parameters to the factory (exclusive with the dictionary string specifying > language, default "pl"), to load FSA (dictionary) and corresponding property > file (metadata/featureData). This dictionary could be placed, e.g. in Solr's > conf dir and loaded, because this would be done via ResourceLoader. > Alternatively the language could still be passed, but must be part of JAR > file distribution. Currently this defaults to "pl" at the moment and plain > Lucene does not allow more, unless you add own JAR files. So practically, the > parameter is useless for a pure, uncustomized Lucene-Impl. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts
[ https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728097#comment-14728097 ] Paul Elschot commented on LUCENE-6590: -- LGTM. > Explore different ways to apply boosts > -- > > Key: LUCENE-6590 > URL: https://issues.apache.org/jira/browse/LUCENE-6590 > Project: Lucene - Core > Issue Type: Wish >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, > LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch > > > Follow-up from LUCENE-6570: the fact that all queries are mutable in order to > allow for applying a boost raises issues since it makes queries bad cache > keys since their hashcode can change anytime. We could just document that > queries should never be modified after they have gone through IndexSearcher > but it would be even better if the API made queries impossible to mutate at > all. > I think there are two main options: > - either replace "void setBoost(boost)" with something like "Query > withBoost(boost)" which would return a clone that has a different boost > - or move boost handling outside of Query, for instance we could have a > (immutable) query impl that would be dedicated to applying boosts, that > queries that need to change boosts at rewrite time (such as BooleanQuery) > would use as a wrapper. > The latter idea is from Robert and I like it a lot given how often I either > introduced or found a bug which was due to the boost parameter being ignored. > Maybe there are other options, but I think this is worth exploring. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6764) Payloads should be compressed
[ https://issues.apache.org/jira/browse/LUCENE-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728092#comment-14728092 ] Paul Elschot commented on LUCENE-6764: -- That should work, too. Plenty of implementation options though, and I have no idea how much time can be spent on compression during indexing. > Payloads should be compressed > - > > Key: LUCENE-6764 > URL: https://issues.apache.org/jira/browse/LUCENE-6764 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > > I think we should at least try to do something simple, eg. deduplicate or > apply simple LZ77 compression. For instance if you use enclosing html tags to > give different weights to individual terms, there might be lots of > repetitions as there are not that many unique html tags. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-7990) timeAllowed is returning wrong results on the same query submitted with different timeAllowed limits
[ https://issues.apache.org/jira/browse/SOLR-7990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reassigned SOLR-7990: Assignee: Erick Erickson > timeAllowed is returning wrong results on the same query submitted with > different timeAllowed limits > > > Key: SOLR-7990 > URL: https://issues.apache.org/jira/browse/SOLR-7990 > Project: Solr > Issue Type: Bug >Affects Versions: 5.2.1, Trunk, 5.4 >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-7990.patch, SOLR-7990.patch > > > William Bell raised a question on the user's list. The scenario is > > send a query that exceeds timeAllowed > > send another identical query with larger timeAllowed that does NOT time out > The results from the second query are not correct, they reflect the doc count > from the first query. > It apparently has to do with filter queries being inappropriately created and > re-used. I've attached a test case that illustrates the problem. > There are three tests here. > testFilterSimpleCase shows the problem. > testCacheAssumptions is my hack at what I _think_ the states of the caches > should be, but has a bunch of clutter so I'm Ignoring it for now. This should > be un-ignored and testFilterSimpleCase removed when there's any fix proposed. > The assumptions may not be correct though. > testQueryResults shows what I think is a problem, the second call that does > NOT exceed timeAllowed still reports partial results. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6775) Improve MorfologikFilterFactory to allow arbitrary dictionaries from ResourceLoader
Uwe Schindler created LUCENE-6775: - Summary: Improve MorfologikFilterFactory to allow arbitrary dictionaries from ResourceLoader Key: LUCENE-6775 URL: https://issues.apache.org/jira/browse/LUCENE-6775 Project: Lucene - Core Issue Type: Improvement Components: modules/analysis Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: Trunk, 5.4 Followup issue for LUCENE-6774: The filter ctor already allows to pass any dictionary to the filter, but you have no chance to configure this through the Factory (CustomAnalyzer/Solr/Elasticsearch/...). This will add 2 parameters to the factory (exclusive with the dictionary string specifying language, default "pl"), to load FSA (dictionary) and corresponding property file (metadata/featureData). This dictionary could be placed, e.g. in Solr's conf dir and loaded, because this would be done via ResourceLoader. Alternatively the language could still be passed, but must be part of JAR file distribution. Currently this defaults to "pl" at the moment and plain Lucene does not allow more, unless you add own JAR files. So practically, the parameter is useless for a pure, uncustomized Lucene-Impl. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-6774. --- Resolution: Fixed Fix Version/s: (was: 5.3.1) OK. I will open a new issue to allow loading arbitrary dicts with morfologik with the factory. The current factory only allows for a language name, which must be packaged in a JAR file in correct package. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Blocker > Fix For: Trunk, 5.4 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch, > LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728018#comment-14728018 ] ASF subversion and git services commented on LUCENE-6774: - Commit 1700904 from [~thetaphi] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1700904 ] Merged revision(s) 1700903 from lucene/dev/trunk: LUCENE-6774: Remove classloader hack in MorfologikFilter #2 > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Blocker > Fix For: Trunk, 5.4, 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch, > LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728016#comment-14728016 ] ASF subversion and git services commented on LUCENE-6774: - Commit 1700903 from [~thetaphi] in branch 'dev/trunk' [ https://svn.apache.org/r1700903 ] LUCENE-6774: Remove classloader hack in MorfologikFilter #2 > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Blocker > Fix For: Trunk, 5.4, 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch, > LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-6699. Resolution: Fixed Fix Version/s: 5.4 Trunk Thanks [~daddywri]! > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: Trunk, 5.4 > > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6759) Integrate lat/long BKD and spatial 3d, part 2
[ https://issues.apache.org/jira/browse/LUCENE-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-6759. Resolution: Fixed Fix Version/s: 5.4 Trunk > Integrate lat/long BKD and spatial 3d, part 2 > - > > Key: LUCENE-6759 > URL: https://issues.apache.org/jira/browse/LUCENE-6759 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless > Fix For: Trunk, 5.4 > > Attachments: LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch > > > This is just a continuation of LUCENE-6699, which became too big. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727937#comment-14727937 ] ASF subversion and git services commented on LUCENE-6699: - Commit 1700887 from [~mikemccand] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1700887 ] LUCENE-6699: add geo3d + BKD for fast, accurate earth-surface point-in-shape queries > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727923#comment-14727923 ] ASF subversion and git services commented on LUCENE-6699: - Commit 1700883 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1700883 ] LUCENE-6699: add geo3d + BKD for fast, accurate earth-surface point-in-shape queries > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b78) - Build # 13813 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13813/
Java: 64bit/jdk1.9.0-ea-b78 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
2 tests failed.
FAILED:
junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest
Error Message:
Suite timeout exceeded (>= 720 msec).
Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([FE45AB48C127C6C4]:0)
FAILED: org.apache.solr.security.BasicAuthIntegrationTest.testBasics
Error Message:
Test abandoned because suite timeout was reached.
Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([FE45AB48C127C6C4]:0)
Build Log:
[...truncated 11375 lines...]
[junit4] Suite: org.apache.solr.security.BasicAuthIntegrationTest
[junit4] 2> 1465556 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[FE45AB48C127C6C4]) []
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
[junit4] 2> 1465556 INFO (Thread-4387) [] o.a.s.c.ZkTestServer client
port:0.0.0.0/0.0.0.0:0
[junit4] 2> 1465556 INFO (Thread-4387) [] o.a.s.c.ZkTestServer
Starting server
[junit4] 2> 1465656 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[FE45AB48C127C6C4]) []
o.a.s.c.ZkTestServer start zk server on port:51644
[junit4] 2> 1465656 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[FE45AB48C127C6C4]) []
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
[junit4] 2> 1465657 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[FE45AB48C127C6C4]) []
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
[junit4] 2> 1465700 INFO (zkCallback-1585-thread-1) []
o.a.s.c.c.ConnectionManager Watcher
org.apache.solr.common.cloud.ConnectionManager@472d1036
name:ZooKeeperConnection Watcher:127.0.0.1:51644 got event WatchedEvent
state:SyncConnected type:None path:null path:null type:None
[junit4] 2> 1465700 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[FE45AB48C127C6C4]) []
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
[junit4] 2> 1465700 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[FE45AB48C127C6C4]) []
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
[junit4] 2> 1465700 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[FE45AB48C127C6C4]) []
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
[junit4] 2> 1465732 INFO (jetty-launcher-1584-thread-1) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 1465732 INFO (jetty-launcher-1584-thread-2) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 1465732 INFO (jetty-launcher-1584-thread-3) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 1465732 INFO (jetty-launcher-1584-thread-4) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 1465732 INFO (jetty-launcher-1584-thread-5) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 1465736 INFO (jetty-launcher-1584-thread-1) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@648c1bfc{/solr,null,AVAILABLE}
[junit4] 2> 1465737 INFO (jetty-launcher-1584-thread-1) []
o.e.j.s.ServerConnector Started
ServerConnector@7342d4dc{HTTP/1.1}{127.0.0.1:48014}
[junit4] 2> 1465737 INFO (jetty-launcher-1584-thread-1) []
o.e.j.s.Server Started @1467207ms
[junit4] 2> 1465737 INFO (jetty-launcher-1584-thread-2) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@634ebe3d{/solr,null,AVAILABLE}
[junit4] 2> 1465737 INFO (jetty-launcher-1584-thread-3) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@191483c0{/solr,null,AVAILABLE}
[junit4] 2> 1465737 INFO (jetty-launcher-1584-thread-1) []
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr,
hostPort=48014}
[junit4] 2> 1465737 INFO (jetty-launcher-1584-thread-2) []
o.e.j.s.ServerConnector Started
ServerConnector@623a7800{HTTP/1.1}{127.0.0.1:43743}
[junit4] 2> 1465737 INFO (jetty-launcher-1584-thread-2) []
o.e.j.s.Server Started @1467208ms
[junit4] 2> 1465737 INFO (jetty-launcher-1584-thread-1) []
o.a.s.s.SolrDispatchFilter SolrDispatchFilter.init():
sun.misc.Launcher$AppClassLoader@20fa23c1
[junit4] 2> 1465737 INFO (jetty-launcher-1584-thread-3) []
o.e.j.s.ServerConnector Started
ServerConnector@43ec41c3{HTTP/1.1}{127.0.0.1:46700}
[junit4] 2> 1465737 INFO (jetty-launcher-1584-thread-4) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@24446981{/solr,null,AVAILABLE}
[junit4] 2> 1465737 INFO (jetty-launcher-1584-thread-5) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@68e4ebca{/solr,null,AVAILABLE}
[junit4] 2> 1465737 INFO (jetty-launcher-1584-thread-3) []
o.e.j.s.Server Started @1467208ms
[junit4] 2> 1465738 INFO (jetty-launcher-1584-thread-4) [
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727875#comment-14727875 ] Uwe Schindler commented on LUCENE-6774: --- OK thanks. I will open separate issue about the factory. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Blocker > Fix For: Trunk, 5.4, 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch, > LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Solaris (multiarch/jdk1.7.0) - Build # 20 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Solaris/20/
Java: multiarch/jdk1.7.0 -d64 -XX:-UseCompressedOops -XX:+UseSerialGC
2 tests failed.
FAILED: org.apache.solr.security.BasicAuthIntegrationTest.testBasics
Error Message:
Test abandoned because suite timeout was reached.
Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([533243548995101C]:0)
FAILED:
junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest
Error Message:
Suite timeout exceeded (>= 720 msec).
Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([533243548995101C]:0)
Build Log:
[...truncated 11375 lines...]
[junit4] Suite: org.apache.solr.security.BasicAuthIntegrationTest
[junit4] 2> 3210864 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[533243548995101C]) []
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
[junit4] 2> 3210865 INFO (Thread-10250) [] o.a.s.c.ZkTestServer
client port:0.0.0.0/0.0.0.0:0
[junit4] 2> 3210865 INFO (Thread-10250) [] o.a.s.c.ZkTestServer
Starting server
[junit4] 2> 3210965 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[533243548995101C]) []
o.a.s.c.ZkTestServer start zk server on port:44367
[junit4] 2> 3210965 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[533243548995101C]) []
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
[junit4] 2> 3210966 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[533243548995101C]) []
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
[junit4] 2> 3211016 INFO (zkCallback-3517-thread-1) []
o.a.s.c.c.ConnectionManager Watcher
org.apache.solr.common.cloud.ConnectionManager@68ffbced
name:ZooKeeperConnection Watcher:127.0.0.1:44367 got event WatchedEvent
state:SyncConnected type:None path:null path:null type:None
[junit4] 2> 3211016 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[533243548995101C]) []
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
[junit4] 2> 3211016 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[533243548995101C]) []
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
[junit4] 2> 3211017 INFO
(TEST-BasicAuthIntegrationTest.testExraFilters-seed#[533243548995101C]) []
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
[junit4] 2> 3211137 INFO (jetty-launcher-3516-thread-1) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 3211137 INFO (jetty-launcher-3516-thread-2) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 3211137 INFO (jetty-launcher-3516-thread-3) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 3211139 INFO (jetty-launcher-3516-thread-4) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 3211141 INFO (jetty-launcher-3516-thread-5) []
o.e.j.s.Server jetty-9.2.13.v20150730
[junit4] 2> 3211145 INFO (jetty-launcher-3516-thread-4) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@79206122{/solr,null,AVAILABLE}
[junit4] 2> 3211149 INFO (jetty-launcher-3516-thread-2) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@2956635c{/solr,null,AVAILABLE}
[junit4] 2> 3211150 INFO (jetty-launcher-3516-thread-2) []
o.e.j.s.ServerConnector Started
ServerConnector@66954237{HTTP/1.1}{127.0.0.1:56456}
[junit4] 2> 3211150 INFO (jetty-launcher-3516-thread-2) []
o.e.j.s.Server Started @3219347ms
[junit4] 2> 3211150 INFO (jetty-launcher-3516-thread-2) []
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr,
hostPort=56456}
[junit4] 2> 3211150 INFO (jetty-launcher-3516-thread-2) []
o.a.s.s.SolrDispatchFilter SolrDispatchFilter.init():
sun.misc.Launcher$AppClassLoader@1e893918
[junit4] 2> 3211151 INFO (jetty-launcher-3516-thread-2) []
o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory:
'/export/home/jenkins/workspace/Lucene-Solr-5.x-Solaris/solr/build/solr-core/test/J0/temp/solr.security.BasicAuthIntegrationTest_533243548995101C-001/tempDir-001/'
[junit4] 2> 3211156 INFO (jetty-launcher-3516-thread-5) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@1b703108{/solr,null,AVAILABLE}
[junit4] 2> 3211161 INFO (jetty-launcher-3516-thread-3) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@6b56b25a{/solr,null,AVAILABLE}
[junit4] 2> 3211161 INFO (jetty-launcher-3516-thread-3) []
o.e.j.s.ServerConnector Started
ServerConnector@8d769c4{HTTP/1.1}{127.0.0.1:51157}
[junit4] 2> 3211162 INFO (jetty-launcher-3516-thread-3) []
o.e.j.s.Server Started @3219359ms
[junit4] 2> 3211162 INFO (jetty-launcher-3516-thread-3) []
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr,
hostPort=51157}
[j
[jira] [Commented] (SOLR-7569) Create an API to force a leader election between nodes
[ https://issues.apache.org/jira/browse/SOLR-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727760#comment-14727760 ] Ishan Chattopadhyaya commented on SOLR-7569: bq. This seems to have some overlap with SOLR-6236 based on the comments. I think I should've posted the patches there, instead of here. Seems like I'm trying to solve the same problem here (albeit, in a different way). > Create an API to force a leader election between nodes > -- > > Key: SOLR-7569 > URL: https://issues.apache.org/jira/browse/SOLR-7569 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Labels: difficulty-medium, impact-high > Attachments: SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, > SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, > SOLR-7569_lir_down_state_test.patch > > > There are many reasons why Solr will not elect a leader for a shard e.g. all > replicas' last published state was recovery or due to bugs which cause a > leader to be marked as 'down'. While the best solution is that they never get > into this state, we need a manual way to fix this when it does get into this > state. Right now we can do a series of dance involving bouncing the node > (since recovery paths between bouncing and REQUESTRECOVERY are different), > but that is difficult when running a large cluster. Although it is possible > that such a manual API may lead to some data loss but in some cases, it is > the only possible option to restore availability. > This issue proposes to build a new collection API which can be used to force > replicas into recovering a leader while avoiding data loss on a best effort > basis. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7569) Create an API to force a leader election between nodes
[ https://issues.apache.org/jira/browse/SOLR-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727759#comment-14727759 ] Mark Miller commented on SOLR-7569: --- bq. we're just trying to (manually) clean up the LIR state and mark affected down replicas as active and hope that normal leader election is initiated and normalcy is restored. I like that approach too, but I want to make sure we consider SOLR-6236. > Create an API to force a leader election between nodes > -- > > Key: SOLR-7569 > URL: https://issues.apache.org/jira/browse/SOLR-7569 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Labels: difficulty-medium, impact-high > Attachments: SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, > SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, > SOLR-7569_lir_down_state_test.patch > > > There are many reasons why Solr will not elect a leader for a shard e.g. all > replicas' last published state was recovery or due to bugs which cause a > leader to be marked as 'down'. While the best solution is that they never get > into this state, we need a manual way to fix this when it does get into this > state. Right now we can do a series of dance involving bouncing the node > (since recovery paths between bouncing and REQUESTRECOVERY are different), > but that is difficult when running a large cluster. Although it is possible > that such a manual API may lead to some data loss but in some cases, it is > the only possible option to restore availability. > This issue proposes to build a new collection API which can be used to force > replicas into recovering a leader while avoiding data loss on a best effort > basis. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7569) Create an API to force a leader election between nodes
[ https://issues.apache.org/jira/browse/SOLR-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727757#comment-14727757 ] Mark Miller commented on SOLR-7569: --- [~thelabdude], what is your impression? > Create an API to force a leader election between nodes > -- > > Key: SOLR-7569 > URL: https://issues.apache.org/jira/browse/SOLR-7569 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Labels: difficulty-medium, impact-high > Attachments: SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, > SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, > SOLR-7569_lir_down_state_test.patch > > > There are many reasons why Solr will not elect a leader for a shard e.g. all > replicas' last published state was recovery or due to bugs which cause a > leader to be marked as 'down'. While the best solution is that they never get > into this state, we need a manual way to fix this when it does get into this > state. Right now we can do a series of dance involving bouncing the node > (since recovery paths between bouncing and REQUESTRECOVERY are different), > but that is difficult when running a large cluster. Although it is possible > that such a manual API may lead to some data loss but in some cases, it is > the only possible option to restore availability. > This issue proposes to build a new collection API which can be used to force > replicas into recovering a leader while avoiding data loss on a best effort > basis. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727754#comment-14727754 ] Dawid Weiss commented on LUCENE-6774: - What you should be using is this explicit constructor: https://github.com/morfologik/morfologik-stemming/blob/master/morfologik-stemming/src/main/java/morfologik/stemming/Dictionary.java#L64 FSA can be read from an InputStream: https://github.com/morfologik/morfologik-stemming/blob/master/morfologik-fsa/src/main/java/morfologik/fsa/FSA.java#L256 And DictionaryMetadata can be constructed programmatically or otherwise. Here is the method that does the loading from two streams (FSA and properties): https://github.com/morfologik/morfologik-stemming/blob/master/morfologik-stemming/src/main/java/morfologik/stemming/Dictionary.java#L106-L156 > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Blocker > Fix For: Trunk, 5.4, 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch, > LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727745#comment-14727745 ] Uwe Schindler commented on LUCENE-6774: --- Personally, I would also like to change the factory class to take the language code (for backwards compatibility) and otherwise use dict and meta file as separate config params. The default Lucene ResourceLoader interface would then convert them to a URL/InputStream, so it works in Solr from conf/ directory, too. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Blocker > Fix For: Trunk, 5.4, 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch, > LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727741#comment-14727741 ] Uwe Schindler commented on LUCENE-6774: --- URI -> URL (like returned by Class#getResource()). URI does not supply InputStreams. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Blocker > Fix For: Trunk, 5.4, 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch, > LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727738#comment-14727738 ] Dawid Weiss edited comment on LUCENE-6774 at 9/2/15 6:00 PM: - You see Morfologik does ship with the Polish dictionary, but it's merely a simple wrapper around a static inflection dictionary. You could build these yourself for an arbitrary language and reuse all of the code to just load and scan it -- this is what this project does, for example: https://languagetool.org/ That's why I think it'd make more sense to remove all of these resource-loading facilities and simply require an URI to the data itself. Your solution is great, of course! was (Author: dweiss): You see Morfologik does ship with the Polish dictionary, but it's merely a simply wrapper around a static inflection dictionary. You could build these yourself for an arbitrary language and reuse all of the code to just load and scan it -- this is what this project does, for example: https://languagetool.org/ That's why I think it'd make more sense to remove all of these resource-loading facilities and simply require an URI to the data itself. Your solution is great, of course! > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Blocker > Fix For: Trunk, 5.4, 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch, > LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-6774: -- Component/s: modules/analysis > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Robert Muir >Priority: Blocker > Fix For: Trunk, 5.4, 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch, > LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7569) Create an API to force a leader election between nodes
[ https://issues.apache.org/jira/browse/SOLR-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727740#comment-14727740 ] Ishan Chattopadhyaya commented on SOLR-7569: bq. At a high-level, the issue boils down to giving SolrCloud operators a way to either a) manually force a leader to be elected, or b) set an optional configuration property that triggers the force leader behavior after seeing so many failed recoveries due to no leader. I think the difference is that in this issue, we're just trying to (manually) clean up the LIR state and mark affected down replicas as active and hope that normal leader election is initiated and normalcy is restored. Based on initial glance at SOLR-6236, it seems that the intention there is to actually force one of the replicas to become a leader (either manually or automatically). I am not sure which path we should take, but it seems the approach taken here is less intrusive/safer, if/when it works. > Create an API to force a leader election between nodes > -- > > Key: SOLR-7569 > URL: https://issues.apache.org/jira/browse/SOLR-7569 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Labels: difficulty-medium, impact-high > Attachments: SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, > SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, > SOLR-7569_lir_down_state_test.patch > > > There are many reasons why Solr will not elect a leader for a shard e.g. all > replicas' last published state was recovery or due to bugs which cause a > leader to be marked as 'down'. While the best solution is that they never get > into this state, we need a manual way to fix this when it does get into this > state. Right now we can do a series of dance involving bouncing the node > (since recovery paths between bouncing and REQUESTRECOVERY are different), > but that is difficult when running a large cluster. Although it is possible > that such a manual API may lead to some data loss but in some cases, it is > the only possible option to restore availability. > This issue proposes to build a new collection API which can be used to force > replicas into recovering a leader while avoiding data loss on a best effort > basis. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-6774: -- Fix Version/s: 5.4 Trunk > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Robert Muir >Priority: Blocker > Fix For: Trunk, 5.4, 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch, > LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reassigned LUCENE-6774: - Assignee: Uwe Schindler > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Robert Muir >Assignee: Uwe Schindler >Priority: Blocker > Fix For: Trunk, 5.4, 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch, > LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727738#comment-14727738 ] Dawid Weiss commented on LUCENE-6774: - You see Morfologik does ship with the Polish dictionary, but it's merely a simply wrapper around a static inflection dictionary. You could build these yourself for an arbitrary language and reuse all of the code to just load and scan it -- this is what this project does, for example: https://languagetool.org/ That's why I think it'd make more sense to remove all of these resource-loading facilities and simply require an URI to the data itself. Your solution is great, of course! > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Robert Muir >Priority: Blocker > Fix For: Trunk, 5.4, 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch, > LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-6774: -- Attachment: LUCENE-6774.patch New patch. There was a copy'n'paste problem with error message in last one. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch, > LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727730#comment-14727730 ] Uwe Schindler commented on LUCENE-6774: --- OK or URI. I think the current Lucene code is not really a "workaround" we can keep it as is. It does not hack anything it just uses the official APIs. The only thing thats a hack is the hardcoded package paths. Maybe add those as constants to Morfologik. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7569) Create an API to force a leader election between nodes
[
https://issues.apache.org/jira/browse/SOLR-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727720#comment-14727720
]
Mark Miller commented on SOLR-7569:
---
This seems to have some overlap with SOLR-6236 based on the comments. Tim did
some work here as well:
{quote}At a high-level, the issue boils down to giving SolrCloud operators a
way to either a) manually force a leader to be elected, or b) set an optional
configuration property that triggers the force leader behavior after seeing so
many failed recoveries due to no leader. So this can be considered an optional
availablity-over-consistency mode with respect to leader-failover.{quote}
> Create an API to force a leader election between nodes
> --
>
> Key: SOLR-7569
> URL: https://issues.apache.org/jira/browse/SOLR-7569
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Labels: difficulty-medium, impact-high
> Attachments: SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch,
> SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch,
> SOLR-7569_lir_down_state_test.patch
>
>
> There are many reasons why Solr will not elect a leader for a shard e.g. all
> replicas' last published state was recovery or due to bugs which cause a
> leader to be marked as 'down'. While the best solution is that they never get
> into this state, we need a manual way to fix this when it does get into this
> state. Right now we can do a series of dance involving bouncing the node
> (since recovery paths between bouncing and REQUESTRECOVERY are different),
> but that is difficult when running a large cluster. Although it is possible
> that such a manual API may lead to some data loss but in some cases, it is
> the only possible option to restore availability.
> This issue proposes to build a new collection API which can be used to force
> replicas into recovering a leader while avoiding data loss on a best effort
> basis.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727699#comment-14727699 ] Dawid Weiss commented on LUCENE-6774: - I think an URI would be most flexible. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727682#comment-14727682 ] Uwe Schindler commented on LUCENE-6774: --- Maybe add a method with a classloader. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727681#comment-14727681 ] Dawid Weiss commented on LUCENE-6774: - I actually plan to remove all that logic from ResourceUtils... it should be up to the caller to figure out how to locate dictionary resources -- that's where the knowledge of how to do it should be. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727674#comment-14727674 ] Dawid Weiss commented on LUCENE-6774: - Thanks Uwe, yep, it looks good to me as a temporary workaround. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727676#comment-14727676 ] Uwe Schindler commented on LUCENE-6774: --- Dawid: I think the quickest fix would be to replace the second try to add a leading slash in ResourceUtils. For now, we prefer to have the dictionary loaded statically. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-6774: -- Attachment: LUCENE-6774.patch I changed the static constant with the default dict to be consistent. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch, LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727669#comment-14727669 ] Dawid Weiss commented on LUCENE-6774: - I will fix this in Morfologik so that dictionaries are not looked up via class resource search mechanism. The reason context class loader was used was not just Solr -- it was also a workaround for certain web servlet containers (as far as I can remember). I am working on a proper fix in Morfologik, which I'll then apply to Lucene/ Solr. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch, LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6774) Remove solr hack in MorfologikFilter
[
https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-6774:
--
Attachment: LUCENE-6774.patch
Patch. This also removes the horrible cache and uses the only existing
dictionary ("pl") statically.
We should maybe add some additional code to the factory to also allow loading
from plain files. But that's another issue.
> Remove solr hack in MorfologikFilter
>
>
> Key: LUCENE-6774
> URL: https://issues.apache.org/jira/browse/LUCENE-6774
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
>Priority: Blocker
> Fix For: 5.3.1
>
> Attachments: LUCENE-6774.patch, LUCENE-6774.patch
>
>
> If solr wants to set the contextClassLoader because its classloading is
> fucked up, then it needs to do this hack itself: it should not be in lucene
> code.
> The current mess prevents use of this analyzer in other environments
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7844) Zookeeper session expiry during shard leader election can cause multiple leaders.
[ https://issues.apache.org/jira/browse/SOLR-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-7844. --- Resolution: Fixed Thanks guys! > Zookeeper session expiry during shard leader election can cause multiple > leaders. > - > > Key: SOLR-7844 > URL: https://issues.apache.org/jira/browse/SOLR-7844 > Project: Solr > Issue Type: Bug >Affects Versions: 4.10.4 >Reporter: Mike Roberts >Assignee: Mark Miller > Fix For: Trunk, 5.4 > > Attachments: SOLR-7844-5x.patch, SOLR-7844.patch, SOLR-7844.patch, > SOLR-7844.patch, SOLR-7844.patch, SOLR-7844.patch, SOLR-7844.patch, > SOLR-7844.patch, SOLR-7844.patch, SOLR-7844.patch > > > If the ZooKeeper session expires for a host during shard leader election, the > ephemeral leader_elect nodes are removed. However the threads that were > processing the election are still present (and could believe the host won the > election). They will then incorrectly create leader nodes once a new > ZooKeeper session is established. > This introduces a subtle race condition that could cause two hosts to become > leader. > Scenario: > a three machine cluster, all of the machines are restarting at approximately > the same time. > The first machine starts, writes a leader_elect ephemeral node, it's the only > candidate in the election so it wins and starts the leadership process. As it > knows it has peers, it begins to block waiting for the peers to arrive. > During this period of blocking[1] the ZK connection drops and the session > expires. > A new ZK session is established, and ElectionContext.cancelElection is > called. Then register() is called and a new set of leader_elect ephemeral > nodes are created. > During the period between the ZK session expiring, and new set of > leader_elect nodes being created the second machine starts. > It creates its leader_elect ephemeral nodes, as there are no other nodes it > wins the election and starts the leadership process. As its still missing one > of its peers, it begins to block waiting for the third machine to join. > There is now a race between machine1 & machine2, both of whom think they are > the leader. > So far, this isn't too bad, because the machine that loses the race will fail > when it tries to create the /collection/name/leader/shard1 node (as it > already exists), and will rejoin the election. > While this is happening, machine3 has started and has queued for leadership > behind machine2. > If the loser of the race is machine2, when it rejoins the election it cancels > the current context, deleting it's leader_elect ephemeral nodes. > At this point, machine3 believes it has become leader (the watcher it has on > the leader_elect node fires), and it runs the LeaderElector::checkIfIAmLeader > method. This method DELETES the current /collection/name/leader/shard1 node, > then starts the leadership process (as all three machines are now running, it > does not block to wait). > So, machine1 won the race with machine2 and declared its leadership and > created the nodes. However, machine3 has just deleted them, and recreated > them for itself. So machine1 and machine3 both believe they are the leader. > I am thinking that the fix should be to cancel & close all election contexts > immediately on reconnect (we do cancel them, however it's run serially which > has blocking issues, and just canceling does not cause the wait loop to > exit). That election context logic already has checks on the closed flag, so > they should exit if they see it has been closed. > I'm working on a patch for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7844) Zookeeper session expiry during shard leader election can cause multiple leaders.
[ https://issues.apache.org/jira/browse/SOLR-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727664#comment-14727664 ] ASF subversion and git services commented on SOLR-7844: --- Commit 1700853 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1700853 ] SOLR-7844: Zookeeper session expiry during shard leader election can cause multiple leaders. > Zookeeper session expiry during shard leader election can cause multiple > leaders. > - > > Key: SOLR-7844 > URL: https://issues.apache.org/jira/browse/SOLR-7844 > Project: Solr > Issue Type: Bug >Affects Versions: 4.10.4 >Reporter: Mike Roberts >Assignee: Mark Miller > Fix For: Trunk, 5.4 > > Attachments: SOLR-7844-5x.patch, SOLR-7844.patch, SOLR-7844.patch, > SOLR-7844.patch, SOLR-7844.patch, SOLR-7844.patch, SOLR-7844.patch, > SOLR-7844.patch, SOLR-7844.patch, SOLR-7844.patch > > > If the ZooKeeper session expires for a host during shard leader election, the > ephemeral leader_elect nodes are removed. However the threads that were > processing the election are still present (and could believe the host won the > election). They will then incorrectly create leader nodes once a new > ZooKeeper session is established. > This introduces a subtle race condition that could cause two hosts to become > leader. > Scenario: > a three machine cluster, all of the machines are restarting at approximately > the same time. > The first machine starts, writes a leader_elect ephemeral node, it's the only > candidate in the election so it wins and starts the leadership process. As it > knows it has peers, it begins to block waiting for the peers to arrive. > During this period of blocking[1] the ZK connection drops and the session > expires. > A new ZK session is established, and ElectionContext.cancelElection is > called. Then register() is called and a new set of leader_elect ephemeral > nodes are created. > During the period between the ZK session expiring, and new set of > leader_elect nodes being created the second machine starts. > It creates its leader_elect ephemeral nodes, as there are no other nodes it > wins the election and starts the leadership process. As its still missing one > of its peers, it begins to block waiting for the third machine to join. > There is now a race between machine1 & machine2, both of whom think they are > the leader. > So far, this isn't too bad, because the machine that loses the race will fail > when it tries to create the /collection/name/leader/shard1 node (as it > already exists), and will rejoin the election. > While this is happening, machine3 has started and has queued for leadership > behind machine2. > If the loser of the race is machine2, when it rejoins the election it cancels > the current context, deleting it's leader_elect ephemeral nodes. > At this point, machine3 believes it has become leader (the watcher it has on > the leader_elect node fires), and it runs the LeaderElector::checkIfIAmLeader > method. This method DELETES the current /collection/name/leader/shard1 node, > then starts the leadership process (as all three machines are now running, it > does not block to wait). > So, machine1 won the race with machine2 and declared its leadership and > created the nodes. However, machine3 has just deleted them, and recreated > them for itself. So machine1 and machine3 both believe they are the leader. > I am thinking that the fix should be to cancel & close all election contexts > immediately on reconnect (we do cancel them, however it's run serially which > has blocking issues, and just canceling does not cause the wait loop to > exit). That election context logic already has checks on the closed flag, so > they should exit if they see it has been closed. > I'm working on a patch for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60) - Build # 14093 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14093/ Java: 32bit/jdk1.8.0_60 -server -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest 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([381196C605DB8628:9F552E6268609591]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplication(CdcrReplicationHandlerTest.java:86) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:51) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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(StatementAdap
[jira] [Comment Edited] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727594#comment-14727594 ] Uwe Schindler edited comment on LUCENE-6774 at 9/2/15 4:59 PM: --- Hi, I checked the code after a beer and now I know what the issue is. In fact the ResourceUtils code did not change since Solr 4.0 where SOLR-4007 was reported on. This was using version 1.5.5 of Morphologik. The problem is very simple: # Morphologic tries context class loader first, obviously this fails for Solr (SOLR-3716) # As a second try it does "the right thing" but obviously wrong: It uses ResourceUtil.class.getResourceAsStream(), and this fails because when loading the resource it uses an absolute path inclusive package, but without a slash. This of course fails, because the file is not found. This causes Solr fail. # Finally it tries the system classloader. Of course the resource isn't there, because the system classloader has no morphologic jars The issue here is the stupid java difference: If you use a Classloader, you don't need leading slash. If you use Class#getResource() it resolves against current package, so you need a leading slash, if you want it with an absolute path. In single classloader applications this is no issue, because the context classloader always works, but not in Solr. was (Author: thetaphi): Hi, I checked the code after a beer and now I know what the issue is. In fact the ResourceUtils code did not change since Solr 4.0 where SOLR-4007 was reported on. This was using version 1.5.5 of Morphologik. The problem is very simple: # Morphologic tries context class loader first, obviously this fails for Solr (SOLR-3716) # As a second try it does "the right thing" but obviously wrong: It uses ResourceUtil.class.getResourceAsStream(), and this fails because when loading the resource it uses an absolute path inclusive package, but without a slash. This of course fails, because the file is not found. This causes Solr fail. # Finally it tries the system classloader. Of course the resource isn't there, because the system classloader has The issue here is the stupid java difference: If you use a Classloader, you don't need leading slash. If you use Class#getResource() it resolves against current package, so you need a leading slash, if you want it with an absolute path. In single classloader applications this is no issue, because the context classloader always works, but not in Solr. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7844) Zookeeper session expiry during shard leader election can cause multiple leaders.
[ https://issues.apache.org/jira/browse/SOLR-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-7844: -- Attachment: SOLR-7844-5x.patch Here is the 5x patch. > Zookeeper session expiry during shard leader election can cause multiple > leaders. > - > > Key: SOLR-7844 > URL: https://issues.apache.org/jira/browse/SOLR-7844 > Project: Solr > Issue Type: Bug >Affects Versions: 4.10.4 >Reporter: Mike Roberts >Assignee: Mark Miller > Fix For: Trunk, 5.4 > > Attachments: SOLR-7844-5x.patch, SOLR-7844.patch, SOLR-7844.patch, > SOLR-7844.patch, SOLR-7844.patch, SOLR-7844.patch, SOLR-7844.patch, > SOLR-7844.patch, SOLR-7844.patch, SOLR-7844.patch > > > If the ZooKeeper session expires for a host during shard leader election, the > ephemeral leader_elect nodes are removed. However the threads that were > processing the election are still present (and could believe the host won the > election). They will then incorrectly create leader nodes once a new > ZooKeeper session is established. > This introduces a subtle race condition that could cause two hosts to become > leader. > Scenario: > a three machine cluster, all of the machines are restarting at approximately > the same time. > The first machine starts, writes a leader_elect ephemeral node, it's the only > candidate in the election so it wins and starts the leadership process. As it > knows it has peers, it begins to block waiting for the peers to arrive. > During this period of blocking[1] the ZK connection drops and the session > expires. > A new ZK session is established, and ElectionContext.cancelElection is > called. Then register() is called and a new set of leader_elect ephemeral > nodes are created. > During the period between the ZK session expiring, and new set of > leader_elect nodes being created the second machine starts. > It creates its leader_elect ephemeral nodes, as there are no other nodes it > wins the election and starts the leadership process. As its still missing one > of its peers, it begins to block waiting for the third machine to join. > There is now a race between machine1 & machine2, both of whom think they are > the leader. > So far, this isn't too bad, because the machine that loses the race will fail > when it tries to create the /collection/name/leader/shard1 node (as it > already exists), and will rejoin the election. > While this is happening, machine3 has started and has queued for leadership > behind machine2. > If the loser of the race is machine2, when it rejoins the election it cancels > the current context, deleting it's leader_elect ephemeral nodes. > At this point, machine3 believes it has become leader (the watcher it has on > the leader_elect node fires), and it runs the LeaderElector::checkIfIAmLeader > method. This method DELETES the current /collection/name/leader/shard1 node, > then starts the leadership process (as all three machines are now running, it > does not block to wait). > So, machine1 won the race with machine2 and declared its leadership and > created the nodes. However, machine3 has just deleted them, and recreated > them for itself. So machine1 and machine3 both believe they are the leader. > I am thinking that the fix should be to cancel & close all election contexts > immediately on reconnect (we do cancel them, however it's run serially which > has blocking issues, and just canceling does not cause the wait loop to > exit). That election context logic already has checks on the closed flag, so > they should exit if they see it has been closed. > I'm working on a patch for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727600#comment-14727600 ] Uwe Schindler commented on LUCENE-6774: --- My proposal: - we should load the resource using local path (it is very simple, its just the language name) - [~dweiss] should maybe fix this in morphologik, the code is still broken. Maybe he should remove the whole class (he has a nocommit there) I'll supply a patch for a solution that always works not dealing with context classloader. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727594#comment-14727594 ] Uwe Schindler commented on LUCENE-6774: --- Hi, I checked the code after a beer and now I know what the issue is. In fact the ResourceUtils code did not change since Solr 4.0 where SOLR-4007 was reported on. This was using version 1.5.5 of Morphologik. The problem is very simple: # Morphologic tries context class loader first, obviously this fails for Solr (SOLR-3716) # As a second try it does "the right thing" but obviously wrong: It uses ResourceUtil.class.getResourceAsStream(), and this fails because when loading the resource it uses an absolute path inclusive package, but without a slash. This of course fails, because the file is not found. This causes Solr fail. # Finally it tries the system classloader. Of course the resource isn't there, because the system classloader has The issue here is the stupid java difference: If you use a Classloader, you don't need leading slash. If you use Class#getResource() it resolves against current package, so you need a leading slash, if you want it with an absolute path. In single classloader applications this is no issue, because the context classloader always works, but not in Solr. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6590) Explore different ways to apply boosts
[ https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-6590: - Attachment: LUCENE-6590.patch Patch updated to trunk. The patch is large and a bit painful to maintain so if you would like to review it, please let me know. Otherwise I will commit soon. > Explore different ways to apply boosts > -- > > Key: LUCENE-6590 > URL: https://issues.apache.org/jira/browse/LUCENE-6590 > Project: Lucene - Core > Issue Type: Wish >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, > LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch > > > Follow-up from LUCENE-6570: the fact that all queries are mutable in order to > allow for applying a boost raises issues since it makes queries bad cache > keys since their hashcode can change anytime. We could just document that > queries should never be modified after they have gone through IndexSearcher > but it would be even better if the API made queries impossible to mutate at > all. > I think there are two main options: > - either replace "void setBoost(boost)" with something like "Query > withBoost(boost)" which would return a clone that has a different boost > - or move boost handling outside of Query, for instance we could have a > (immutable) query impl that would be dedicated to applying boosts, that > queries that need to change boosts at rewrite time (such as BooleanQuery) > would use as a wrapper. > The latter idea is from Robert and I like it a lot given how often I either > introduced or found a bug which was due to the boost parameter being ignored. > Maybe there are other options, but I think this is worth exploring. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7569) Create an API to force a leader election between nodes
[ https://issues.apache.org/jira/browse/SOLR-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727549#comment-14727549 ] Ishan Chattopadhyaya commented on SOLR-7569: bq. 1. nit - RecoverShardTest has an unused notLeader1 variable Thanks. Made some refactoring to the test and this has gone away now. bq. 2.Shouldn't the "Wait for a long time for a steady state" piece of code be before the proxies for the two replicas are reopened? The LIR state will surely be set at indexing time and only if the proxy is closed. Also if you move that wait before the proxy is reopened then you are sure to have the LIR state as 'down'. This makes sense, I've made the change. bq. 3.The check for 'numActiveReplicas' and 'numReplicasOnLiveNodes' should be done after force refreshing the cluster state of the cloudClient otherwise spurious failures can happen I didn't know about this force update of the cluster state; I've now added it. bq. 4.nit - Why is sendDoc overridden in RecoverShardTest? The minRf is same, just the max retries has been increased and wait between retries has been decreased The tests were (and still are) taking too long, and reducing the wait from 30sec to 1sec was helpful. bq. 5.The OCMH.recoverShard() isn't unsetting the leader properly. It should be as simple as: Thanks, I've cleaned this up. bq. 6.Can you please write a test to ensure that this API works with 'async' parameter? TODO. bq.Leader is live but 'down' -> mark it 'active' This works now. Added testLeaderDown() method. bq.Leader itself is in LIR -> delete the LIR node This should work, since the API method first clears the LIR state. Couldn't add a test for this, since I couldn't simulate this state in a test. bq.Leader is not live: Replicas are live but 'down' or 'recovering' -> mark them 'active' This works now. Added testAllReplicasDownNoLeader() method. bq.Leader is not live: Replicas are live but in LIR -> delete the LIR nodes This works as last patch. The corresponding test is now at testReplicasInLIRNoLeader(). bq. Did you find out why/how that happened? If this is reproducible, can you please create an issue and post the test there? Added SOLR-7989 for this, will look deeper soon. > Create an API to force a leader election between nodes > -- > > Key: SOLR-7569 > URL: https://issues.apache.org/jira/browse/SOLR-7569 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Labels: difficulty-medium, impact-high > Attachments: SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, > SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, > SOLR-7569_lir_down_state_test.patch > > > There are many reasons why Solr will not elect a leader for a shard e.g. all > replicas' last published state was recovery or due to bugs which cause a > leader to be marked as 'down'. While the best solution is that they never get > into this state, we need a manual way to fix this when it does get into this > state. Right now we can do a series of dance involving bouncing the node > (since recovery paths between bouncing and REQUESTRECOVERY are different), > but that is difficult when running a large cluster. Although it is possible > that such a manual API may lead to some data loss but in some cases, it is > the only possible option to restore availability. > This issue proposes to build a new collection API which can be used to force > replicas into recovering a leader while avoiding data loss on a best effort > basis. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7569) Create an API to force a leader election between nodes
[ https://issues.apache.org/jira/browse/SOLR-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-7569: --- Attachment: SOLR-7569.patch > Create an API to force a leader election between nodes > -- > > Key: SOLR-7569 > URL: https://issues.apache.org/jira/browse/SOLR-7569 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Labels: difficulty-medium, impact-high > Attachments: SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, > SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, SOLR-7569.patch, > SOLR-7569_lir_down_state_test.patch > > > There are many reasons why Solr will not elect a leader for a shard e.g. all > replicas' last published state was recovery or due to bugs which cause a > leader to be marked as 'down'. While the best solution is that they never get > into this state, we need a manual way to fix this when it does get into this > state. Right now we can do a series of dance involving bouncing the node > (since recovery paths between bouncing and REQUESTRECOVERY are different), > but that is difficult when running a large cluster. Although it is possible > that such a manual API may lead to some data loss but in some cases, it is > the only possible option to restore availability. > This issue proposes to build a new collection API which can be used to force > replicas into recovering a leader while avoiding data loss on a best effort > basis. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727533#comment-14727533 ] Yonik Seeley commented on LUCENE-6774: -- Setting as a blocker until someone can determine if Solr is now broken or not. Hopefully Uwe is right and the code is no longer needed. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated LUCENE-6774: - Priority: Blocker (was: Major) > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Priority: Blocker > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727515#comment-14727515 ] Uwe Schindler commented on LUCENE-6774: --- Setting a context class loader inside "library" code is a big problem and should never ever done. It is good that Robert found this problem. The code has to be removed, sorry. Please let us fix the code by: # first adding a test # ask [~dweiss] if there were changes he did after this issue in Morphlogik's resource loading If both of this does not work would suggest to: # let Solr set the context ClassLoader: SOLR-3716 # just load the resource files ourselves and pass them to Dictionary#load(). This is mainly because I am not happy that Morfologik uses context ClassLoader at all. So I would like to fix this by loading the file ourselves from Class's classpath (or in the factory using ResourceLoader as provided by Lucene/Solr). > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[
https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727509#comment-14727509
]
Robert Muir commented on LUCENE-6774:
-
I don't care if i broke solr. solr can fix itself here instead of breaking
everyone else. its just that simple. lucene is a library.
if you think i'm giving solr the middle finger, then well, fine, it deserves it:
{noformat}
../´¯/)
,/¯../
...//
./´¯/'...'/´¯¯`·¸
../'/...//.../¨¯\
('(...´...´ ¯~/'...')
.\.'./
..''...\.. _.·´
\..(
..\.\...
{noformat}
> Remove solr hack in MorfologikFilter
>
>
> Key: LUCENE-6774
> URL: https://issues.apache.org/jira/browse/LUCENE-6774
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.3.1
>
> Attachments: LUCENE-6774.patch
>
>
> If solr wants to set the contextClassLoader because its classloading is
> fucked up, then it needs to do this hack itself: it should not be in lucene
> code.
> The current mess prevents use of this analyzer in other environments
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727503#comment-14727503 ] Uwe Schindler commented on LUCENE-6774: --- [~ysee...@gmail.com]: I'd suggest to write a test, which is not so easy for analysis extras. From looking at the code I see no reason why Morphologik's code may not find the files. I think this might have been fixed by Dawid to no longer solely depend on context classloader. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727500#comment-14727500 ] Yonik Seeley commented on LUCENE-6774: -- If it did break Solr, then we should have come up with a solution that works for *everyone*. Removing that code without even *knowing* if it broke solr is essentially giving us all the middle finger. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727498#comment-14727498 ] Robert Muir commented on LUCENE-6774: - this horrible hack prevents the analyzer from being used in other environments. sorry, solr can set contextclassloader in its own code. Doing it here is no reason to break *other non-solr apps* Believe it or not, there are people that use lucene without solr. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60) - Build # 14092 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14092/ Java: 64bit/jdk1.8.0_60 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication Error Message: Index: 0, Size: 0 Stack Trace: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at __randomizedtesting.SeedInfo.seed([509F3BBA970A580F:A7ECD5E251E2F7E9]:0) at java.util.ArrayList.rangeCheck(ArrayList.java:653) at java.util.ArrayList.get(ArrayList.java:429) at org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1239) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 9680 lines...] [junit4] Suite: org.apache.solr.handler.TestReplicationHandler [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.handler.Tes
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727488#comment-14727488 ] Uwe Schindler commented on LUCENE-6774: --- I linked the issue that causes the havoc here. I don't think this is an issue anymore, because morphologik tries: # context classloader # own classloader # system classloader (in this order). I am not sure how this was implemented in the version used in SOLR-4007. Maybe [~dawid.weiss] knows more. I have he feeling that this is no issue anymore. We should add a test for Solr. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727490#comment-14727490 ] Yonik Seeley commented on LUCENE-6774: -- Hmmm, you essentially reverted SOLR-4007 Is that code no longer necessary, or will the error that SOLR-4007 resolved now happen again? I know SOLR-4007 didn't add a test (and maybe it's hard to do), but that's no reason to knowingly break Solr. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7984) totally bogus and missleading "no default request handler is registered" logged by RequestHandlers
[
https://issues.apache.org/jira/browse/SOLR-7984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-7984.
--
Resolution: Fixed
Fix Version/s: 5.4
Trunk
> totally bogus and missleading "no default request handler is registered"
> logged by RequestHandlers
> ---
>
> Key: SOLR-7984
> URL: https://issues.apache.org/jira/browse/SOLR-7984
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.1
>Reporter: Hoss Man
>Assignee: Noble Paul
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-7988.patch
>
>
> As noted on the user list by Scott Hollenbeck the following warning can be
> logged by solr...
> bq. no default request handler is registered (either '/select' or 'standard')
> ...even if there is both a handler named "standard" and a handler (in his
> case named "pinkPony") defined as default="true".
> The code in question appears to be total nonsense...
> {code}
> if(!handlers.alias( "/select","")){
> if(!handlers.alias( "standard","")){
> log.warn("no default request handler is registered (either '/select'
> or 'standard')");
> }
> }
> {code}
> * PluginBag.alias is not documented, but appears to be a mutating operation
> that _adds_ an alias if and only if the first arg is aname of something that
> exists, and the second arg is a name that does not already exist -- returning
> true if the alias is added
> * if an alias already exists with the (default) name "" (which
> initHandlersFromConfig takes care of registring before this code) then
> neither of these can be made the new default.
> * just because neither of these aren't made the default here, doesn't mean
> there isn't already a default handler -- it actually means the exact oposite
> * if the goal was to log an error when there is no default, then that should
> have just been checked directly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7984) totally bogus and missleading "no default request handler is registered" logged by RequestHandlers
[
https://issues.apache.org/jira/browse/SOLR-7984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727482#comment-14727482
]
ASF subversion and git services commented on SOLR-7984:
---
Commit 1700841 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1700841 ]
SOLR-7984: wrong and misleading error message 'no default request handler is
registered'
> totally bogus and missleading "no default request handler is registered"
> logged by RequestHandlers
> ---
>
> Key: SOLR-7984
> URL: https://issues.apache.org/jira/browse/SOLR-7984
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.1
>Reporter: Hoss Man
>Assignee: Noble Paul
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-7988.patch
>
>
> As noted on the user list by Scott Hollenbeck the following warning can be
> logged by solr...
> bq. no default request handler is registered (either '/select' or 'standard')
> ...even if there is both a handler named "standard" and a handler (in his
> case named "pinkPony") defined as default="true".
> The code in question appears to be total nonsense...
> {code}
> if(!handlers.alias( "/select","")){
> if(!handlers.alias( "standard","")){
> log.warn("no default request handler is registered (either '/select'
> or 'standard')");
> }
> }
> {code}
> * PluginBag.alias is not documented, but appears to be a mutating operation
> that _adds_ an alias if and only if the first arg is aname of something that
> exists, and the second arg is a name that does not already exist -- returning
> true if the alias is added
> * if an alias already exists with the (default) name "" (which
> initHandlersFromConfig takes care of registring before this code) then
> neither of these can be made the new default.
> * just because neither of these aren't made the default here, doesn't mean
> there isn't already a default handler -- it actually means the exact oposite
> * if the goal was to log an error when there is no default, then that should
> have just been checked directly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7984) totally bogus and missleading "no default request handler is registered" logged by RequestHandlers
[
https://issues.apache.org/jira/browse/SOLR-7984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727480#comment-14727480
]
ASF subversion and git services commented on SOLR-7984:
---
Commit 1700840 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1700840 ]
SOLR-7984: wrong and misleading error message 'no default request handler is
registered'
> totally bogus and missleading "no default request handler is registered"
> logged by RequestHandlers
> ---
>
> Key: SOLR-7984
> URL: https://issues.apache.org/jira/browse/SOLR-7984
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.1
>Reporter: Hoss Man
>Assignee: Noble Paul
> Attachments: SOLR-7988.patch
>
>
> As noted on the user list by Scott Hollenbeck the following warning can be
> logged by solr...
> bq. no default request handler is registered (either '/select' or 'standard')
> ...even if there is both a handler named "standard" and a handler (in his
> case named "pinkPony") defined as default="true".
> The code in question appears to be total nonsense...
> {code}
> if(!handlers.alias( "/select","")){
> if(!handlers.alias( "standard","")){
> log.warn("no default request handler is registered (either '/select'
> or 'standard')");
> }
> }
> {code}
> * PluginBag.alias is not documented, but appears to be a mutating operation
> that _adds_ an alias if and only if the first arg is aname of something that
> exists, and the second arg is a name that does not already exist -- returning
> true if the alias is added
> * if an alias already exists with the (default) name "" (which
> initHandlersFromConfig takes care of registring before this code) then
> neither of these can be made the new default.
> * just because neither of these aren't made the default here, doesn't mean
> there isn't already a default handler -- it actually means the exact oposite
> * if the goal was to log an error when there is no default, then that should
> have just been checked directly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727478#comment-14727478 ] ASF subversion and git services commented on LUCENE-6774: - Commit 1700839 from [~rcmuir] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1700839 ] LUCENE-6774: Remove solr hack in MorfologikFilter > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727467#comment-14727467 ] ASF subversion and git services commented on LUCENE-6774: - Commit 1700837 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1700837 ] LUCENE-6774: Remove solr hack in MorfologikFilter > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727462#comment-14727462 ] Robert Muir commented on LUCENE-6774: - I am committing this because such hacks should not be in lucene code. Please open a separate issue to deal with the solr hack better > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727461#comment-14727461 ] Robert Muir commented on LUCENE-6774: - Sorry, that is incorrect Uwe. Morfologik "tries" that loader, but it also does things correctly too. Look right here: https://github.com/morfologik/morfologik-stemming/blob/master/morfologik-fsa/src/main/java/morfologik/util/ResourceUtils.java#L40-L50 > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7836) Possible deadlock when closing refcounted index writers.
[ https://issues.apache.org/jira/browse/SOLR-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727456#comment-14727456 ] Erick Erickson commented on SOLR-7836: -- Worth merging into 5.3 in case a 5.3.1 gets cut? > Possible deadlock when closing refcounted index writers. > > > Key: SOLR-7836 > URL: https://issues.apache.org/jira/browse/SOLR-7836 > Project: Solr > Issue Type: Bug >Reporter: Erick Erickson >Assignee: Erick Erickson > Fix For: Trunk, 5.4 > > Attachments: SOLR-7836-reorg.patch, SOLR-7836-synch.patch, > SOLR-7836.patch, SOLR-7836.patch, SOLR-7836.patch, SOLR-7836.patch, > SOLR-7836.patch, deadlock_3.res.zip, deadlock_5_pass_iw.res.zip, deadlock_test > > > Preliminary patch for what looks like a possible race condition between > writerFree and pauseWriter in DefaultSorlCoreState. > Looking for comments and/or why I'm completely missing the boat. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6774) Remove solr hack in MorfologikFilter
[
https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727452#comment-14727452
]
Uwe Schindler commented on LUCENE-6774:
---
I think the main problem is Morphologik that reads the resources from the
context classloader - which is just wrong.
I'd suggest to not use the static {{Dictionary#getForLanguage}} and instead
load the FSA with the methods taking InputStream or URL from resources. We just
need to duplicate the ISO code -> Resource file name code and then pass the
resource URL from the "right" classloader to the load() methods.
I can have a look.
> Remove solr hack in MorfologikFilter
>
>
> Key: LUCENE-6774
> URL: https://issues.apache.org/jira/browse/LUCENE-6774
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 5.3.1
>
> Attachments: LUCENE-6774.patch
>
>
> If solr wants to set the contextClassLoader because its classloading is
> fucked up, then it needs to do this hack itself: it should not be in lucene
> code.
> The current mess prevents use of this analyzer in other environments
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6774) Remove solr hack in MorfologikFilter
[ https://issues.apache.org/jira/browse/LUCENE-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-6774: Attachment: LUCENE-6774.patch patch. > Remove solr hack in MorfologikFilter > > > Key: LUCENE-6774 > URL: https://issues.apache.org/jira/browse/LUCENE-6774 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 5.3.1 > > Attachments: LUCENE-6774.patch > > > If solr wants to set the contextClassLoader because its classloading is > fucked up, then it needs to do this hack itself: it should not be in lucene > code. > The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6774) Remove solr hack in MorfologikFilter
Robert Muir created LUCENE-6774: --- Summary: Remove solr hack in MorfologikFilter Key: LUCENE-6774 URL: https://issues.apache.org/jira/browse/LUCENE-6774 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Fix For: 5.3.1 If solr wants to set the contextClassLoader because its classloading is fucked up, then it needs to do this hack itself: it should not be in lucene code. The current mess prevents use of this analyzer in other environments -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8002) Field aliases support for SQL queries
[ https://issues.apache.org/jira/browse/SOLR-8002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727429#comment-14727429 ] Joel Bernstein commented on SOLR-8002: -- This makes sense. I haven't had a chance to review SOLR-7669 yet. [~susheel2...@gmail.com], if you're working on a patch you might want to see if you can work with the SelectStream. You'll need to apply the patch from SOLR-7669 as it's not yet in trunk. > Field aliases support for SQL queries > - > > Key: SOLR-8002 > URL: https://issues.apache.org/jira/browse/SOLR-8002 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: Trunk >Reporter: Susheel Kumar > > Currently field aliases are not supported for SQL queries against SQL > Handler. E.g. below SQL query > select id,name as product_name from techproducts limit 20 > currently fails as data returned contains still "name" as the field/column > key than product_name -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7984) totally bogus and missleading "no default request handler is registered" logged by RequestHandlers
[
https://issues.apache.org/jira/browse/SOLR-7984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-7984:
-
Attachment: SOLR-7988.patch
> totally bogus and missleading "no default request handler is registered"
> logged by RequestHandlers
> ---
>
> Key: SOLR-7984
> URL: https://issues.apache.org/jira/browse/SOLR-7984
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.1
>Reporter: Hoss Man
>Assignee: Noble Paul
> Attachments: SOLR-7988.patch
>
>
> As noted on the user list by Scott Hollenbeck the following warning can be
> logged by solr...
> bq. no default request handler is registered (either '/select' or 'standard')
> ...even if there is both a handler named "standard" and a handler (in his
> case named "pinkPony") defined as default="true".
> The code in question appears to be total nonsense...
> {code}
> if(!handlers.alias( "/select","")){
> if(!handlers.alias( "standard","")){
> log.warn("no default request handler is registered (either '/select'
> or 'standard')");
> }
> }
> {code}
> * PluginBag.alias is not documented, but appears to be a mutating operation
> that _adds_ an alias if and only if the first arg is aname of something that
> exists, and the second arg is a name that does not already exist -- returning
> true if the alias is added
> * if an alias already exists with the (default) name "" (which
> initHandlersFromConfig takes care of registring before this code) then
> neither of these can be made the new default.
> * just because neither of these aren't made the default here, doesn't mean
> there isn't already a default handler -- it actually means the exact oposite
> * if the goal was to log an error when there is no default, then that should
> have just been checked directly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727381#comment-14727381 ] ASF subversion and git services commented on LUCENE-6699: - Commit 1700820 from [~mikemccand] in branch 'dev/branches/lucene6699' [ https://svn.apache.org/r1700820 ] LUCENE-6699: fix precommit > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60) - Build # 13811 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13811/
Java: 64bit/jdk1.8.0_60 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
1 tests failed.
FAILED: org.apache.solr.cloud.HttpPartitionTest.test
Error Message:
Didn't see all replicas for shard shard1 in c8n_1x2 come up within 3 ms!
ClusterState: { "collection1":{ "replicationFactor":"1", "shards":{
"shard1":{ "range":"8000-", "state":"active",
"replicas":{"core_node2":{ "core":"collection1",
"base_url":"http://127.0.0.1:44349";,
"node_name":"127.0.0.1:44349_", "state":"active",
"leader":"true"}}}, "shard2":{ "range":"0-7fff",
"state":"active", "replicas":{ "core_node1":{
"core":"collection1", "base_url":"http://127.0.0.1:49806";,
"node_name":"127.0.0.1:49806_", "state":"active",
"leader":"true"}, "core_node3":{ "core":"collection1",
"base_url":"http://127.0.0.1:59494";,
"node_name":"127.0.0.1:59494_", "state":"active",
"router":{"name":"compositeId"}, "maxShardsPerNode":"1",
"autoAddReplicas":"false", "autoCreated":"true"}, "control_collection":{
"replicationFactor":"1", "shards":{"shard1":{
"range":"8000-7fff", "state":"active",
"replicas":{"core_node1":{ "core":"collection1",
"base_url":"http://127.0.0.1:50685";,
"node_name":"127.0.0.1:50685_", "state":"active",
"leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false",
"autoCreated":"true"}, "c8n_1x2":{ "replicationFactor":"2",
"shards":{"shard1":{ "range":"8000-7fff",
"state":"active", "replicas":{ "core_node1":{
"core":"c8n_1x2_shard1_replica1",
"base_url":"http://127.0.0.1:49806";,
"node_name":"127.0.0.1:49806_", "state":"recovering"},
"core_node2":{ "core":"c8n_1x2_shard1_replica2",
"base_url":"http://127.0.0.1:44349";,
"node_name":"127.0.0.1:44349_", "state":"active",
"leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false"}}
Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in c8n_1x2
come up within 3 ms! ClusterState: {
"collection1":{
"replicationFactor":"1",
"shards":{
"shard1":{
"range":"8000-",
"state":"active",
"replicas":{"core_node2":{
"core":"collection1",
"base_url":"http://127.0.0.1:44349";,
"node_name":"127.0.0.1:44349_",
"state":"active",
"leader":"true"}}},
"shard2":{
"range":"0-7fff",
"state":"active",
"replicas":{
"core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:49806";,
"node_name":"127.0.0.1:49806_",
"state":"active",
"leader":"true"},
"core_node3":{
"core":"collection1",
"base_url":"http://127.0.0.1:59494";,
"node_name":"127.0.0.1:59494_",
"state":"active",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true"},
"control_collection":{
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:50685";,
"node_name":"127.0.0.1:50685_",
"state":"active",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true"},
"c8n_1x2":{
"replicationFactor":"2",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node1":{
"core":"c8n_1x2_shard1_replica1",
"base_url":"http://127.0.0.1:49806";,
"node_name":"127.0.0.1:49806_",
"state":"recovering"},
"core_node2":{
"core":"c8n_1x2_shard1_replica2",
"base_url":"http://127.0.0.1:44349";,
"node_name":"127.0.0.1:44349_",
"state":"active",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false"}}
at
__randomizedtesting.SeedInfo.seed([5EBDF3497AF2F18:8DBFE0EE395342E0]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.AbstractFullDistribZkTestBase.ensureAllRepli
[jira] [Commented] (SOLR-7978) Really fix the example/files update-script Java version issues
[
https://issues.apache.org/jira/browse/SOLR-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727377#comment-14727377
]
Uwe Schindler commented on SOLR-7978:
-
{code:javascript}
analyzer.tokenStream("subject", new
java.io.StringReader(doc.getFieldValue("subject")))
{code}
Since long time, Analyzer also takes {{String}}, so no need for
{{StringReader}}. This is also faster (doesn't matter in JS, of course):
[http://lucene.apache.org/core/5_3_0/core/org/apache/lucene/analysis/Analyzer.html#tokenStream(java.lang.String,%20java.lang.String)]
> Really fix the example/files update-script Java version issues
> --
>
> Key: SOLR-7978
> URL: https://issues.apache.org/jira/browse/SOLR-7978
> Project: Solr
> Issue Type: Bug
> Components: examples
>Affects Versions: 5.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: 5.4
>
> Attachments: SOLR-7978.patch
>
>
> SOLR-7652 addressed this issue by having a Java7 version of the script for 5x
> and a Java8 version on trunk. 5x on Java8 is broken though. I wager that
> there's got to be some incantations that can make the same script work on
> Java 7 and 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6773) Always flatten nested conjunctions
[ https://issues.apache.org/jira/browse/LUCENE-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-6773: - Attachment: LUCENE-6773.patch Here is a patch. > Always flatten nested conjunctions > -- > > Key: LUCENE-6773 > URL: https://issues.apache.org/jira/browse/LUCENE-6773 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Attachments: LUCENE-6773.patch > > > LUCENE-6585 started the work to flatten nested conjunctions, but this only > works with approximations. Otherwise a ConjunctionScorer is passed to > ConjunctionDISI.intersect, and is not flattened since it is not an instance > of ConjunctionDISI. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6773) Always flatten nested conjunctions
Adrien Grand created LUCENE-6773: Summary: Always flatten nested conjunctions Key: LUCENE-6773 URL: https://issues.apache.org/jira/browse/LUCENE-6773 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor LUCENE-6585 started the work to flatten nested conjunctions, but this only works with approximations. Otherwise a ConjunctionScorer is passed to ConjunctionDISI.intersect, and is not flattened since it is not an instance of ConjunctionDISI. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
