[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_92) - Build # 885 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/885/ Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithTimeDelay Error Message: Could not find collection : c1 Stack Trace: org.apache.solr.common.SolrException: Could not find collection : c1 at __randomizedtesting.SeedInfo.seed([C782C1C928F048C8:B81C764C41926542]:0) at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:192) at org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:130) at org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithTimeDelay(ZkStateReaderTest.java:52) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 12155 lines...] [junit4] Suite: org.apache.solr.cloud.overseer.ZkStateReaderTest [junit4] 2> Creating dataDir:
[jira] [Commented] (LUCENE-7287) New lemma-tizer plugin for ukrainian language.
[ https://issues.apache.org/jira/browse/LUCENE-7287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326753#comment-15326753 ] Andriy Rysin commented on LUCENE-7287: -- Thanks for the hint, I've changed the code to use MappingCharFilter. It's slightly slower but architecturally more correct. > New lemma-tizer plugin for ukrainian language. > -- > > Key: LUCENE-7287 > URL: https://issues.apache.org/jira/browse/LUCENE-7287 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Dmytro Hambal >Priority: Minor > Labels: analysis, language, plugin > > Hi all, > I wonder whether you are interested in supporting a plugin which provides a > mapping between ukrainian word forms and their lemmas. Some tests and docs go > out-of-the-box =) . > https://github.com/mrgambal/elasticsearch-ukrainian-lemmatizer > It's really simple but still works and generates some value for its users. > More: https://github.com/elastic/elasticsearch/issues/18303 -- 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-6.x-Windows (32bit/jdk1.8.0_92) - Build # 245 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/245/ Java: 32bit/jdk1.8.0_92 -client -XX:+UseSerialGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: ObjectTracker found 8 object(s) that were not released!!! [MockDirectoryWrapper, MDCAwareThreadPoolExecutor, TransactionLog, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, TransactionLog, MockDirectoryWrapper, MockDirectoryWrapper] Stack Trace: java.lang.AssertionError: ObjectTracker found 8 object(s) that were not released!!! [MockDirectoryWrapper, MDCAwareThreadPoolExecutor, TransactionLog, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, TransactionLog, MockDirectoryWrapper, MockDirectoryWrapper] at __randomizedtesting.SeedInfo.seed([64B9B58E5A09D6EF]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257) at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_64B9B58E5A09D6EF-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog\tlog.001: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_64B9B58E5A09D6EF-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog\tlog.001: The process cannot access the file because it is being used by another process. C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_64B9B58E5A09D6EF-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_64B9B58E5A09D6EF-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_64B9B58E5A09D6EF-001\tempDir-001\node2\testschemaapi_shard1_replica2\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_64B9B58E5A09D6EF-001\tempDir-001\node2\testschemaapi_shard1_replica2\data
[jira] [Commented] (SOLR-6394) Managed Synonyms should support deleting all synonyms or replacing a single one
[ https://issues.apache.org/jira/browse/SOLR-6394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326718#comment-15326718 ] Vani commented on SOLR-6394: Would be very helpful if we do have an API : support to delete all stopwords and synonyms , multiple stopwords/synonyms. > Managed Synonyms should support deleting all synonyms or replacing a single > one > --- > > Key: SOLR-6394 > URL: https://issues.apache.org/jira/browse/SOLR-6394 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Affects Versions: 4.9 >Reporter: Mathias H. >Priority: Minor > Labels: difficulty-medium, impact-medium, managed, rest, synonyms > > Currently it is only possible to add synonyms and deleting single synonyms. > If you need to delete all synonyms you have to get the list and then sending > an delete request to every single synonym. Also you can't overwrite a synonym > but only append it. > It would be more convenient to have additional possibilities: > Deleting all synonyms > curl -XDELETE > http://localhost:8983/solr/collection1/schema/analysis/synonyms/english/ > Overwriting a single synonym > curl -XPUT > http://localhost:8983/solr/collection1/schema/analysis/synonyms/english/apple > Add a synonym / append to an existing synonym > curl -XPOST > http://localhost:8983/solr/collection1/schema/analysis/synonyms/english/apple -- 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-NightlyTests-6.x - Build # 91 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/91/ 4 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Timeout occured while waiting response from server at: https://127.0.0.1:34655/lb_/i Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: https://127.0.0.1:34655/lb_/i at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:601) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:399) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:515) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 16977 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16977/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseConcMarkSweepGC
1 tests failed.
FAILED: org.apache.solr.handler.TestReqParamsAPI.test
Error Message:
Could not get expected value 'P val' for path 'response/params/y/p' full
output: { "responseHeader":{ "status":0, "QTime":0}, "response":{
"znodeVersion":2, "params":{ "x":{ "a":"A val",
"b":"B val", "":{"v":0}}, "y":{ "c":"CY val modified",
"b":"BY val", "i":20, "d":[ "val 1",
"val 2"], "e":"EY val", "":{"v":1}, from server:
http://127.0.0.1:38398/uqdjr/collection1
Stack Trace:
java.lang.AssertionError: Could not get expected value 'P val' for path
'response/params/y/p' full output: {
"responseHeader":{
"status":0,
"QTime":0},
"response":{
"znodeVersion":2,
"params":{
"x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
"y":{
"c":"CY val modified",
"b":"BY val",
"i":20,
"d":[
"val 1",
"val 2"],
"e":"EY val",
"":{"v":1}, from server: http://127.0.0.1:38398/uqdjr/collection1
at
__randomizedtesting.SeedInfo.seed([D916F1FB67D7A59E:5142CE21C92BC866]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:481)
at
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:216)
at
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
[jira] [Commented] (SOLR-8812) ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND and mm is not explicitly set
[
https://issues.apache.org/jira/browse/SOLR-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326691#comment-15326691
]
Jan Høydahl commented on SOLR-8812:
---
Thanks Steve for pushing this through!
> ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND and mm is
> not explicitly set
> -
>
> Key: SOLR-8812
> URL: https://issues.apache.org/jira/browse/SOLR-8812
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 5.5
>Reporter: Ryan Steinberg
>Assignee: Steve Rowe
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8812-barbie.patch, SOLR-8812.patch,
> SOLR-8812.patch, SOLR-8812.patch
>
>
> The edismax parser ignores Boolean OR in queries when q.op=AND. This behavior
> is new to Solr 5.5.0 and an unexpected major change.
> Example:
> "q": "id:12345 OR zz",
> "defType": "edismax",
> "q.op": "AND",
> where "12345" is a known document ID and "zz" is a string NOT present
> in my data
> Version 5.5.0 produces zero results:
> "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+((id:12345
> DisjunctionMaxQuery((text:zz)))~2))/no_coord",
> "parsedquery_toString": "+((id:12345 (text:zz))~2)",
> "explain": {},
> "QParser": "ExtendedDismaxQParser"
> Version 5.4.0 produces one result as expected
> "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+(id:12345
> DisjunctionMaxQuery((text:zz/no_coord",
> "parsedquery_toString": "+(id:12345 (text:zz))"
> "explain": {},
> "QParser": "ExtendedDismaxQParser"
--
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-master-Windows (64bit/jdk1.8.0_92) - Build # 5907 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5907/ Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: ObjectTracker found 4 object(s) that were not released!!! [TransactionLog, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MockDirectoryWrapper] Stack Trace: java.lang.AssertionError: ObjectTracker found 4 object(s) that were not released!!! [TransactionLog, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MockDirectoryWrapper] at __randomizedtesting.SeedInfo.seed([D280FC1EFB095D24]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:256) at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_D280FC1EFB095D24-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog\tlog.000: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_D280FC1EFB095D24-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog\tlog.000: The process cannot access the file because it is being used by another process. C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_D280FC1EFB095D24-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_D280FC1EFB095D24-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_D280FC1EFB095D24-001\tempDir-001\node2\testschemaapi_shard1_replica2\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_D280FC1EFB095D24-001\tempDir-001\node2\testschemaapi_shard1_replica2\data C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_D280FC1EFB095D24-001\tempDir-001\node2\testschemaapi_shard1_replica2:
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 644 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/644/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC No tests ran. Build Log: [...truncated 11744 lines...] ERROR: Connection was broken: java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2325) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2794) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:801) at java.io.ObjectInputStream.(ObjectInputStream.java:299) at hudson.remoting.ObjectInputStreamEx.(ObjectInputStreamEx.java:48) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) Build step 'Invoke Ant' marked build as failure ERROR: Step ‘Archive the artifacts’ failed: no workspace for Lucene-Solr-master-Solaris #644 ERROR: Step ‘Scan for compiler warnings’ failed: no workspace for Lucene-Solr-master-Solaris #644 ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for Lucene-Solr-master-Solaris #644 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] [Resolved] (SOLR-2199) DIH JdbcDataSource - Support multiple resultsets
[ https://issues.apache.org/jira/browse/SOLR-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev resolved SOLR-2199. Resolution: Fixed > DIH JdbcDataSource - Support multiple resultsets > > > Key: SOLR-2199 > URL: https://issues.apache.org/jira/browse/SOLR-2199 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4.1 >Reporter: Mark Waddle >Assignee: Mikhail Khludnev > Attachments: SOLR-2199.patch, SOLR-2199.patch > > > Database servers can return multiple result sets from a single statement. > This can be beneficial for indexing because it reduces the number of > connections and statements being executed against a database, therefore > reducing overhead. The JDBC Statement object supports reading multiple > ResultSets. Support should be added to the JdbcDataSource to take advantage > of 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-2199) DIH JdbcDataSource - Support multiple resultsets
[ https://issues.apache.org/jira/browse/SOLR-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326636#comment-15326636 ] ASF subversion and git services commented on SOLR-2199: --- Commit c67258694be9e0ce9a0631f64d14a7853e81dc9a in lucene-solr's branch refs/heads/branch_6x from [~mkhludnev] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c672586 ] SOLR-2199: DataImportHandler (DIH) JdbcDataSource supports multiple resultsets per query > DIH JdbcDataSource - Support multiple resultsets > > > Key: SOLR-2199 > URL: https://issues.apache.org/jira/browse/SOLR-2199 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4.1 >Reporter: Mark Waddle >Assignee: Mikhail Khludnev > Attachments: SOLR-2199.patch, SOLR-2199.patch > > > Database servers can return multiple result sets from a single statement. > This can be beneficial for indexing because it reduces the number of > connections and statements being executed against a database, therefore > reducing overhead. The JDBC Statement object supports reading multiple > ResultSets. Support should be added to the JdbcDataSource to take advantage > of 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-2199) DIH JdbcDataSource - Support multiple resultsets
[ https://issues.apache.org/jira/browse/SOLR-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326635#comment-15326635 ] ASF subversion and git services commented on SOLR-2199: --- Commit fce10ae1097fa7f764516f2b343365e86afc273d in lucene-solr's branch refs/heads/master from [~mkhludnev] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fce10ae ] SOLR-2199: DataImportHandler (DIH) JdbcDataSource supports multiple resultsets per query > DIH JdbcDataSource - Support multiple resultsets > > > Key: SOLR-2199 > URL: https://issues.apache.org/jira/browse/SOLR-2199 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4.1 >Reporter: Mark Waddle >Assignee: Mikhail Khludnev > Attachments: SOLR-2199.patch, SOLR-2199.patch > > > Database servers can return multiple result sets from a single statement. > This can be beneficial for indexing because it reduces the number of > connections and statements being executed against a database, therefore > reducing overhead. The JDBC Statement object supports reading multiple > ResultSets. Support should be added to the JdbcDataSource to take advantage > of 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] [Resolved] (LUCENE-5931) DirectoryReader.openIfChanged(oldReader, commit) incorrectly assumes given commit point has deletes/field updates
[
https://issues.apache.org/jira/browse/LUCENE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-5931.
Resolution: Fixed
Thanks [~jpountz] for pinging me about this almost lost issue!
> DirectoryReader.openIfChanged(oldReader, commit) incorrectly assumes given
> commit point has deletes/field updates
> -
>
> Key: LUCENE-5931
> URL: https://issues.apache.org/jira/browse/LUCENE-5931
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
>Affects Versions: 4.6.1
>Reporter: Vitaly Funstein
>Assignee: Michael McCandless
>Priority: Critical
> Fix For: master (7.0), 6.2
>
> Attachments: CommitReuseTest.java, LUCENE-5931.patch,
> LUCENE-5931.patch, LUCENE-5931.patch, LUCENE-5931.patch, LUCENE-5931.patch
>
>
> {{StandardDirectoryReader}} assumes that the segments from commit point have
> deletes, when they may not, yet the original SegmentReader for the segment
> that we are trying to reuse does. This is evident when running attached JUnit
> test case with asserts enabled (default):
> {noformat}
> java.lang.AssertionError
> at
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:188)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:326)
> at
> org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:320)
> at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:702)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:315)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:311)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
> at
> org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:183)
> {noformat}
> or, if asserts are disabled then it falls through into NPE:
> {noformat}
> java.lang.NullPointerException
> at java.io.File.(File.java:305)
> at
> org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:80)
> at
> org.apache.lucene.codecs.lucene40.BitVector.(BitVector.java:327)
> at
> org.apache.lucene.codecs.lucene40.Lucene40LiveDocsFormat.readLiveDocs(Lucene40LiveDocsFormat.java:90)
> at org.apache.lucene.index.SegmentReader.(SegmentReader.java:131)
> at
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:194)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:326)
> at
> org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:320)
> at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:702)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:315)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:311)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
> at
> org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:183)
> {noformat}
--
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-5931) DirectoryReader.openIfChanged(oldReader, commit) incorrectly assumes given commit point has deletes/field updates
[
https://issues.apache.org/jira/browse/LUCENE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326630#comment-15326630
]
ASF subversion and git services commented on LUCENE-5931:
-
Commit 6b0b119074f4cd32adc2388fbcc01f2aa70c7d5d in lucene-solr's branch
refs/heads/branch_6x from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6b0b119 ]
LUCENE-5931: detect when segments were (illegally) replaced when re-opening an
IndexReader
> DirectoryReader.openIfChanged(oldReader, commit) incorrectly assumes given
> commit point has deletes/field updates
> -
>
> Key: LUCENE-5931
> URL: https://issues.apache.org/jira/browse/LUCENE-5931
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
>Affects Versions: 4.6.1
>Reporter: Vitaly Funstein
>Assignee: Michael McCandless
>Priority: Critical
> Fix For: master (7.0), 6.2
>
> Attachments: CommitReuseTest.java, LUCENE-5931.patch,
> LUCENE-5931.patch, LUCENE-5931.patch, LUCENE-5931.patch, LUCENE-5931.patch
>
>
> {{StandardDirectoryReader}} assumes that the segments from commit point have
> deletes, when they may not, yet the original SegmentReader for the segment
> that we are trying to reuse does. This is evident when running attached JUnit
> test case with asserts enabled (default):
> {noformat}
> java.lang.AssertionError
> at
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:188)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:326)
> at
> org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:320)
> at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:702)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:315)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:311)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
> at
> org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:183)
> {noformat}
> or, if asserts are disabled then it falls through into NPE:
> {noformat}
> java.lang.NullPointerException
> at java.io.File.(File.java:305)
> at
> org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:80)
> at
> org.apache.lucene.codecs.lucene40.BitVector.(BitVector.java:327)
> at
> org.apache.lucene.codecs.lucene40.Lucene40LiveDocsFormat.readLiveDocs(Lucene40LiveDocsFormat.java:90)
> at org.apache.lucene.index.SegmentReader.(SegmentReader.java:131)
> at
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:194)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:326)
> at
> org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:320)
> at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:702)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:315)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:311)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
> at
> org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:183)
> {noformat}
--
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-7287) New lemma-tizer plugin for ukrainian language.
[ https://issues.apache.org/jira/browse/LUCENE-7287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326628#comment-15326628 ] Ahmet Arslan commented on LUCENE-7287: -- May be MappingCharFilter could be used instead of a token filter? > New lemma-tizer plugin for ukrainian language. > -- > > Key: LUCENE-7287 > URL: https://issues.apache.org/jira/browse/LUCENE-7287 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Dmytro Hambal >Priority: Minor > Labels: analysis, language, plugin > > Hi all, > I wonder whether you are interested in supporting a plugin which provides a > mapping between ukrainian word forms and their lemmas. Some tests and docs go > out-of-the-box =) . > https://github.com/mrgambal/elasticsearch-ukrainian-lemmatizer > It's really simple but still works and generates some value for its users. > More: https://github.com/elastic/elasticsearch/issues/18303 -- 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-5931) DirectoryReader.openIfChanged(oldReader, commit) incorrectly assumes given commit point has deletes/field updates
[
https://issues.apache.org/jira/browse/LUCENE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326627#comment-15326627
]
ASF subversion and git services commented on LUCENE-5931:
-
Commit 664e39292bd0a90ed6f20debc872ab74a1d7294f in lucene-solr's branch
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=664e392 ]
LUCENE-5931: detect when segments were (illegally) replaced when re-opening an
IndexReader
> DirectoryReader.openIfChanged(oldReader, commit) incorrectly assumes given
> commit point has deletes/field updates
> -
>
> Key: LUCENE-5931
> URL: https://issues.apache.org/jira/browse/LUCENE-5931
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
>Affects Versions: 4.6.1
>Reporter: Vitaly Funstein
>Assignee: Michael McCandless
>Priority: Critical
> Fix For: master (7.0), 6.2
>
> Attachments: CommitReuseTest.java, LUCENE-5931.patch,
> LUCENE-5931.patch, LUCENE-5931.patch, LUCENE-5931.patch, LUCENE-5931.patch
>
>
> {{StandardDirectoryReader}} assumes that the segments from commit point have
> deletes, when they may not, yet the original SegmentReader for the segment
> that we are trying to reuse does. This is evident when running attached JUnit
> test case with asserts enabled (default):
> {noformat}
> java.lang.AssertionError
> at
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:188)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:326)
> at
> org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:320)
> at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:702)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:315)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:311)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
> at
> org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:183)
> {noformat}
> or, if asserts are disabled then it falls through into NPE:
> {noformat}
> java.lang.NullPointerException
> at java.io.File.(File.java:305)
> at
> org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:80)
> at
> org.apache.lucene.codecs.lucene40.BitVector.(BitVector.java:327)
> at
> org.apache.lucene.codecs.lucene40.Lucene40LiveDocsFormat.readLiveDocs(Lucene40LiveDocsFormat.java:90)
> at org.apache.lucene.index.SegmentReader.(SegmentReader.java:131)
> at
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:194)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:326)
> at
> org.apache.lucene.index.StandardDirectoryReader$2.doBody(StandardDirectoryReader.java:320)
> at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:702)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenFromCommit(StandardDirectoryReader.java:315)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:311)
> at
> org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
> at
> org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:183)
> {noformat}
--
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-2199) DIH JdbcDataSource - Support multiple resultsets
[ https://issues.apache.org/jira/browse/SOLR-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326625#comment-15326625 ] Mikhail Khludnev commented on SOLR-2199: the patch seems fine. committing. > DIH JdbcDataSource - Support multiple resultsets > > > Key: SOLR-2199 > URL: https://issues.apache.org/jira/browse/SOLR-2199 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4.1 >Reporter: Mark Waddle >Assignee: Mikhail Khludnev > Attachments: SOLR-2199.patch, SOLR-2199.patch > > > Database servers can return multiple result sets from a single statement. > This can be beneficial for indexing because it reduces the number of > connections and statements being executed against a database, therefore > reducing overhead. The JDBC Statement object supports reading multiple > ResultSets. Support should be added to the JdbcDataSource to take advantage > of 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-7287) New lemma-tizer plugin for ukrainian language.
[ https://issues.apache.org/jira/browse/LUCENE-7287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326624#comment-15326624 ] Andriy Rysin commented on LUCENE-7287: -- I've added a token filter for unicode apostrophes and stress symbol. > New lemma-tizer plugin for ukrainian language. > -- > > Key: LUCENE-7287 > URL: https://issues.apache.org/jira/browse/LUCENE-7287 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Dmytro Hambal >Priority: Minor > Labels: analysis, language, plugin > > Hi all, > I wonder whether you are interested in supporting a plugin which provides a > mapping between ukrainian word forms and their lemmas. Some tests and docs go > out-of-the-box =) . > https://github.com/mrgambal/elasticsearch-ukrainian-lemmatizer > It's really simple but still works and generates some value for its users. > More: https://github.com/elastic/elasticsearch/issues/18303 -- 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-NightlyTests-master - Build # 1040 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1040/
11 tests failed.
FAILED:
org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload
Error Message:
expected:<[{indexVersion=1465750028630,generation=2,filelist=[_se.fdt, _se.fdx,
_se.fnm, _se.nvd, _se.nvm, _se.si, _se_FST50_0.doc, _se_FST50_0.tfp, _sq.fdt,
_sq.fdx, _sq.fnm, _sq.nvd, _sq.nvm, _sq.si, _sq_FST50_0.doc, _sq_FST50_0.tfp,
_t8.fdt, _t8.fdx, _t8.fnm, _t8.nvd, _t8.nvm, _t8.si, _t8_FST50_0.doc,
_t8_FST50_0.tfp, _t9.fdt, _t9.fdx, _t9.fnm, _t9.nvd, _t9.nvm, _t9.si,
_t9_FST50_0.doc, _t9_FST50_0.tfp, _tf.fdt, _tf.fdx, _tf.fnm, _tf.nvd, _tf.nvm,
_tf.si, _tf_FST50_0.doc, _tf_FST50_0.tfp, _th.fdt, _th.fdx, _th.fnm, _th.nvd,
_th.nvm, _th.si, _th_FST50_0.doc, _th_FST50_0.tfp, _tm.cfe, _tm.cfs, _tm.si,
_tn.fdt, _tn.fdx, _tn.fnm, _tn.nvd, _tn.nvm, _tn.si, _tn_FST50_0.doc,
_tn_FST50_0.tfp, _tq.cfe, _tq.cfs, _tq.si, _tr.fdt, _tr.fdx, _tr.fnm, _tr.nvd,
_tr.nvm, _tr.si, _tr_FST50_0.doc, _tr_FST50_0.tfp, _ts.fdt, _ts.fdx, _ts.fnm,
_ts.nvd, _ts.nvm, _ts.si, _ts_FST50_0.doc, _ts_FST50_0.tfp, _tt.fdt, _tt.fdx,
_tt.fnm, _tt.nvd, _tt.nvm, _tt.si, _tt_FST50_0.doc, _tt_FST50_0.tfp, _tu.fdt,
_tu.fdx, _tu.fnm, _tu.nvd, _tu.nvm, _tu.si, _tu_FST50_0.doc, _tu_FST50_0.tfp,
_tv.fdt, _tv.fdx, _tv.fnm, _tv.nvd, _tv.nvm, _tv.si, _tv_FST50_0.doc,
_tv_FST50_0.tfp, _tw.fdt, _tw.fdx, _tw.fnm, _tw.nvd, _tw.nvm, _tw.si,
_tw_FST50_0.doc, _tw_FST50_0.tfp, _tx.fdt, _tx.fdx, _tx.fnm, _tx.nvd, _tx.nvm,
_tx.si, _tx_FST50_0.doc, _tx_FST50_0.tfp, _ty.fdt, _ty.fdx, _ty.fnm, _ty.nvd,
_ty.nvm, _ty.si, _ty_FST50_0.doc, _ty_FST50_0.tfp, _tz.fdt, _tz.fdx, _tz.fnm,
_tz.nvd, _tz.nvm, _tz.si, _tz_FST50_0.doc, _tz_FST50_0.tfp, _u0.fdt, _u0.fdx,
_u0.fnm, _u0.nvd, _u0.nvm, _u0.si, _u0_FST50_0.doc, _u0_FST50_0.tfp, _u1.fdt,
_u1.fdx, _u1.fnm, _u1.nvd, _u1.nvm, _u1.si, _u1_FST50_0.doc, _u1_FST50_0.tfp,
_u2.fdt, _u2.fdx, _u2.fnm, _u2.nvd, _u2.nvm, _u2.si, _u2_FST50_0.doc,
_u2_FST50_0.tfp, _u3.fdt, _u3.fdx, _u3.fnm, _u3.nvd, _u3.nvm, _u3.si,
_u3_FST50_0.doc, _u3_FST50_0.tfp, segments_2]}]> but
was:<[{indexVersion=1465750028630,generation=2,filelist=[_se.fdt, _se.fdx,
_se.fnm, _se.nvd, _se.nvm, _se.si, _se_FST50_0.doc, _se_FST50_0.tfp, _sq.fdt,
_sq.fdx, _sq.fnm, _sq.nvd, _sq.nvm, _sq.si, _sq_FST50_0.doc, _sq_FST50_0.tfp,
_t8.fdt, _t8.fdx, _t8.fnm, _t8.nvd, _t8.nvm, _t8.si, _t8_FST50_0.doc,
_t8_FST50_0.tfp, _t9.fdt, _t9.fdx, _t9.fnm, _t9.nvd, _t9.nvm, _t9.si,
_t9_FST50_0.doc, _t9_FST50_0.tfp, _tf.fdt, _tf.fdx, _tf.fnm, _tf.nvd, _tf.nvm,
_tf.si, _tf_FST50_0.doc, _tf_FST50_0.tfp, _th.fdt, _th.fdx, _th.fnm, _th.nvd,
_th.nvm, _th.si, _th_FST50_0.doc, _th_FST50_0.tfp, _tm.cfe, _tm.cfs, _tm.si,
_tn.fdt, _tn.fdx, _tn.fnm, _tn.nvd, _tn.nvm, _tn.si, _tn_FST50_0.doc,
_tn_FST50_0.tfp, _tq.cfe, _tq.cfs, _tq.si, _tr.fdt, _tr.fdx, _tr.fnm, _tr.nvd,
_tr.nvm, _tr.si, _tr_FST50_0.doc, _tr_FST50_0.tfp, _ts.fdt, _ts.fdx, _ts.fnm,
_ts.nvd, _ts.nvm, _ts.si, _ts_FST50_0.doc, _ts_FST50_0.tfp, _tt.fdt, _tt.fdx,
_tt.fnm, _tt.nvd, _tt.nvm, _tt.si, _tt_FST50_0.doc, _tt_FST50_0.tfp, _tu.fdt,
_tu.fdx, _tu.fnm, _tu.nvd, _tu.nvm, _tu.si, _tu_FST50_0.doc, _tu_FST50_0.tfp,
_tv.fdt, _tv.fdx, _tv.fnm, _tv.nvd, _tv.nvm, _tv.si, _tv_FST50_0.doc,
_tv_FST50_0.tfp, _tw.fdt, _tw.fdx, _tw.fnm, _tw.nvd, _tw.nvm, _tw.si,
_tw_FST50_0.doc, _tw_FST50_0.tfp, _tx.fdt, _tx.fdx, _tx.fnm, _tx.nvd, _tx.nvm,
_tx.si, _tx_FST50_0.doc, _tx_FST50_0.tfp, _ty.fdt, _ty.fdx, _ty.fnm, _ty.nvd,
_ty.nvm, _ty.si, _ty_FST50_0.doc, _ty_FST50_0.tfp, _tz.fdt, _tz.fdx, _tz.fnm,
_tz.nvd, _tz.nvm, _tz.si, _tz_FST50_0.doc, _tz_FST50_0.tfp, _u0.fdt, _u0.fdx,
_u0.fnm, _u0.nvd, _u0.nvm, _u0.si, _u0_FST50_0.doc, _u0_FST50_0.tfp, _u1.fdt,
_u1.fdx, _u1.fnm, _u1.nvd, _u1.nvm, _u1.si, _u1_FST50_0.doc, _u1_FST50_0.tfp,
_u2.fdt, _u2.fdx, _u2.fnm, _u2.nvd, _u2.nvm, _u2.si, _u2_FST50_0.doc,
_u2_FST50_0.tfp, _u3.fdt, _u3.fdx, _u3.fnm, _u3.nvd, _u3.nvm, _u3.si,
_u3_FST50_0.doc, _u3_FST50_0.tfp, segments_2]},
{indexVersion=1465750028630,generation=3,filelist=[_tc.cfe, _tc.cfs, _tc.si,
_th.fdt, _th.fdx, _th.fnm, _th.nvd, _th.nvm, _th.si, _th_FST50_0.doc,
_th_FST50_0.tfp, _tn.fdt, _tn.fdx, _tn.fnm, _tn.nvd, _tn.nvm, _tn.si,
_tn_FST50_0.doc, _tn_FST50_0.tfp, _tt.fdt, _tt.fdx, _tt.fnm, _tt.nvd, _tt.nvm,
_tt.si, _tt_FST50_0.doc, _tt_FST50_0.tfp, _tu.fdt, _tu.fdx, _tu.fnm, _tu.nvd,
_tu.nvm, _tu.si, _tu_FST50_0.doc, _tu_FST50_0.tfp, _ty.fdt, _ty.fdx, _ty.fnm,
_ty.nvd, _ty.nvm, _ty.si, _ty_FST50_0.doc, _ty_FST50_0.tfp, _u3.fdt, _u3.fdx,
_u3.fnm, _u3.nvd, _u3.nvm, _u3.si, _u3_FST50_0.doc, _u3_FST50_0.tfp, _u4.cfe,
_u4.cfs, _u4.si, segments_3]}]>
Stack Trace:
java.lang.AssertionError:
expected:<[{indexVersion=1465750028630,generation=2,filelist=[_se.fdt, _se.fdx,
_se.fnm, _se.nvd, _se.nvm, _se.si, _se_FST50_0.doc, _se_FST50_0.tfp, _sq.fdt,
_sq.fdx, _sq.fnm, _sq.nvd, _sq.nvm, _sq.si, _sq_FST50_0.doc, _sq_FST50_0.tfp,
_t8.fdt, _t8.fdx, _t8.fnm, _t8.nvd, _t8.nvm, _t8.si, _t8_FST50_0.doc,
_t8_FST50_0.tfp,
[jira] [Updated] (LUCENE-7318) Graduate StandardAnalyzer out of analyzers module into core
[
https://issues.apache.org/jira/browse/LUCENE-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-7318:
---
Attachment: LUCENE-7318.patch
Rote patch, moving {{StandardAnalyzer/Tokenizer}}, and the utility
classes it uses, to core's oal.analysis module.
I left {{ClassicAnalyzer}} and {{UAX29URLEmailTokenizer}} in the
analysis module.
"ant test" passes but precommit is still angry about some javadocs
... I'll iterate.
The one non-rote change I did was to move the
{{ENGLISH_STOP_WORDS_SET}} from {{StopAnalyzer}} (still in analyzers
module) to {{StandardAnalyzer}}.
I also added "jflex" target to core's build.xml, to regenerate the
tokenizer.
I left {{ClassicAnalyzer}}, and the factories, in the analysis/common
module.
> Graduate StandardAnalyzer out of analyzers module into core
> ---
>
> Key: LUCENE-7318
> URL: https://issues.apache.org/jira/browse/LUCENE-7318
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7318.patch
>
>
> Spinoff from LUCENE-7314:
> {{StandardAnalyzer}} has progressed substantially since we broke out the
> analyzers module ... it now follows a real Unicode standard (UAX #29 Unicode
> Text Segmentation). It's also much faster than it used to be, since it
> switched to JFlex a while back. Many bug fixes, etc.
> I think it would make a good default for most Lucene users, and we should
> graduate it from the analyzers module into core, and make it the default for
> {{IndexWriter}}.
> It's really quite crazy that users must go digging in the analyzers module to
> get started with Lucene ... we don't make them dig through the codecs module
> to find a good default codec ...
--
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-6.1-Windows (32bit/jdk1.8.0_92) - Build # 7 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.1-Windows/7/
Java: 32bit/jdk1.8.0_92 -client -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([321388BA4FEAE276]: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([321388BA4FEAE276]:0)
Build Log:
[...truncated 12446 lines...]
[junit4] Suite: org.apache.solr.security.BasicAuthIntegrationTest
[junit4] 2> 806729 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[321388BA4FEAE276]) []
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
[junit4] 2> 806730 INFO (Thread-1812) [] o.a.s.c.ZkTestServer client
port:0.0.0.0/0.0.0.0:0
[junit4] 2> 806730 INFO (Thread-1812) [] o.a.s.c.ZkTestServer
Starting server
[junit4] 2> 806830 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[321388BA4FEAE276]) []
o.a.s.c.ZkTestServer start zk server on port:60227
[junit4] 2> 806830 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[321388BA4FEAE276]) []
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
[junit4] 2> 806831 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[321388BA4FEAE276]) []
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
[junit4] 2> 806840 INFO (zkCallback-757-thread-1) []
o.a.s.c.c.ConnectionManager Watcher
org.apache.solr.common.cloud.ConnectionManager@12f087 name:ZooKeeperConnection
Watcher:127.0.0.1:60227 got event WatchedEvent state:SyncConnected type:None
path:null path:null type:None
[junit4] 2> 806840 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[321388BA4FEAE276]) []
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
[junit4] 2> 806841 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[321388BA4FEAE276]) []
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
[junit4] 2> 806841 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[321388BA4FEAE276]) []
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
[junit4] 2> 806869 INFO (jetty-launcher-756-thread-3) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 806870 INFO (jetty-launcher-756-thread-2) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 806871 INFO (jetty-launcher-756-thread-2) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@fdee2{/solr,null,AVAILABLE}
[junit4] 2> 806873 INFO (jetty-launcher-756-thread-3) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@1850d7e{/solr,null,AVAILABLE}
[junit4] 2> 806885 INFO (jetty-launcher-756-thread-1) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 806885 INFO (jetty-launcher-756-thread-4) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 806886 INFO (jetty-launcher-756-thread-1) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@fdca6{/solr,null,AVAILABLE}
[junit4] 2> 806887 INFO (jetty-launcher-756-thread-1) []
o.e.j.s.ServerConnector Started
ServerConnector@a4f06e{HTTP/1.1,[http/1.1]}{127.0.0.1:60237}
[junit4] 2> 806887 INFO (jetty-launcher-756-thread-1) []
o.e.j.s.Server Started @810441ms
[junit4] 2> 806887 INFO (jetty-launcher-756-thread-1) []
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr,
hostPort=60237}
[junit4] 2> 806887 INFO (jetty-launcher-756-thread-1) []
o.a.s.s.SolrDispatchFilter SolrDispatchFilter.init():
sun.misc.Launcher$AppClassLoader@1d16e93
[junit4] 2> 806887 INFO (jetty-launcher-756-thread-1) []
o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory:
'C:\Users\jenkins\workspace\Lucene-Solr-6.1-Windows\solr\build\solr-core\test\J1\temp\solr.security.BasicAuthIntegrationTest_321388BA4FEAE276-001\tempDir-001\node1'
[junit4] 2> 806892 INFO (jetty-launcher-756-thread-1) []
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
[junit4] 2> 806892 INFO (jetty-launcher-756-thread-1) []
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find
system property or JNDI)
[junit4] 2> 806892 INFO (jetty-launcher-756-thread-3) []
o.e.j.s.ServerConnector Started
ServerConnector@130266d{HTTP/1.1,[http/1.1]}{127.0.0.1:60232}
[junit4] 2> 806892 INFO (jetty-launcher-756-thread-3) []
o.e.j.s.Server Started @810446ms
[junit4] 2> 806892 INFO (jetty-launcher-756-thread-3) []
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr,
hostPort=60232}
[junit4] 2> 806891 INFO (jetty-launcher-756-thread-4)
Re: [JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_92) - Build # 5906 - Still Failing!
I'll dig. Mike McCandless http://blog.mikemccandless.com On Sun, Jun 12, 2016 at 8:25 AM, Policeman Jenkins Server < jenk...@thetaphi.de> wrote: > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5906/ > Java: 32bit/jdk1.8.0_92 -server -XX:+UseG1GC > > 2 tests failed. > FAILED: > org.apache.lucene.search.TestControlledRealTimeReopenThread.testControlledRealTimeReopenThread > > Error Message: > > > Stack Trace: > java.lang.AssertionError > at > __randomizedtesting.SeedInfo.seed([E94344495F00D8B7:16AA558AAC03F0BB]:0) > at org.junit.Assert.fail(Assert.java:92) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertFalse(Assert.java:68) > at org.junit.Assert.assertFalse(Assert.java:79) > at > org.apache.lucene.index.ThreadedIndexingAndSearchingTestCase.runTest(ThreadedIndexingAndSearchingTestCase.java:629) > at > org.apache.lucene.search.TestControlledRealTimeReopenThread.testControlledRealTimeReopenThread(TestControlledRealTimeReopenThread.java:68) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) > at > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) > at > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) > at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) > at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) > at > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) > at java.lang.Thread.run(Thread.java:745) > > > FAILED: > junit.framework.TestSuite.org.apache.lucene.search.TestControlledRealTimeReopenThread > > Error Message: >
[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+122) - Build # 880 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/880/
Java: 64bit/jdk-9-ea+122 -XX:-UseCompressedOops -XX:+UseParallelGC
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([ACF216DCA5473E13]: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([ACF216DCA5473E13]:0)
Build Log:
[...truncated 12614 lines...]
[junit4] Suite: org.apache.solr.security.BasicAuthIntegrationTest
[junit4] 2> 829705 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[ACF216DCA5473E13]) []
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
[junit4] 2> 829705 INFO (Thread-2043) [] o.a.s.c.ZkTestServer client
port:0.0.0.0/0.0.0.0:0
[junit4] 2> 829705 INFO (Thread-2043) [] o.a.s.c.ZkTestServer
Starting server
[junit4] 2> 829805 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[ACF216DCA5473E13]) []
o.a.s.c.ZkTestServer start zk server on port:33812
[junit4] 2> 829805 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[ACF216DCA5473E13]) []
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
[junit4] 2> 829805 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[ACF216DCA5473E13]) []
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
[junit4] 2> 829832 INFO (zkCallback-1175-thread-1) []
o.a.s.c.c.ConnectionManager Watcher
org.apache.solr.common.cloud.ConnectionManager@40d22941
name:ZooKeeperConnection Watcher:127.0.0.1:33812 got event WatchedEvent
state:SyncConnected type:None path:null path:null type:None
[junit4] 2> 829832 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[ACF216DCA5473E13]) []
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
[junit4] 2> 829832 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[ACF216DCA5473E13]) []
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
[junit4] 2> 829832 INFO
(TEST-BasicAuthIntegrationTest.testBasics-seed#[ACF216DCA5473E13]) []
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
[junit4] 2> 829861 INFO (jetty-launcher-1174-thread-1) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 829862 INFO (jetty-launcher-1174-thread-2) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 829862 INFO (jetty-launcher-1174-thread-3) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 829862 INFO (jetty-launcher-1174-thread-4) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 829862 INFO (jetty-launcher-1174-thread-5) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 829864 INFO (jetty-launcher-1174-thread-1) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@208105b9{/solr,null,AVAILABLE}
[junit4] 2> 829864 INFO (jetty-launcher-1174-thread-5) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@51eeb4bd{/solr,null,AVAILABLE}
[junit4] 2> 829864 INFO (jetty-launcher-1174-thread-2) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@4594d3ab{/solr,null,AVAILABLE}
[junit4] 2> 829865 INFO (jetty-launcher-1174-thread-3) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@2f1bd5e3{/solr,null,AVAILABLE}
[junit4] 2> 829865 INFO (jetty-launcher-1174-thread-4) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@7b0159ab{/solr,null,AVAILABLE}
[junit4] 2> 829866 INFO (jetty-launcher-1174-thread-5) []
o.e.j.s.ServerConnector Started
ServerConnector@20302a15{HTTP/1.1,[http/1.1]}{127.0.0.1:40275}
[junit4] 2> 829866 INFO (jetty-launcher-1174-thread-4) []
o.e.j.s.ServerConnector Started
ServerConnector@5ae0eaa6{HTTP/1.1,[http/1.1]}{127.0.0.1:37692}
[junit4] 2> 829866 INFO (jetty-launcher-1174-thread-5) []
o.e.j.s.Server Started @831882ms
[junit4] 2> 829866 INFO (jetty-launcher-1174-thread-2) []
o.e.j.s.ServerConnector Started
ServerConnector@53dfb1f{HTTP/1.1,[http/1.1]}{127.0.0.1:33631}
[junit4] 2> 829866 INFO (jetty-launcher-1174-thread-5) []
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr,
hostPort=40275}
[junit4] 2> 829866 INFO (jetty-launcher-1174-thread-1) []
o.e.j.s.ServerConnector Started
ServerConnector@6b933813{HTTP/1.1,[http/1.1]}{127.0.0.1:42556}
[junit4] 2> 829866 INFO (jetty-launcher-1174-thread-2) []
o.e.j.s.Server Started @831883ms
[junit4] 2> 829866 INFO (jetty-launcher-1174-thread-1) []
o.e.j.s.Server Started @831883ms
[junit4] 2> 829866 INFO (jetty-launcher-1174-thread-2) []
[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_92) - Build # 5906 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5906/ Java: 32bit/jdk1.8.0_92 -server -XX:+UseG1GC 2 tests failed. FAILED: org.apache.lucene.search.TestControlledRealTimeReopenThread.testControlledRealTimeReopenThread Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([E94344495F00D8B7:16AA558AAC03F0BB]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at org.apache.lucene.index.ThreadedIndexingAndSearchingTestCase.runTest(ThreadedIndexingAndSearchingTestCase.java:629) at org.apache.lucene.search.TestControlledRealTimeReopenThread.testControlledRealTimeReopenThread(TestControlledRealTimeReopenThread.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.lucene.search.TestControlledRealTimeReopenThread Error Message: 2 threads leaked from SUITE scope at org.apache.lucene.search.TestControlledRealTimeReopenThread: 1) Thread[id=320, name=NRTDeletes Reopen Thread, state=TIMED_WAITING, group=TGRP-TestControlledRealTimeReopenThread] at sun.misc.Unsafe.park(Native Method) at
[jira] [Resolved] (LUCENE-7334) Update ASM to 5.1 (expressions,...)
[ https://issues.apache.org/jira/browse/LUCENE-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-7334. --- Resolution: Fixed Fix Version/s: (was: 6.2) 6.x > Update ASM to 5.1 (expressions,...) > --- > > Key: LUCENE-7334 > URL: https://issues.apache.org/jira/browse/LUCENE-7334 > Project: Lucene - Core > Issue Type: Task > Components: modules/expressions >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 6.x, master (7.0) > > Attachments: LUCENE-7334.patch > > > We should update ASM to version 5.1. The change is easy, no real code changes > needed. -- 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-7334) Update ASM to 5.1 (expressions,...)
[ https://issues.apache.org/jira/browse/LUCENE-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326414#comment-15326414 ] ASF subversion and git services commented on LUCENE-7334: - Commit 4ead0dbcc65b89e53948a228602bbbc1b8401faa in lucene-solr's branch refs/heads/branch_6x from [~thetaphi] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4ead0db ] LUCENE-7334: Update ASM dependency to 5.1 > Update ASM to 5.1 (expressions,...) > --- > > Key: LUCENE-7334 > URL: https://issues.apache.org/jira/browse/LUCENE-7334 > Project: Lucene - Core > Issue Type: Task > Components: modules/expressions >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 6.x, master (7.0) > > Attachments: LUCENE-7334.patch > > > We should update ASM to version 5.1. The change is easy, no real code changes > needed. -- 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-7334) Update ASM to 5.1 (expressions,...)
[ https://issues.apache.org/jira/browse/LUCENE-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326413#comment-15326413 ] ASF subversion and git services commented on LUCENE-7334: - Commit 02c65547e2973dbfdea4b2a2411987d23d66a6b6 in lucene-solr's branch refs/heads/master from [~thetaphi] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=02c6554 ] LUCENE-7334: Update ASM dependency to 5.1 > Update ASM to 5.1 (expressions,...) > --- > > Key: LUCENE-7334 > URL: https://issues.apache.org/jira/browse/LUCENE-7334 > Project: Lucene - Core > Issue Type: Task > Components: modules/expressions >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: master (7.0), 6.2 > > Attachments: LUCENE-7334.patch > > > We should update ASM to version 5.1. The change is easy, no real code changes > needed. -- 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-MAVEN] Lucene-Solr-Maven-6.1 #3: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-6.1/3/ No tests ran. Build Log: [...truncated 28051 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.1/build.xml:756: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.1/build.xml:299: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.1/lucene/build.xml:416: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.1/lucene/common-build.xml:1651: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.1/lucene/common-build.xml:566: Error deploying artifact 'org.apache.lucene:lucene-test-framework:jar': Error deploying artifact: Failed to transfer file: https://repository.apache.org/content/repositories/snapshots/org/apache/lucene/lucene-test-framework/6.1.0-SNAPSHOT/lucene-test-framework-6.1.0-20160612.120643-81-sources.jar.md5. Return code is: 502 Total time: 8 minutes 30 seconds Build step 'Invoke Ant' marked build as failure Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-6.1 - Build # 6 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.1/6/ 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: ObjectTracker found 4 object(s) that were not released!!! [SolrCore, MockDirectoryWrapper, MockDirectoryWrapper, MDCAwareThreadPoolExecutor] Stack Trace: java.lang.AssertionError: ObjectTracker found 4 object(s) that were not released!!! [SolrCore, MockDirectoryWrapper, MockDirectoryWrapper, MDCAwareThreadPoolExecutor] at __randomizedtesting.SeedInfo.seed([9F6CD8FC5A358841]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257) at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=8688, name=searcherExecutor-4181-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=8688, name=searcherExecutor-4181-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([9F6CD8FC5A358841]:0) FAILED:
[jira] [Commented] (LUCENE-7334) Update ASM to 5.1 (expressions,...)
[ https://issues.apache.org/jira/browse/LUCENE-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326358#comment-15326358 ] Robert Muir commented on LUCENE-7334: - I don't think we need to rush it in to a release, but I think its good to stay reasonably up to date and not have ancient jars as dependencies! > Update ASM to 5.1 (expressions,...) > --- > > Key: LUCENE-7334 > URL: https://issues.apache.org/jira/browse/LUCENE-7334 > Project: Lucene - Core > Issue Type: Task > Components: modules/expressions >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: master (7.0), 6.2 > > Attachments: LUCENE-7334.patch > > > We should update ASM to version 5.1. The change is easy, no real code changes > needed. -- 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-2199) DIH JdbcDataSource - Support multiple resultsets
[ https://issues.apache.org/jira/browse/SOLR-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326347#comment-15326347 ] Kristine Jetzke commented on SOLR-2199: --- [~mkhludnev] I attached a new patch that additionally handles some cases that were missing in the original patch (e.g. result set is initially returned, followed by an update count, followed by another result set or update count initially returned followed by a result set). I also added unit tests. > DIH JdbcDataSource - Support multiple resultsets > > > Key: SOLR-2199 > URL: https://issues.apache.org/jira/browse/SOLR-2199 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4.1 >Reporter: Mark Waddle >Assignee: Mikhail Khludnev > Attachments: SOLR-2199.patch, SOLR-2199.patch > > > Database servers can return multiple result sets from a single statement. > This can be beneficial for indexing because it reduces the number of > connections and statements being executed against a database, therefore > reducing overhead. The JDBC Statement object supports reading multiple > ResultSets. Support should be added to the JdbcDataSource to take advantage > of 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] [Updated] (SOLR-2199) DIH JdbcDataSource - Support multiple resultsets
[ https://issues.apache.org/jira/browse/SOLR-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristine Jetzke updated SOLR-2199: -- Attachment: SOLR-2199.patch > DIH JdbcDataSource - Support multiple resultsets > > > Key: SOLR-2199 > URL: https://issues.apache.org/jira/browse/SOLR-2199 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4.1 >Reporter: Mark Waddle >Assignee: Mikhail Khludnev > Attachments: SOLR-2199.patch, SOLR-2199.patch > > > Database servers can return multiple result sets from a single statement. > This can be beneficial for indexing because it reduces the number of > connections and statements being executed against a database, therefore > reducing overhead. The JDBC Statement object supports reading multiple > ResultSets. Support should be added to the JdbcDataSource to take advantage > of 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] [Comment Edited] (LUCENE-7334) Update ASM to 5.1 (expressions,...)
[ https://issues.apache.org/jira/browse/LUCENE-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326325#comment-15326325 ] Uwe Schindler edited comment on LUCENE-7334 at 6/12/16 9:10 AM: [~rcmuir]: Should I push this also to 6.1 ? I know that ES is now also using ASM 5.1, but you are running plugins in separate classloaders, so it should not be an issue. In addition replacing the JARs works OOB. So any suggestion? I will commit this soon. was (Author: thetaphi): [~rcmuir]: Should I push this also to 6.1 ? I know that ES is now also using ASM 4.1, but you are running plugins in separate classloaders, so it should not be an issue. In addition replacing the JARs works OOB. So any suggestion? I will commit this soon. > Update ASM to 5.1 (expressions,...) > --- > > Key: LUCENE-7334 > URL: https://issues.apache.org/jira/browse/LUCENE-7334 > Project: Lucene - Core > Issue Type: Task > Components: modules/expressions >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: master (7.0), 6.2 > > Attachments: LUCENE-7334.patch > > > We should update ASM to version 5.1. The change is easy, no real code changes > needed. -- 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-7334) Update ASM to 5.1 (expressions,...)
[ https://issues.apache.org/jira/browse/LUCENE-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326325#comment-15326325 ] Uwe Schindler commented on LUCENE-7334: --- [~rcmuir]: Should I push this also to 6.1. I know that ES is now also using ASM 4.1, but you are running plugins in separate classloaders, so it should not be an issue. In addition replacing the JARs works OOB. So any suggestion? I will commit this soon. > Update ASM to 5.1 (expressions,...) > --- > > Key: LUCENE-7334 > URL: https://issues.apache.org/jira/browse/LUCENE-7334 > Project: Lucene - Core > Issue Type: Task > Components: modules/expressions >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: master (7.0), 6.2 > > Attachments: LUCENE-7334.patch > > > We should update ASM to version 5.1. The change is easy, no real code changes > needed. -- 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-7334) Update ASM to 5.1 (expressions,...)
[ https://issues.apache.org/jira/browse/LUCENE-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326325#comment-15326325 ] Uwe Schindler edited comment on LUCENE-7334 at 6/12/16 9:10 AM: [~rcmuir]: Should I push this also to 6.1 ? I know that ES is now also using ASM 4.1, but you are running plugins in separate classloaders, so it should not be an issue. In addition replacing the JARs works OOB. So any suggestion? I will commit this soon. was (Author: thetaphi): [~rcmuir]: Should I push this also to 6.1. I know that ES is now also using ASM 4.1, but you are running plugins in separate classloaders, so it should not be an issue. In addition replacing the JARs works OOB. So any suggestion? I will commit this soon. > Update ASM to 5.1 (expressions,...) > --- > > Key: LUCENE-7334 > URL: https://issues.apache.org/jira/browse/LUCENE-7334 > Project: Lucene - Core > Issue Type: Task > Components: modules/expressions >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: master (7.0), 6.2 > > Attachments: LUCENE-7334.patch > > > We should update ASM to version 5.1. The change is easy, no real code changes > needed. -- 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-6.x-MacOSX (64bit/jdk1.8.0) - Build # 202 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/202/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.TestCloudBackupRestore.test Error Message: Error from server at http://127.0.0.1:57844/solr: Backup directory already exists: /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-core/test/J0/temp/solr.cloud.TestCloudBackupRestore_578FC150354AB606-001/tempDir-002/mytestbackup Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:57844/solr: Backup directory already exists: /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-core/test/J0/temp/solr.cloud.TestCloudBackupRestore_578FC150354AB606-001/tempDir-002/mytestbackup at __randomizedtesting.SeedInfo.seed([578FC150354AB606:DFDBFE8A9BB6DBFE]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:590) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:404) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:357) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1228) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166) at org.apache.solr.cloud.TestCloudBackupRestore.testBackupAndRestore(TestCloudBackupRestore.java:153) at org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:110) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_92) - Build # 16973 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16973/ Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseParallelGC 4 tests failed. FAILED: org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousAddsViaCloudClient Error Message: Error from server at https://127.0.0.1:40633/solr/test_col: Async exception during distributed update: Connect to 127.0.0.1:39833 [/127.0.0.1] failed: Read timed out Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:40633/solr/test_col: Async exception during distributed update: Connect to 127.0.0.1:39833 [/127.0.0.1] failed: Read timed out at __randomizedtesting.SeedInfo.seed([1D7A2691847F5CD4:20CBAAE5BB96650D]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:366) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1228) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149) at org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:895) at org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:858) at org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:873) at org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousAdds(TestTolerantUpdateProcessorCloud.java:511) at org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousAddsViaCloudClient(TestTolerantUpdateProcessorCloud.java:396) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at
[JENKINS-MAVEN] Lucene-Solr-Maven-master #1780: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-master/1780/ No tests ran. Build Log: [...truncated 27943 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:756: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:299: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/build.xml:414: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:566: Error deploying artifact 'org.apache.lucene:lucene-solr-grandparent:pom': Error retrieving previous build number for artifact 'org.apache.lucene:lucene-solr-grandparent:pom': repository metadata for: 'snapshot org.apache.lucene:lucene-solr-grandparent:7.0.0-SNAPSHOT' could not be retrieved from repository: apache.snapshots.https due to an error: Error transferring file: Server returned HTTP response code: 502 for URL: https://repository.apache.org/content/repositories/snapshots/org/apache/lucene/lucene-solr-grandparent/7.0.0-SNAPSHOT/maven-metadata.xml Total time: 7 minutes 36 seconds Build step 'Invoke Ant' marked build as failure Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-6.1 - Build # 3 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.1/3/ 2 tests failed. FAILED: org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test Error Message: KeeperErrorCode = Session expired for /clusterstate.json Stack Trace: org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = Session expired for /clusterstate.json at org.apache.zookeeper.KeeperException.create(KeeperException.java:127) at org.apache.zookeeper.KeeperException.create(KeeperException.java:51) at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155) at org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:348) at org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:345) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60) at org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:345) at org.apache.solr.common.cloud.ZkStateReader.refreshLegacyClusterState(ZkStateReader.java:506) at org.apache.solr.common.cloud.ZkStateReader.forceUpdateCollection(ZkStateReader.java:296) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testNoCollectionSpecified(CollectionsAPIDistributedZkTest.java:582) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Resolved] (SOLR-8744) Overseer operations need more fine grained mutual exclusion
[
https://issues.apache.org/jira/browse/SOLR-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-8744.
--
Resolution: Fixed
> Overseer operations need more fine grained mutual exclusion
> ---
>
> Key: SOLR-8744
> URL: https://issues.apache.org/jira/browse/SOLR-8744
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Noble Paul
>Priority: Blocker
> Labels: sharding, solrcloud
> Fix For: 6.1
>
> Attachments: SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch,
> SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch,
> SOLR-8744.patch, SOLR-8744.patch, SmileyLockTree.java, SmileyLockTree.java
>
>
> SplitShard creates a mutex over the whole collection, but, in practice, this
> is a big scaling problem. Multiple split shard operations could happen at
> the time time, as long as different shards are being split. In practice,
> those shards often reside on different machines, so there's no I/O bottleneck
> in those cases, just the mutex in Overseer forcing the operations to be done
> serially.
> Given that a single split can take many minutes on a large collection, this
> is a bottleneck at scale.
> Here is the proposed new design
> There are various Collection operations performed at Overseer. They may need
> exclusive access at various levels. Each operation must define the Access
> level at which the access is required. Access level is an enum.
> CLUSTER(0)
> COLLECTION(1)
> SHARD(2)
> REPLICA(3)
> The Overseer node maintains a tree of these locks. The lock tree would look
> as follows. The tree can be created lazily as and when tasks come up.
> {code}
> Legend:
> C1, C2 -> Collections
> S1, S2 -> Shards
> R1,R2,R3,R4 -> Replicas
> Cluster
> / \
>/ \
> C1 C2
> / \ / \
> / \ / \
>S1 S2 S1 S2
> R1, R2 R3.R4 R1,R2 R3,R4
> {code}
> When the overseer receives a message, it tries to acquire the appropriate
> lock from the tree. For example, if an operation needs a lock at a Collection
> level and it needs to operate on Collection C1, the node C1 and all child
> nodes of C1 must be free.
> h2.Lock acquiring logic
> Each operation would start from the root of the tree (Level 0 -> Cluster) and
> start moving down depending upon the operation. After it reaches the right
> node, it checks if all the children are free from a lock. If it fails to
> acquire a lock, it remains in the work queue. A scheduler thread waits for
> notification from the current set of tasks . Every task would do a
> {{notify()}} on the monitor of the scheduler thread. The thread would start
> from the head of the queue and check all tasks to see if that task is able to
> acquire the right lock. If yes, it is executed, if not, the task is left in
> the work queue.
> When a new task arrives in the work queue, the schedulerthread wakes and just
> try to schedule that task.
--
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-8744) Overseer operations need more fine grained mutual exclusion
[
https://issues.apache.org/jira/browse/SOLR-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326290#comment-15326290
]
ASF subversion and git services commented on SOLR-8744:
---
Commit 4726c5b2d2efa9ba160b608d46a977d0a6b83f94 in lucene-solr's branch
refs/heads/branch_6_1 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4726c5b ]
SOLR-8744: Minimize the impact on ZK when there are a lot of blocked tasks
> Overseer operations need more fine grained mutual exclusion
> ---
>
> Key: SOLR-8744
> URL: https://issues.apache.org/jira/browse/SOLR-8744
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Noble Paul
>Priority: Blocker
> Labels: sharding, solrcloud
> Fix For: 6.1
>
> Attachments: SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch,
> SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch,
> SOLR-8744.patch, SOLR-8744.patch, SmileyLockTree.java, SmileyLockTree.java
>
>
> SplitShard creates a mutex over the whole collection, but, in practice, this
> is a big scaling problem. Multiple split shard operations could happen at
> the time time, as long as different shards are being split. In practice,
> those shards often reside on different machines, so there's no I/O bottleneck
> in those cases, just the mutex in Overseer forcing the operations to be done
> serially.
> Given that a single split can take many minutes on a large collection, this
> is a bottleneck at scale.
> Here is the proposed new design
> There are various Collection operations performed at Overseer. They may need
> exclusive access at various levels. Each operation must define the Access
> level at which the access is required. Access level is an enum.
> CLUSTER(0)
> COLLECTION(1)
> SHARD(2)
> REPLICA(3)
> The Overseer node maintains a tree of these locks. The lock tree would look
> as follows. The tree can be created lazily as and when tasks come up.
> {code}
> Legend:
> C1, C2 -> Collections
> S1, S2 -> Shards
> R1,R2,R3,R4 -> Replicas
> Cluster
> / \
>/ \
> C1 C2
> / \ / \
> / \ / \
>S1 S2 S1 S2
> R1, R2 R3.R4 R1,R2 R3,R4
> {code}
> When the overseer receives a message, it tries to acquire the appropriate
> lock from the tree. For example, if an operation needs a lock at a Collection
> level and it needs to operate on Collection C1, the node C1 and all child
> nodes of C1 must be free.
> h2.Lock acquiring logic
> Each operation would start from the root of the tree (Level 0 -> Cluster) and
> start moving down depending upon the operation. After it reaches the right
> node, it checks if all the children are free from a lock. If it fails to
> acquire a lock, it remains in the work queue. A scheduler thread waits for
> notification from the current set of tasks . Every task would do a
> {{notify()}} on the monitor of the scheduler thread. The thread would start
> from the head of the queue and check all tasks to see if that task is able to
> acquire the right lock. If yes, it is executed, if not, the task is left in
> the work queue.
> When a new task arrives in the work queue, the schedulerthread wakes and just
> try to schedule that task.
--
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-8744) Overseer operations need more fine grained mutual exclusion
[
https://issues.apache.org/jira/browse/SOLR-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326247#comment-15326247
]
ASF subversion and git services commented on SOLR-8744:
---
Commit ff6475c3a7229a27f7e97057fbbfadd2600032dd in lucene-solr's branch
refs/heads/branch_6x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ff6475c ]
SOLR-8744: Minimize the impact on ZK when there are a lot of blocked tasks
> Overseer operations need more fine grained mutual exclusion
> ---
>
> Key: SOLR-8744
> URL: https://issues.apache.org/jira/browse/SOLR-8744
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Noble Paul
>Priority: Blocker
> Labels: sharding, solrcloud
> Fix For: 6.1
>
> Attachments: SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch,
> SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch,
> SOLR-8744.patch, SOLR-8744.patch, SmileyLockTree.java, SmileyLockTree.java
>
>
> SplitShard creates a mutex over the whole collection, but, in practice, this
> is a big scaling problem. Multiple split shard operations could happen at
> the time time, as long as different shards are being split. In practice,
> those shards often reside on different machines, so there's no I/O bottleneck
> in those cases, just the mutex in Overseer forcing the operations to be done
> serially.
> Given that a single split can take many minutes on a large collection, this
> is a bottleneck at scale.
> Here is the proposed new design
> There are various Collection operations performed at Overseer. They may need
> exclusive access at various levels. Each operation must define the Access
> level at which the access is required. Access level is an enum.
> CLUSTER(0)
> COLLECTION(1)
> SHARD(2)
> REPLICA(3)
> The Overseer node maintains a tree of these locks. The lock tree would look
> as follows. The tree can be created lazily as and when tasks come up.
> {code}
> Legend:
> C1, C2 -> Collections
> S1, S2 -> Shards
> R1,R2,R3,R4 -> Replicas
> Cluster
> / \
>/ \
> C1 C2
> / \ / \
> / \ / \
>S1 S2 S1 S2
> R1, R2 R3.R4 R1,R2 R3,R4
> {code}
> When the overseer receives a message, it tries to acquire the appropriate
> lock from the tree. For example, if an operation needs a lock at a Collection
> level and it needs to operate on Collection C1, the node C1 and all child
> nodes of C1 must be free.
> h2.Lock acquiring logic
> Each operation would start from the root of the tree (Level 0 -> Cluster) and
> start moving down depending upon the operation. After it reaches the right
> node, it checks if all the children are free from a lock. If it fails to
> acquire a lock, it remains in the work queue. A scheduler thread waits for
> notification from the current set of tasks . Every task would do a
> {{notify()}} on the monitor of the scheduler thread. The thread would start
> from the head of the queue and check all tasks to see if that task is able to
> acquire the right lock. If yes, it is executed, if not, the task is left in
> the work queue.
> When a new task arrives in the work queue, the schedulerthread wakes and just
> try to schedule that task.
--
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-8744) Overseer operations need more fine grained mutual exclusion
[
https://issues.apache.org/jira/browse/SOLR-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326246#comment-15326246
]
ASF subversion and git services commented on SOLR-8744:
---
Commit 232b44e283dfd01f9ec01b4e68b09b3755a1b17a in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=232b44e ]
SOLR-8744: Minimize the impact on ZK when there are a lot of blocked tasks
> Overseer operations need more fine grained mutual exclusion
> ---
>
> Key: SOLR-8744
> URL: https://issues.apache.org/jira/browse/SOLR-8744
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Noble Paul
>Priority: Blocker
> Labels: sharding, solrcloud
> Fix For: 6.1
>
> Attachments: SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch,
> SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch,
> SOLR-8744.patch, SOLR-8744.patch, SmileyLockTree.java, SmileyLockTree.java
>
>
> SplitShard creates a mutex over the whole collection, but, in practice, this
> is a big scaling problem. Multiple split shard operations could happen at
> the time time, as long as different shards are being split. In practice,
> those shards often reside on different machines, so there's no I/O bottleneck
> in those cases, just the mutex in Overseer forcing the operations to be done
> serially.
> Given that a single split can take many minutes on a large collection, this
> is a bottleneck at scale.
> Here is the proposed new design
> There are various Collection operations performed at Overseer. They may need
> exclusive access at various levels. Each operation must define the Access
> level at which the access is required. Access level is an enum.
> CLUSTER(0)
> COLLECTION(1)
> SHARD(2)
> REPLICA(3)
> The Overseer node maintains a tree of these locks. The lock tree would look
> as follows. The tree can be created lazily as and when tasks come up.
> {code}
> Legend:
> C1, C2 -> Collections
> S1, S2 -> Shards
> R1,R2,R3,R4 -> Replicas
> Cluster
> / \
>/ \
> C1 C2
> / \ / \
> / \ / \
>S1 S2 S1 S2
> R1, R2 R3.R4 R1,R2 R3,R4
> {code}
> When the overseer receives a message, it tries to acquire the appropriate
> lock from the tree. For example, if an operation needs a lock at a Collection
> level and it needs to operate on Collection C1, the node C1 and all child
> nodes of C1 must be free.
> h2.Lock acquiring logic
> Each operation would start from the root of the tree (Level 0 -> Cluster) and
> start moving down depending upon the operation. After it reaches the right
> node, it checks if all the children are free from a lock. If it fails to
> acquire a lock, it remains in the work queue. A scheduler thread waits for
> notification from the current set of tasks . Every task would do a
> {{notify()}} on the monitor of the scheduler thread. The thread would start
> from the head of the queue and check all tasks to see if that task is able to
> acquire the right lock. If yes, it is executed, if not, the task is left in
> the work queue.
> When a new task arrives in the work queue, the schedulerthread wakes and just
> try to schedule that task.
--
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
