[jira] [Commented] (LUCENE-5189) Numeric DocValues Updates
[ https://issues.apache.org/jira/browse/LUCENE-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793579#comment-13793579 ] Shai Erera commented on LUCENE-5189: Thanks for the comments Mike, I fixed the code. bq. That's a great catch on forceMerge carrying the wrapped IOExc forward. Why is jenkins not hitting this already...? I think because liveDocs aren't written during forceMerge, i.e. they are carried in RAM? Numeric DocValues Updates - Key: LUCENE-5189 URL: https://issues.apache.org/jira/browse/LUCENE-5189 Project: Lucene - Core Issue Type: New Feature Components: core/index Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-5189-4x.patch, LUCENE-5189-no-lost-updates.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189_process_events.patch, LUCENE-5189_process_events.patch, LUCENE-5189-updates-order.patch, LUCENE-5189-updates-order.patch In LUCENE-4258 we started to work on incremental field updates, however the amount of changes are immense and hard to follow/consume. The reason is that we targeted postings, stored fields, DV etc., all from the get go. I'd like to start afresh here, with numeric-dv-field updates only. There are a couple of reasons to that: * NumericDV fields should be easier to update, if e.g. we write all the values of all the documents in a segment for the updated field (similar to how livedocs work, and previously norms). * It's a fairly contained issue, attempting to handle just one data type to update, yet requires many changes to core code which will also be useful for updating other data types. * It has value in and on itself, and we don't need to allow updating all the data types in Lucene at once ... we can do that gradually. I have some working patch already which I'll upload next, explaining the changes. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5189) Numeric DocValues Updates
[ https://issues.apache.org/jira/browse/LUCENE-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793580#comment-13793580 ] ASF subversion and git services commented on LUCENE-5189: - Commit 1531620 from [~shaie] in branch 'dev/trunk' [ https://svn.apache.org/r1531620 ] LUCENE-5189: add field updates to TestIndexWriterDelete.testNoLostDeletesOrUpdatesOnIOException Numeric DocValues Updates - Key: LUCENE-5189 URL: https://issues.apache.org/jira/browse/LUCENE-5189 Project: Lucene - Core Issue Type: New Feature Components: core/index Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-5189-4x.patch, LUCENE-5189-no-lost-updates.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189_process_events.patch, LUCENE-5189_process_events.patch, LUCENE-5189-updates-order.patch, LUCENE-5189-updates-order.patch In LUCENE-4258 we started to work on incremental field updates, however the amount of changes are immense and hard to follow/consume. The reason is that we targeted postings, stored fields, DV etc., all from the get go. I'd like to start afresh here, with numeric-dv-field updates only. There are a couple of reasons to that: * NumericDV fields should be easier to update, if e.g. we write all the values of all the documents in a segment for the updated field (similar to how livedocs work, and previously norms). * It's a fairly contained issue, attempting to handle just one data type to update, yet requires many changes to core code which will also be useful for updating other data types. * It has value in and on itself, and we don't need to allow updating all the data types in Lucene at once ... we can do that gradually. I have some working patch already which I'll upload next, explaining the changes. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5341) Output version number in logs
Shawn Heisey created SOLR-5341: -- Summary: Output version number in logs Key: SOLR-5341 URL: https://issues.apache.org/jira/browse/SOLR-5341 Project: Solr Issue Type: Improvement Affects Versions: 4.5 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.6, 5.0 It would be exceptionally useful from a tech support perspective if the version number were placed in the log during startup. I'm inclined to make this a WARN log, but if the consensus is to have it at INFO, then I can go that direction. It might also be useful to have any shutdown hooks in Solr log the version as well. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!
Or just keep the failures forever if there's such an option? (and discard successful builds after a given time window)? Mike -- what did you mean by Maybe we can get the master seed included in a single test failure snippet?? Dawid On Sun, Oct 13, 2013 at 1:56 AM, Robert Muir rcm...@gmail.com wrote: Or just configure flonkings to hold the logs longer. I know the defaults are bad for this: but you can change it to keep them for e.g. 3 days or something so that the disk space usage is constant. On Sat, Oct 12, 2013 at 6:50 PM, Michael McCandless luc...@mikemccandless.com wrote: Sigh, I didn't try the master seed, and no, I have no browser window open. Maybe we can get the master seed included in a single test failure snippet? Mike McCandless http://blog.mikemccandless.com On Sat, Oct 12, 2013 at 5:28 PM, Robert Muir rcm...@gmail.com wrote: Just the seed? or the master seed. if its a jvm bug we need the latter. flonkings already discarded the console log so we lost that, unless you still have it open in a browser or something? On Sat, Oct 12, 2013 at 4:39 PM, Michael McCandless luc...@mikemccandless.com wrote: Can anyone reproduce this failure? I tried beasting with 1.7.0_05 but no fails ... Mike McCandless http://blog.mikemccandless.com On Sat, Oct 12, 2013 at 9:11 AM, buil...@flonkings.com wrote: Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63029/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting Error Message: Stack Trace: java.lang.NullPointerException at org.apache.lucene.index.SnapshotDeletionPolicy.release(SnapshotDeletionPolicy.java:99) at org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting(TestSnapshotDeletionPolicy.java:313) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at
Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!
keeping around 4 days of builds now at max 1000 builds simon On Sun, Oct 13, 2013 at 1:56 AM, Robert Muir rcm...@gmail.com wrote: Or just configure flonkings to hold the logs longer. I know the defaults are bad for this: but you can change it to keep them for e.g. 3 days or something so that the disk space usage is constant. On Sat, Oct 12, 2013 at 6:50 PM, Michael McCandless luc...@mikemccandless.com wrote: Sigh, I didn't try the master seed, and no, I have no browser window open. Maybe we can get the master seed included in a single test failure snippet? Mike McCandless http://blog.mikemccandless.com On Sat, Oct 12, 2013 at 5:28 PM, Robert Muir rcm...@gmail.com wrote: Just the seed? or the master seed. if its a jvm bug we need the latter. flonkings already discarded the console log so we lost that, unless you still have it open in a browser or something? On Sat, Oct 12, 2013 at 4:39 PM, Michael McCandless luc...@mikemccandless.com wrote: Can anyone reproduce this failure? I tried beasting with 1.7.0_05 but no fails ... Mike McCandless http://blog.mikemccandless.com On Sat, Oct 12, 2013 at 9:11 AM, buil...@flonkings.com wrote: Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63029/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting Error Message: Stack Trace: java.lang.NullPointerException at org.apache.lucene.index.SnapshotDeletionPolicy.release(SnapshotDeletionPolicy.java:99) at org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting(TestSnapshotDeletionPolicy.java:313) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Updated] (SOLR-5338) Split shards by a route key
[
https://issues.apache.org/jira/browse/SOLR-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-5338:
Attachment: SOLR-5338.patch
Fixed bug a in the test related to counting documents with a particular route
key.
Split shards by a route key
---
Key: SOLR-5338
URL: https://issues.apache.org/jira/browse/SOLR-5338
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Fix For: 4.6, 5.0
Attachments: SOLR-5338.patch, SOLR-5338.patch
Provide a way to split a shard using a route key such that all documents of
the specified route key end up in a single dedicated sub-shard.
Example:
Assume that collection1, shard1 has hash range [0, 20]. Also that route key
'A!' has hash range [12,15]. Then invoking:
{code}
/admin/collections?action=SPLITcollection=collection1split.key=A!
{code}
should produce three sub-shards with hash range [0,11], [12,15] and [16,20].
Specifying the source shard is not required here because the route key is
enough to figure it out. Route keys spanning more than one shards will not be
supported.
Note that the sub-shard with the hash range of the route key may also contain
documents for other route keys whose hashes collide.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5342) In some places, when a caught exception is re-thrown, the original exception is not included
Shawn Heisey created SOLR-5342: -- Summary: In some places, when a caught exception is re-thrown, the original exception is not included Key: SOLR-5342 URL: https://issues.apache.org/jira/browse/SOLR-5342 Project: Solr Issue Type: Improvement Affects Versions: 4.5 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.5.1, 4.6, 5.0 ShardHandlerFactory#newInstance catches exceptions and rethrows them. It was including the message from the caught exception, but not including the actual exception. This made it difficult to figure out the root cause for an SSL initialization error. While fixing this, I discovered other places that are missing this as well. Some of them I elected not to fix, either because it's catching IOException (which normally provides good messages), or because it was in a location that might get called frequently, which would greatly increase logging output. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5342) In some places, when a caught exception is re-thrown, the original exception is not included
[ https://issues.apache.org/jira/browse/SOLR-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-5342: --- Attachment: SOLR-5342.patch Patch fixing a few instances of the problem. The CHANGES entry is in 4.5.1, but can be moved if this won't be backported. In some places, when a caught exception is re-thrown, the original exception is not included Key: SOLR-5342 URL: https://issues.apache.org/jira/browse/SOLR-5342 Project: Solr Issue Type: Improvement Affects Versions: 4.5 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.5.1, 4.6, 5.0 Attachments: SOLR-5342.patch ShardHandlerFactory#newInstance catches exceptions and rethrows them. It was including the message from the caught exception, but not including the actual exception. This made it difficult to figure out the root cause for an SSL initialization error. While fixing this, I discovered other places that are missing this as well. Some of them I elected not to fix, either because it's catching IOException (which normally provides good messages), or because it was in a location that might get called frequently, which would greatly increase logging output. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5342) In some places, when a caught exception is re-thrown, the original exception is not included
[ https://issues.apache.org/jira/browse/SOLR-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793592#comment-13793592 ] Shawn Heisey commented on SOLR-5342: I feel that the change to ShardHandlerFactory is necessary, but if anyone has good reason to not make the change in other classes, please let me know. A similar issue might need to be filed in LUCENE, because I did find some similar stuff there. If nobody else does so, I will go ahead and do it when it's not 2 in the morning. :) In some places, when a caught exception is re-thrown, the original exception is not included Key: SOLR-5342 URL: https://issues.apache.org/jira/browse/SOLR-5342 Project: Solr Issue Type: Improvement Affects Versions: 4.5 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.5.1, 4.6, 5.0 Attachments: SOLR-5342.patch ShardHandlerFactory#newInstance catches exceptions and rethrows them. It was including the message from the caught exception, but not including the actual exception. This made it difficult to figure out the root cause for an SSL initialization error. While fixing this, I discovered other places that are missing this as well. Some of them I elected not to fix, either because it's catching IOException (which normally provides good messages), or because it was in a location that might get called frequently, which would greatly increase logging output. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5277) Modify FixedBitSet copy constructor to take numBits to allow grow/shrink the new bitset
[ https://issues.apache.org/jira/browse/LUCENE-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793594#comment-13793594 ] ASF subversion and git services commented on LUCENE-5277: - Commit 1531627 from [~shaie] in branch 'dev/trunk' [ https://svn.apache.org/r1531627 ] LUCENE-5277: Modify FixedBitSet copy constructor to take numBits to allow grow/shrink the new bitset Modify FixedBitSet copy constructor to take numBits to allow grow/shrink the new bitset --- Key: LUCENE-5277 URL: https://issues.apache.org/jira/browse/LUCENE-5277 Project: Lucene - Core Issue Type: Improvement Components: core/index Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-5277.patch FixedBitSet copy constructor is redundant the way it is now -- one can call FBS.clone() to achieve that (and indeed, no code in Lucene calls this ctor). I think it will be useful to add a numBits parameter to that method to allow growing/shrinking the new bitset, while copying all relevant bits from the passed one. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793595#comment-13793595 ] Elran Dvir commented on SOLR-5084: -- Hi all, Did anyone have a chance to examine the latest patch? Is everthing fine? Thanks. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5277) Modify FixedBitSet copy constructor to take numBits to allow grow/shrink the new bitset
[ https://issues.apache.org/jira/browse/LUCENE-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793596#comment-13793596 ] ASF subversion and git services commented on LUCENE-5277: - Commit 1531630 from [~shaie] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1531630 ] LUCENE-5277: Modify FixedBitSet copy constructor to take numBits to allow grow/shrink the new bitset Modify FixedBitSet copy constructor to take numBits to allow grow/shrink the new bitset --- Key: LUCENE-5277 URL: https://issues.apache.org/jira/browse/LUCENE-5277 Project: Lucene - Core Issue Type: Improvement Components: core/index Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-5277.patch FixedBitSet copy constructor is redundant the way it is now -- one can call FBS.clone() to achieve that (and indeed, no code in Lucene calls this ctor). I think it will be useful to add a numBits parameter to that method to allow growing/shrinking the new bitset, while copying all relevant bits from the passed one. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5277) Modify FixedBitSet copy constructor to take numBits to allow grow/shrink the new bitset
[ https://issues.apache.org/jira/browse/LUCENE-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-5277. Resolution: Fixed Fix Version/s: 5.0 4.6 Lucene Fields: New,Patch Available (was: New) Committed to trunk and 4x. Modify FixedBitSet copy constructor to take numBits to allow grow/shrink the new bitset --- Key: LUCENE-5277 URL: https://issues.apache.org/jira/browse/LUCENE-5277 Project: Lucene - Core Issue Type: Improvement Components: core/index Reporter: Shai Erera Assignee: Shai Erera Fix For: 4.6, 5.0 Attachments: LUCENE-5277.patch FixedBitSet copy constructor is redundant the way it is now -- one can call FBS.clone() to achieve that (and indeed, no code in Lucene calls this ctor). I think it will be useful to add a numBits parameter to that method to allow growing/shrinking the new bitset, while copying all relevant bits from the passed one. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!
On Sun, Oct 13, 2013 at 2:43 AM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: Or just keep the failures forever if there's such an option? (and discard successful builds after a given time window)? That would be really nice! Mike -- what did you mean by Maybe we can get the master seed included in a single test failure snippet?? Oh, I was talking about capturing and reporting, via the Jenkins failure email (that massive regexp!) the master seed that randomizedtesting prints out at the start of ant test. But, it looks like this seed is in fact the one passed to each test ... so the seed in the reproduce with line is already the master seed. So I can try to reproduce with that (and exact same number of JVMS as flonkings). So, nothing to do here :) I was just confused. Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5260) Make older Suggesters more accepting of TermFreqPayloadIterator
[ https://issues.apache.org/jira/browse/LUCENE-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793607#comment-13793607 ] ASF subversion and git services commented on LUCENE-5260: - Commit 1531664 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1531664 ] LUCENE-5260: cutover all suggesters to TermFreqPayloadIterator Make older Suggesters more accepting of TermFreqPayloadIterator --- Key: LUCENE-5260 URL: https://issues.apache.org/jira/browse/LUCENE-5260 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Areek Zillur Attachments: LUCENE-5260.patch, LUCENE-5260.patch As discussed in https://issues.apache.org/jira/browse/LUCENE-5251, it would be nice to make the older suggesters accepting of TermFreqPayloadIterator and throw an exception if payload is found (if it cannot be used). This will also allow us to nuke most of the other interfaces for BytesRefIterator. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5260) Make older Suggesters more accepting of TermFreqPayloadIterator
[ https://issues.apache.org/jira/browse/LUCENE-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793609#comment-13793609 ] ASF subversion and git services commented on LUCENE-5260: - Commit 1531666 from [~mikemccand] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1531666 ] LUCENE-5260: cutover all suggesters to TermFreqPayloadIterator Make older Suggesters more accepting of TermFreqPayloadIterator --- Key: LUCENE-5260 URL: https://issues.apache.org/jira/browse/LUCENE-5260 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Areek Zillur Fix For: 4.6, 5.0 Attachments: LUCENE-5260.patch, LUCENE-5260.patch As discussed in https://issues.apache.org/jira/browse/LUCENE-5251, it would be nice to make the older suggesters accepting of TermFreqPayloadIterator and throw an exception if payload is found (if it cannot be used). This will also allow us to nuke most of the other interfaces for BytesRefIterator. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5260) Make older Suggesters more accepting of TermFreqPayloadIterator
[ https://issues.apache.org/jira/browse/LUCENE-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-5260. Resolution: Fixed Fix Version/s: 5.0 4.6 Thanks Areek! Make older Suggesters more accepting of TermFreqPayloadIterator --- Key: LUCENE-5260 URL: https://issues.apache.org/jira/browse/LUCENE-5260 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Areek Zillur Fix For: 4.6, 5.0 Attachments: LUCENE-5260.patch, LUCENE-5260.patch As discussed in https://issues.apache.org/jira/browse/LUCENE-5251, it would be nice to make the older suggesters accepting of TermFreqPayloadIterator and throw an exception if payload is found (if it cannot be used). This will also allow us to nuke most of the other interfaces for BytesRefIterator. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.6.0_45) - Build # 7771 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/7771/ Java: 64bit/jdk1.6.0_45 -XX:+UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 4160 lines...] [javac] Compiling 48 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/suggest/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/suggest/src/java/org/apache/lucene/search/suggest/SortedTermFreqPayloadIteratorWrapper.java:146: cannot find symbol [javac] symbol : method compare(long,long) [javac] location: class java.lang.Long [javac] return Long.compare(leftCost, rightCost); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 1 error BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:428: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:408: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:39: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build.xml:557: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1912: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/module-build.xml:57: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:477: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1650: Compile failed; see the compiler error output for details. Total time: 9 minutes 27 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 64bit/jdk1.6.0_45 -XX:+UseCompressedOops -XX:+UseParallelGC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793613#comment-13793613 ] Erick Erickson commented on SOLR-5084: -- Elran: I haven't forgotten, I've just been swamped. I'll try to get to it Real Soon Now, but I'm traveling for the next 10 days. Anyone who wants to go ahead and grab and commit this please feel free! Erick new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.6.0_45) - Build # 3278 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/3278/ Java: 32bit/jdk1.6.0_45 -client -XX:+UseParallelGC All tests passed Build Log: [...truncated 4088 lines...] [javac] Compiling 48 source files to C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\suggest\classes\java [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\suggest\src\java\org\apache\lucene\search\suggest\SortedTermFreqPayloadIteratorWrapper.java:146: cannot find symbol [javac] symbol : method compare(long,long) [javac] location: class java.lang.Long [javac] return Long.compare(leftCost, rightCost); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 1 error BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:428: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:408: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:39: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build.xml:557: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:1912: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\module-build.xml:57: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:477: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:1650: Compile failed; see the compiler error output for details. Total time: 13 minutes 6 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 32bit/jdk1.6.0_45 -client -XX:+UseParallelGC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.6.0_45) - Build # 7771 - Failure!
Doh! I committed a fix ... Mike McCandless http://blog.mikemccandless.com On Sun, Oct 13, 2013 at 6:49 AM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/7771/ Java: 64bit/jdk1.6.0_45 -XX:+UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 4160 lines...] [javac] Compiling 48 source files to /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/suggest/classes/java [javac] /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/suggest/src/java/org/apache/lucene/search/suggest/SortedTermFreqPayloadIteratorWrapper.java:146: cannot find symbol [javac] symbol : method compare(long,long) [javac] location: class java.lang.Long [javac] return Long.compare(leftCost, rightCost); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 1 error BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:428: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:408: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:39: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build.xml:557: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1912: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/module-build.xml:57: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:477: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1650: Compile failed; see the compiler error output for details. Total time: 9 minutes 27 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 64bit/jdk1.6.0_45 -XX:+UseCompressedOops -XX:+UseParallelGC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5260) Make older Suggesters more accepting of TermFreqPayloadIterator
[ https://issues.apache.org/jira/browse/LUCENE-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793615#comment-13793615 ] ASF subversion and git services commented on LUCENE-5260: - Commit 1531667 from [~mikemccand] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1531667 ] LUCENE-5260: don't use java7-only API Make older Suggesters more accepting of TermFreqPayloadIterator --- Key: LUCENE-5260 URL: https://issues.apache.org/jira/browse/LUCENE-5260 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Areek Zillur Fix For: 4.6, 5.0 Attachments: LUCENE-5260.patch, LUCENE-5260.patch As discussed in https://issues.apache.org/jira/browse/LUCENE-5251, it would be nice to make the older suggesters accepting of TermFreqPayloadIterator and throw an exception if payload is found (if it cannot be used). This will also allow us to nuke most of the other interfaces for BytesRefIterator. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.6.0_45) - Build # 3278 - Failure!
I already committed a fix ... Mike McCandless http://blog.mikemccandless.com On Sun, Oct 13, 2013 at 7:02 AM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/3278/ Java: 32bit/jdk1.6.0_45 -client -XX:+UseParallelGC All tests passed Build Log: [...truncated 4088 lines...] [javac] Compiling 48 source files to C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\suggest\classes\java [javac] C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\suggest\src\java\org\apache\lucene\search\suggest\SortedTermFreqPayloadIteratorWrapper.java:146: cannot find symbol [javac] symbol : method compare(long,long) [javac] location: class java.lang.Long [javac] return Long.compare(leftCost, rightCost); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 1 error BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:428: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:408: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:39: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build.xml:557: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:1912: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\module-build.xml:57: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:477: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:1650: Compile failed; see the compiler error output for details. Total time: 13 minutes 6 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 32bit/jdk1.6.0_45 -client -XX:+UseParallelGC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5338) Split shards by a route key
[
https://issues.apache.org/jira/browse/SOLR-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-5338:
Attachment: SOLR-5338.patch
# Detect and abort if split.key's hash range is equal to parent shard's hash
range
# Removed useless test added in SolrIndexSplitter. The one in ShardSplitTest is
better.
Split shards by a route key
---
Key: SOLR-5338
URL: https://issues.apache.org/jira/browse/SOLR-5338
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Fix For: 4.6, 5.0
Attachments: SOLR-5338.patch, SOLR-5338.patch, SOLR-5338.patch
Provide a way to split a shard using a route key such that all documents of
the specified route key end up in a single dedicated sub-shard.
Example:
Assume that collection1, shard1 has hash range [0, 20]. Also that route key
'A!' has hash range [12,15]. Then invoking:
{code}
/admin/collections?action=SPLITcollection=collection1split.key=A!
{code}
should produce three sub-shards with hash range [0,11], [12,15] and [16,20].
Specifying the source shard is not required here because the route key is
enough to figure it out. Route keys spanning more than one shards will not be
supported.
Note that the sub-shard with the hash range of the route key may also contain
documents for other route keys whose hashes collide.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5324) Make sub shard replica recovery and shard state switch asynchronous
[ https://issues.apache.org/jira/browse/SOLR-5324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-5324. - Resolution: Fixed Make sub shard replica recovery and shard state switch asynchronous --- Key: SOLR-5324 URL: https://issues.apache.org/jira/browse/SOLR-5324 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 4.6, 5.0 Attachments: SOLR-5324.patch, SOLR-5324.patch, SOLR-5324.patch, SOLR-5324.patch Currently the shard split command waits for all replicas of all sub shards to recover and then switches the state of parent to inactive and sub-shards to active. The problem is that shard split (ab)uses the CoreAdmin WaitForState action to ask the sub shard leader to wait until the replica states are active. This action is prone to timeout. We should make the shard state switching asynchronous. Once all replicas of all sub-shards are 'active', the shard states should be switched automatically. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions
[ https://issues.apache.org/jira/browse/LUCENE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793620#comment-13793620 ] Shalin Shekhar Mangar commented on LUCENE-5273: --- I just noticed on trunk that executing ant example for solr causes lucene tgz file (and hence javadocs) to be built. So the example task takes quite a bit longer to execute: cd solr; ant example branches/lucene_solr_4_5: Total time: 1 minute 33 seconds trunk: Total time: 4 minutes 54 seconds Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions - Key: LUCENE-5273 URL: https://issues.apache.org/jira/browse/LUCENE-5273 Project: Lucene - Core Issue Type: Bug Components: general/build Reporter: Steve Rowe Assignee: Steve Rowe Fix For: 4.6, 5.0 Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we release multiple versions of the same artifact: binary Maven artifacts are not identical to the ones in the Lucene and Solr binary distributions, and the Lucene jars in the Solr binary distribution, including within the war, are not identical to the ones in the Lucene binary distribution. This is bad. It's (probably always?) not horribly bad, since the differences all appear to be caused by the build re-creating manifests and re-building jars and the Solr war from their constituents at various points in the release build process; as a result, manifest timestamp attributes, as well as archive metadata (at least constituent timestamps, maybe other things?), differ each time a jar is rebuilt. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5098) Broadword bit selection
[ https://issues.apache.org/jira/browse/LUCENE-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793626#comment-13793626 ] Paul Elschot commented on LUCENE-5098: -- On reviewing the article I found that the method names I chose for algorithms 1 and 2 in the VIgna article were wrong. I used rank9 and select9 because of the titles of sections 3 and 5 in the article, but the method names do less than what is described in these sections. The method names should have been bitCount and select. I'll add a correction for this at LUCENE-5236, there is no need to reopen this issue. Broadword bit selection --- Key: LUCENE-5098 URL: https://issues.apache.org/jira/browse/LUCENE-5098 Project: Lucene - Core Issue Type: Improvement Components: core/other Reporter: Paul Elschot Assignee: Adrien Grand Priority: Minor Fix For: 4.5 Attachments: LUCENE-5098.patch, LUCENE-5098.patch -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions
[ https://issues.apache.org/jira/browse/LUCENE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793634#comment-13793634 ] Steve Rowe commented on LUCENE-5273: Thanks for reporting the slowdown, Shalin, I'll look into it. Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions - Key: LUCENE-5273 URL: https://issues.apache.org/jira/browse/LUCENE-5273 Project: Lucene - Core Issue Type: Bug Components: general/build Reporter: Steve Rowe Assignee: Steve Rowe Fix For: 4.6, 5.0 Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we release multiple versions of the same artifact: binary Maven artifacts are not identical to the ones in the Lucene and Solr binary distributions, and the Lucene jars in the Solr binary distribution, including within the war, are not identical to the ones in the Lucene binary distribution. This is bad. It's (probably always?) not horribly bad, since the differences all appear to be caused by the build re-creating manifests and re-building jars and the Solr war from their constituents at various points in the release build process; as a result, manifest timestamp attributes, as well as archive metadata (at least constituent timestamps, maybe other things?), differ each time a jar is rebuilt. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5236) Use broadword bit selection in EliasFanoDecoder
[ https://issues.apache.org/jira/browse/LUCENE-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-5236: - Attachment: LUCENE-5236.patch The patch of 13 Oct 2013 also includes a method name correction in the BroadWord class, and it removes some unused code and one or two commented code lines. Use broadword bit selection in EliasFanoDecoder --- Key: LUCENE-5236 URL: https://issues.apache.org/jira/browse/LUCENE-5236 Project: Lucene - Core Issue Type: Improvement Reporter: Paul Elschot Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-5236.patch, LUCENE-5236.patch, LUCENE-5236.patch, TestDocIdSetBenchmark.java Try and speed up decoding -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-5236) Use broadword bit selection in EliasFanoDecoder
[ https://issues.apache.org/jira/browse/LUCENE-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793636#comment-13793636 ] Paul Elschot edited comment on LUCENE-5236 at 10/13/13 12:44 PM: - The patch of 13 Oct 2013 also includes a method name correction in the BroadWord class (see at LUCENE-5098), and it removes some unused code and one or two commented code lines. was (Author: paul.elsc...@xs4all.nl): The patch of 13 Oct 2013 also includes a method name correction in the BroadWord class, and it removes some unused code and one or two commented code lines. Use broadword bit selection in EliasFanoDecoder --- Key: LUCENE-5236 URL: https://issues.apache.org/jira/browse/LUCENE-5236 Project: Lucene - Core Issue Type: Improvement Reporter: Paul Elschot Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-5236.patch, LUCENE-5236.patch, LUCENE-5236.patch, TestDocIdSetBenchmark.java Try and speed up decoding -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5272) OpenBitSet.ensureCapacity does not modify numBits
[
https://issues.apache.org/jira/browse/LUCENE-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793637#comment-13793637
]
Shai Erera commented on LUCENE-5272:
I was about to post an updated patch when I realized that now {{OBS.length()}}
is broken. It currently returns {{bits.length 6}}, which is completely
unrelated to neither {{wlen}} nor {{numBits}}. Bits.length() javadocs say:
Returns the number of bits in this set, what should we return?
* If we want to adhere to the jdocs, we should return {{numBits}}, but then
numBits cannot be an assertion-only member.
* If we want to return {{wlen 6}}, then we should nuke {{numBits}} because
otherwise you will call {{length()}} to receive e.g 64 but when you will call
{{fastSet(52)}} you may trip the assertion error.
* If we return bits.length, then we can nuke both wlen and numBits.
Actually, OpenBitSetIterator is also broken, because it iterates up to wlen,
again with no relation to numBits. And of course it's now unrelated to
bits.length too, so e.g. if you call OBS.length() and compares that with the
number of nextDoc() calls the iterator returns (say when all bits are 'set'),
the numbers are not equal...
Why do we need these two fields? As far as I can tell, wlen is only
bits.length when someone shares a long[] but limit its size. Do we really care
about this case? I can understand the reason to keep {{numBits}} because e.g.
you want to adhere to Bits spec:
* Return numBits from length()
* Bits.get(int) document that you should not call it with out of bounds indexes
* Iterator should iterate up to the last set/cleared bit
But it has to be a first-class member, not an assert-only one.
Another quirkiness, what should the app expect to happen if it calls
{{obs.get(170)}} (and say bits.length=1)? It currently receives false and not
e.g. AIOOBE. But this could falsly lead to calling fastSet(170) thinking that
the bitset is at the right size. I'm not saying this is a super-duper usecase
we should handle, since if an app calls fastSet, it should also call fastGet,
but I think it will be good if we are consistent about when you get false and
when you hit out-of-bounds.
The out-of-bounds here are also related to 'wlen', as the method checks if the
bit is within bits.length range, not wlen range. This is another bug I think
since if you share a bits[] which has say bit 170 set, but you limit it to 2
words, calling OBS.get(170) will false return true?
I think this class could use some serious overhauling and re-thinking. I find
it very confusing as it is written now. We should decide what are the contracts
of each method, and then implement it as such.
And though unrelated to the bugs reported in this issue, perhaps someone can
explain why we need both the 'int' and 'long' method variants? Can't we have
only the long indexes?
OpenBitSet.ensureCapacity does not modify numBits
-
Key: LUCENE-5272
URL: https://issues.apache.org/jira/browse/LUCENE-5272
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Reporter: Shai Erera
Attachments: LUCENE-5272.patch
It's a simple bug, reproduced by this simple test:
{code}
public void testEnsureCapacity() {
OpenBitSet bits = new OpenBitSet(1);
bits.fastSet(0);
bits.ensureCapacity(5); // make room for more bits
bits.fastSet(2);
}
{code}
The problem is that {{numBits}} which is used only for assrets isn't modified
by ensureCapacity and so the next fastSet trips the assert. I guess we should
also fix ensureCapacityWords and test it too.
I may not be able to fix this until Sunday though, so if anyone wants to fix
it before (maybe it can make it into 4.5.1), feel free.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5272) OpenBitSet.ensureCapacity does not modify numBits
[
https://issues.apache.org/jira/browse/LUCENE-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793654#comment-13793654
]
Paul Elschot commented on LUCENE-5272:
--
I'm adding a method to OpenBitSetIterator to support advanceToJustBefore for a
new DocBlockIterator, see LUCENE-5092.
Basically this does an advance followed by a prevSetBit, and when the advance
is getting too far out, it is important to know precisely where the end of the
bit set is.
Also I found that in order to be able to use prevSetBit from OBS I had to add
this static method there:
{code}
public static int prevSetBitStatic(int index, long[] bits, int wlen) {
}
{code}
which is ugly. It would be better to have the OBS as an attribute in the
OBSIterator so the existing prevSetBit method can be called directly.
So I am in favour of an overhaul, remove (deprecate?) everything that is not
currently used, and make OBS an attribute in OBSIterator instead of the long[]
and its length.
For the end of the bit set, bits.length seems to be the simplest thing that
could possibly work, so it is worth at try.
For the 'int' and 'long' variants, maybe we can do without the 'int' variants
now that 64 bit processors have become common.
Another candidate for a minor clean up is EliasFanoEncoder.numLongsForBits
which is a long implementation of OBS.bits2words.
OpenBitSet.ensureCapacity does not modify numBits
-
Key: LUCENE-5272
URL: https://issues.apache.org/jira/browse/LUCENE-5272
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Reporter: Shai Erera
Attachments: LUCENE-5272.patch
It's a simple bug, reproduced by this simple test:
{code}
public void testEnsureCapacity() {
OpenBitSet bits = new OpenBitSet(1);
bits.fastSet(0);
bits.ensureCapacity(5); // make room for more bits
bits.fastSet(2);
}
{code}
The problem is that {{numBits}} which is used only for assrets isn't modified
by ensureCapacity and so the next fastSet trips the assert. I guess we should
also fix ensureCapacityWords and test it too.
I may not be able to fix this until Sunday though, so if anyone wants to fix
it before (maybe it can make it into 4.5.1), feel free.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5325) zk connection loss causes overseer leader loss
[ https://issues.apache.org/jira/browse/SOLR-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793666#comment-13793666 ] Mark Miller commented on SOLR-5325: --- I think that the reason that this is hard to catch in a test is that we try and do retries on connectionloss up to the expiration time - there must be some case where we were still getting a connectionloss and no expiration though. This issue should handle that case for this particular bit of code, but as an overall precautionary measure, I have also bumped up the retries just a bit to try and ensure they are going beyond the session timeout. zk connection loss causes overseer leader loss -- Key: SOLR-5325 URL: https://issues.apache.org/jira/browse/SOLR-5325 Project: Solr Issue Type: Bug Affects Versions: 4.3, 4.4, 4.5 Reporter: Christine Poerschke Assignee: Mark Miller Fix For: 4.5.1, 4.6, 5.0 Attachments: SOLR-5325.patch, SOLR-5325.patch, SOLR-5325.patch The problem we saw was that when the solr overseer leader experienced temporary zk connectivity problems it stopped processing overseer queue events. This first happened when quorum within the external zk ensemble was lost due to too many zookeepers being stopped (similar to SOLR-5199). The second time it happened when there was a sufficient number of zookeepers but they were holding zookeeper leadership elections and thus refused connections (the elections were taking several seconds, we were using the default zookeeper.cnxTimeout=5s value and it was hit for one ensemble member). -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5342) In some places, when a caught exception is re-thrown, the original exception is not included
[
https://issues.apache.org/jira/browse/SOLR-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793665#comment-13793665
]
Robert Muir commented on SOLR-5342:
---
{quote}
While fixing this, I discovered other places that are missing this as well.
Some of them I elected not to fix, either because it's catching IOException
(which normally provides good messages), or because it was in a location that
might get called frequently, which would greatly increase logging output.
{quote}
If you won't fix these, I will find them all and fix them myself. It does not
matter if the message is good and logging does not matter either: hiding
stacktraces is seriously wrong.
In some places, when a caught exception is re-thrown, the original exception
is not included
Key: SOLR-5342
URL: https://issues.apache.org/jira/browse/SOLR-5342
Project: Solr
Issue Type: Improvement
Affects Versions: 4.5
Reporter: Shawn Heisey
Assignee: Shawn Heisey
Priority: Minor
Fix For: 4.5.1, 4.6, 5.0
Attachments: SOLR-5342.patch
ShardHandlerFactory#newInstance catches exceptions and rethrows them. It was
including the message from the caught exception, but not including the actual
exception. This made it difficult to figure out the root cause for an SSL
initialization error.
While fixing this, I discovered other places that are missing this as well.
Some of them I elected not to fix, either because it's catching IOException
(which normally provides good messages), or because it was in a location that
might get called frequently, which would greatly increase logging output.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5325) zk connection loss causes overseer leader loss
[ https://issues.apache.org/jira/browse/SOLR-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-5325. --- Resolution: Fixed Thanks Christine! zk connection loss causes overseer leader loss -- Key: SOLR-5325 URL: https://issues.apache.org/jira/browse/SOLR-5325 Project: Solr Issue Type: Bug Affects Versions: 4.3, 4.4, 4.5 Reporter: Christine Poerschke Assignee: Mark Miller Fix For: 4.5.1, 4.6, 5.0 Attachments: SOLR-5325.patch, SOLR-5325.patch, SOLR-5325.patch The problem we saw was that when the solr overseer leader experienced temporary zk connectivity problems it stopped processing overseer queue events. This first happened when quorum within the external zk ensemble was lost due to too many zookeepers being stopped (similar to SOLR-5199). The second time it happened when there was a sufficient number of zookeepers but they were holding zookeeper leadership elections and thus refused connections (the elections were taking several seconds, we were using the default zookeeper.cnxTimeout=5s value and it was hit for one ensemble member). -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5280) Rename TermFreqPayloadIterator - SuggestionIterator
Michael McCandless created LUCENE-5280: -- Summary: Rename TermFreqPayloadIterator - SuggestionIterator Key: LUCENE-5280 URL: https://issues.apache.org/jira/browse/LUCENE-5280 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.6, 5.0 The current name is cumbersome, and annoying to change whenever we add something to the iterator (in this case payloads). Since we are breaking it anyway in 4.6, I think we should take the opportunity to find a better name. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793683#comment-13793683 ] Elran Dvir commented on SOLR-5084: -- Thanks! new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Assignee: Erick Erickson Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch, Solr-5084.trunk.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Jenkins build is back to normal : 4.5.1-solr-test-core-loop #6
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/6/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5281) NPE: TestDirectoryTaxonomyReader.testGetChildren
Steve Rowe created LUCENE-5281:
--
Summary: NPE: TestDirectoryTaxonomyReader.testGetChildren
Key: LUCENE-5281
URL: https://issues.apache.org/jira/browse/LUCENE-5281
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.5, 5.0
Reporter: Steve Rowe
Reproduces 100% for me on trunk and on branch_4x (OS X 10.8.5, Oracle Java 64
bit 1.7.0_25):
{noformat}
[junit4] Suite:
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestDirectoryTaxonomyReader -Dtests.method=testGetChildren
-Dtests.seed=B94C5192B4851C12 -Dtests.slow=true -Dtests.locale=es_UY
-Dtests.timezone=America/Santa_Isabel -Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.48s | TestDirectoryTaxonomyReader.testGetChildren
[junit4] Throwable #1: java.lang.NullPointerException
[junit4]at
__randomizedtesting.SeedInfo.seed([B94C5192B4851C12:D5BAEB4F58AE9D94]:0)
[junit4]at
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren(TestDirectoryTaxonomyReader.java:508)
[junit4]at java.lang.Thread.run(Thread.java:724)
[junit4] 2 NOTE: test params are: codec=Lucene40,
sim=RandomSimilarityProvider(queryNorm=false,coord=crazy): {}, locale=es_UY,
timezone=America/Santa_Isabel
[junit4] 2 NOTE: Mac OS X 10.8.5 x86_64/Oracle Corporation 1.7.0_25
(64-bit)/cpus=8,threads=1,free=83697144,total=119537664
[junit4] 2 NOTE: All tests run in this JVM: [TestDirectoryTaxonomyReader]
[junit4] Completed in 1.06s, 1 test, 1 error FAILURES!
[junit4]
[junit4]
[junit4] Tests with failures:
[junit4] -
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5281) NPE: TestDirectoryTaxonomyReader.testGetChildren
[
https://issues.apache.org/jira/browse/LUCENE-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated LUCENE-5281:
---
Component/s: modules/facet
NPE: TestDirectoryTaxonomyReader.testGetChildren
Key: LUCENE-5281
URL: https://issues.apache.org/jira/browse/LUCENE-5281
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Affects Versions: 4.5, 5.0
Reporter: Steve Rowe
Reproduces 100% for me on trunk and on branch_4x (OS X 10.8.5, Oracle Java 64
bit 1.7.0_25):
{noformat}
[junit4] Suite:
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestDirectoryTaxonomyReader -Dtests.method=testGetChildren
-Dtests.seed=B94C5192B4851C12 -Dtests.slow=true -Dtests.locale=es_UY
-Dtests.timezone=America/Santa_Isabel -Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.48s | TestDirectoryTaxonomyReader.testGetChildren
[junit4] Throwable #1: java.lang.NullPointerException
[junit4] at
__randomizedtesting.SeedInfo.seed([B94C5192B4851C12:D5BAEB4F58AE9D94]:0)
[junit4] at
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren(TestDirectoryTaxonomyReader.java:508)
[junit4] at java.lang.Thread.run(Thread.java:724)
[junit4] 2 NOTE: test params are: codec=Lucene40,
sim=RandomSimilarityProvider(queryNorm=false,coord=crazy): {}, locale=es_UY,
timezone=America/Santa_Isabel
[junit4] 2 NOTE: Mac OS X 10.8.5 x86_64/Oracle Corporation 1.7.0_25
(64-bit)/cpus=8,threads=1,free=83697144,total=119537664
[junit4] 2 NOTE: All tests run in this JVM:
[TestDirectoryTaxonomyReader]
[junit4] Completed in 1.06s, 1 test, 1 error FAILURES!
[junit4]
[junit4]
[junit4] Tests with failures:
[junit4] -
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5342) In some places, when a caught exception is re-thrown, the original exception is not included
[ https://issues.apache.org/jira/browse/SOLR-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793684#comment-13793684 ] Shawn Heisey commented on SOLR-5342: I can do it, I just wasn't sure whether I *should*. My search method was to use Eclipse to locate usages of Throwable.getMessage(). I saw cases where getMessage() is used to construct logging messages, but the actual exception was not included in the logger call. I also did not touch any test code. I'll put together a patch that changes every instance I can find, and then we can discuss whether any need to be reverted. In some places, when a caught exception is re-thrown, the original exception is not included Key: SOLR-5342 URL: https://issues.apache.org/jira/browse/SOLR-5342 Project: Solr Issue Type: Improvement Affects Versions: 4.5 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.5.1, 4.6, 5.0 Attachments: SOLR-5342.patch ShardHandlerFactory#newInstance catches exceptions and rethrows them. It was including the message from the caught exception, but not including the actual exception. This made it difficult to figure out the root cause for an SSL initialization error. While fixing this, I discovered other places that are missing this as well. Some of them I elected not to fix, either because it's catching IOException (which normally provides good messages), or because it was in a location that might get called frequently, which would greatly increase logging output. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5281) NPE: TestDirectoryTaxonomyReader.testGetChildren
[
https://issues.apache.org/jira/browse/LUCENE-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated LUCENE-5281:
---
Description:
Reproduces 100% for me on trunk and on branch_4x - below is from branch_4x:
{noformat}
[junit4] Suite:
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestDirectoryTaxonomyReader -Dtests.method=testGetChildren
-Dtests.seed=B94C5192B4851C12 -Dtests.slow=true -Dtests.locale=es_UY
-Dtests.timezone=America/Santa_Isabel -Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.48s | TestDirectoryTaxonomyReader.testGetChildren
[junit4] Throwable #1: java.lang.NullPointerException
[junit4]at
__randomizedtesting.SeedInfo.seed([B94C5192B4851C12:D5BAEB4F58AE9D94]:0)
[junit4]at
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren(TestDirectoryTaxonomyReader.java:508)
[junit4]at java.lang.Thread.run(Thread.java:724)
[junit4] 2 NOTE: test params are: codec=Lucene40,
sim=RandomSimilarityProvider(queryNorm=false,coord=crazy): {}, locale=es_UY,
timezone=America/Santa_Isabel
[junit4] 2 NOTE: Mac OS X 10.8.5 x86_64/Oracle Corporation 1.7.0_25
(64-bit)/cpus=8,threads=1,free=83697144,total=119537664
[junit4] 2 NOTE: All tests run in this JVM: [TestDirectoryTaxonomyReader]
[junit4] Completed in 1.06s, 1 test, 1 error FAILURES!
[junit4]
[junit4]
[junit4] Tests with failures:
[junit4] -
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren
{noformat}
was:
Reproduces 100% for me on trunk and on branch_4x (OS X 10.8.5, Oracle Java 64
bit 1.7.0_25):
{noformat}
[junit4] Suite:
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestDirectoryTaxonomyReader -Dtests.method=testGetChildren
-Dtests.seed=B94C5192B4851C12 -Dtests.slow=true -Dtests.locale=es_UY
-Dtests.timezone=America/Santa_Isabel -Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.48s | TestDirectoryTaxonomyReader.testGetChildren
[junit4] Throwable #1: java.lang.NullPointerException
[junit4]at
__randomizedtesting.SeedInfo.seed([B94C5192B4851C12:D5BAEB4F58AE9D94]:0)
[junit4]at
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren(TestDirectoryTaxonomyReader.java:508)
[junit4]at java.lang.Thread.run(Thread.java:724)
[junit4] 2 NOTE: test params are: codec=Lucene40,
sim=RandomSimilarityProvider(queryNorm=false,coord=crazy): {}, locale=es_UY,
timezone=America/Santa_Isabel
[junit4] 2 NOTE: Mac OS X 10.8.5 x86_64/Oracle Corporation 1.7.0_25
(64-bit)/cpus=8,threads=1,free=83697144,total=119537664
[junit4] 2 NOTE: All tests run in this JVM: [TestDirectoryTaxonomyReader]
[junit4] Completed in 1.06s, 1 test, 1 error FAILURES!
[junit4]
[junit4]
[junit4] Tests with failures:
[junit4] -
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren
{noformat}
NPE: TestDirectoryTaxonomyReader.testGetChildren
Key: LUCENE-5281
URL: https://issues.apache.org/jira/browse/LUCENE-5281
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Affects Versions: 4.5, 5.0
Reporter: Steve Rowe
Reproduces 100% for me on trunk and on branch_4x - below is from branch_4x:
{noformat}
[junit4] Suite:
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestDirectoryTaxonomyReader -Dtests.method=testGetChildren
-Dtests.seed=B94C5192B4851C12 -Dtests.slow=true -Dtests.locale=es_UY
-Dtests.timezone=America/Santa_Isabel -Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.48s | TestDirectoryTaxonomyReader.testGetChildren
[junit4] Throwable #1: java.lang.NullPointerException
[junit4] at
__randomizedtesting.SeedInfo.seed([B94C5192B4851C12:D5BAEB4F58AE9D94]:0)
[junit4] at
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren(TestDirectoryTaxonomyReader.java:508)
[junit4] at java.lang.Thread.run(Thread.java:724)
[junit4] 2 NOTE: test params are: codec=Lucene40,
sim=RandomSimilarityProvider(queryNorm=false,coord=crazy): {}, locale=es_UY,
timezone=America/Santa_Isabel
[junit4] 2 NOTE: Mac OS X 10.8.5 x86_64/Oracle Corporation 1.7.0_25
(64-bit)/cpus=8,threads=1,free=83697144,total=119537664
[junit4] 2 NOTE: All tests run in this JVM:
[TestDirectoryTaxonomyReader]
[junit4] Completed in 1.06s, 1 test, 1 error FAILURES!
[junit4]
[junit4]
[junit4] Tests with failures:
Build failed in Jenkins: 4.5.1-solr-test-core-loop #7
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/7/ -- [...truncated 12821 lines...] [junit4] [junit4] Suite: org.apache.solr.core.TestImplicitCoreProperties [junit4] Completed on J2 in 0.89s, 1 test [junit4] [junit4] Suite: org.apache.solr.update.processor.UniqFieldsUpdateProcessorFactoryTest [junit4] Completed on J0 in 0.66s, 1 test [junit4] [junit4] Suite: org.apache.solr.update.processor.FieldMutatingUpdateProcessorTest [junit4] Completed on J1 in 0.70s, 27 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSchemaNameResource [junit4] Completed on J2 in 0.49s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestDynamicFieldCollectionResource [junit4] Completed on J3 in 0.52s, 5 tests [junit4] [junit4] Suite: org.apache.solr.search.function.SortByFunctionTest [junit4] Completed on J0 in 0.85s, 2 tests [junit4] [junit4] Suite: org.apache.solr.SolrInfoMBeanTest [junit4] Completed on J1 in 0.69s, 1 test [junit4] [junit4] Suite: org.apache.solr.search.TestValueSourceCache [junit4] Completed on J2 in 0.88s, 2 tests [junit4] [junit4] Suite: org.apache.solr.schema.IndexSchemaTest [junit4] Completed on J3 in 0.77s, 3 tests [junit4] [junit4] Suite: org.apache.solr.core.RequestHandlersTest [junit4] Completed on J0 in 0.71s, 4 tests [junit4] [junit4] Suite: org.apache.solr.schema.IndexSchemaRuntimeFieldTest [junit4] Completed on J1 in 0.63s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSchemaSimilarityResource [junit4] Completed on J3 in 0.47s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.TestOmitPositions [junit4] Completed on J2 in 0.64s, 2 tests [junit4] [junit4] Suite: org.apache.solr.request.TestRemoteStreaming [junit4] Completed on J0 in 0.62s, 4 tests [junit4] [junit4] Suite: org.apache.solr.response.TestPHPSerializedResponseWriter [junit4] Completed on J1 in 0.67s, 2 tests [junit4] [junit4] Suite: org.apache.solr.core.TestMergePolicyConfig [junit4] Completed on J3 in 0.69s, 4 tests [junit4] [junit4] Suite: org.apache.solr.request.TestBinaryResponseWriter [junit4] Completed on J2 in 0.62s, 2 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSolrQueryParserDefaultOperatorResource [junit4] Completed on J0 in 0.43s, 1 test [junit4] [junit4] Suite: org.apache.solr.handler.component.SearchHandlerTest [junit4] Completed on J1 in 0.61s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestFieldTypeResource [junit4] Completed on J3 in 0.58s, 4 tests [junit4] [junit4] Suite: org.apache.solr.search.TestLFUCache [junit4] Completed on J2 in 0.54s, 5 tests [junit4] [junit4] Suite: org.apache.solr.core.TestQuerySenderListener [junit4] Completed on J0 in 0.54s, 3 tests [junit4] [junit4] Suite: org.apache.solr.analysis.TestReversedWildcardFilterFactory [junit4] Completed on J1 in 0.50s, 4 tests [junit4] [junit4] Suite: org.apache.solr.core.TestJmxMonitoredMap [junit4] Completed on J2 in 0.09s, 2 tests [junit4] [junit4] Suite: org.apache.solr.schema.PrimitiveFieldTypeTest [junit4] Completed on J3 in 0.51s, 1 test [junit4] [junit4] Suite: org.apache.solr.spelling.suggest.TestAnalyzedSuggestions [junit4] Completed on J1 in 0.42s, 2 tests [junit4] [junit4] Suite: org.apache.solr.search.TestElisionMultitermQuery [junit4] Completed on J2 in 0.42s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestUniqueKeyFieldResource [junit4] Completed on J0 in 0.58s, 1 test [junit4] [junit4] Suite: org.apache.solr.util.TestFastOutputStream [junit4] Completed on J1 in 0.10s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.TestCollationField [junit4] Completed on J3 in 0.36s, 8 tests [junit4] [junit4] Suite: org.apache.solr.core.CoreContainerCoreInitFailuresTest [junit4] Completed on J2 in 0.32s, 2 tests [junit4] [junit4] Suite: org.apache.solr.schema.NumericFieldsTest [junit4] Completed on J0 in 0.36s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.MultiTermTest [junit4] Completed on J1 in 0.32s, 3 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestClassNameShortening [junit4] Completed on J3 in 0.30s, 3 tests [junit4] [junit4] Suite: org.apache.solr.servlet.DirectSolrConnectionTest [junit4] Completed on J1 in 0.21s, 2 tests [junit4] [junit4] Suite: org.apache.solr.schema.NotRequiredUniqueKeyTest [junit4] Completed on J2 in 0.26s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSerializedLuceneMatchVersion [junit4] Completed on J0 in 0.27s, 2 tests [junit4] [junit4] Suite: org.apache.solr.analysis.TestCollationKeyRangeQueries [junit4] Completed on J3 in 0.23s, 3 tests
[jira] [Commented] (LUCENE-5272) OpenBitSet.ensureCapacity does not modify numBits
[
https://issues.apache.org/jira/browse/LUCENE-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793686#comment-13793686
]
Shai Erera commented on LUCENE-5272:
I don't think we need to deprecate anything as there's no way anyone relies on
these methods and his app works (setNumWords, length etc.). I am also thinking
of a new GrowableBitSet which relaxes all bounds checks and puts the
responsibility on the app to call grow()/ensureCapacity(). This will also get
rid of the duplicate methods (set/fastSet, get/fastSet etc.).
Unfortunately we cannot modify OBS to relax bound checks because that's a
serious backwards break. But perhaps we can completely deprecate it in favor of
the new bitset.
OpenBitSet.ensureCapacity does not modify numBits
-
Key: LUCENE-5272
URL: https://issues.apache.org/jira/browse/LUCENE-5272
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Reporter: Shai Erera
Attachments: LUCENE-5272.patch
It's a simple bug, reproduced by this simple test:
{code}
public void testEnsureCapacity() {
OpenBitSet bits = new OpenBitSet(1);
bits.fastSet(0);
bits.ensureCapacity(5); // make room for more bits
bits.fastSet(2);
}
{code}
The problem is that {{numBits}} which is used only for assrets isn't modified
by ensureCapacity and so the next fastSet trips the assert. I guess we should
also fix ensureCapacityWords and test it too.
I may not be able to fix this until Sunday though, so if anyone wants to fix
it before (maybe it can make it into 4.5.1), feel free.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Jenkins build is back to normal : 4.5.1-solr-test-core-loop #8
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/8/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-5281) NPE: TestDirectoryTaxonomyReader.testGetChildren
[
https://issues.apache.org/jira/browse/LUCENE-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera reassigned LUCENE-5281:
--
Assignee: Shai Erera
NPE: TestDirectoryTaxonomyReader.testGetChildren
Key: LUCENE-5281
URL: https://issues.apache.org/jira/browse/LUCENE-5281
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Affects Versions: 4.5, 5.0
Reporter: Steve Rowe
Assignee: Shai Erera
Reproduces 100% for me on trunk and on branch_4x - below is from branch_4x:
{noformat}
[junit4] Suite:
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestDirectoryTaxonomyReader -Dtests.method=testGetChildren
-Dtests.seed=B94C5192B4851C12 -Dtests.slow=true -Dtests.locale=es_UY
-Dtests.timezone=America/Santa_Isabel -Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.48s | TestDirectoryTaxonomyReader.testGetChildren
[junit4] Throwable #1: java.lang.NullPointerException
[junit4] at
__randomizedtesting.SeedInfo.seed([B94C5192B4851C12:D5BAEB4F58AE9D94]:0)
[junit4] at
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren(TestDirectoryTaxonomyReader.java:508)
[junit4] at java.lang.Thread.run(Thread.java:724)
[junit4] 2 NOTE: test params are: codec=Lucene40,
sim=RandomSimilarityProvider(queryNorm=false,coord=crazy): {}, locale=es_UY,
timezone=America/Santa_Isabel
[junit4] 2 NOTE: Mac OS X 10.8.5 x86_64/Oracle Corporation 1.7.0_25
(64-bit)/cpus=8,threads=1,free=83697144,total=119537664
[junit4] 2 NOTE: All tests run in this JVM:
[TestDirectoryTaxonomyReader]
[junit4] Completed in 1.06s, 1 test, 1 error FAILURES!
[junit4]
[junit4]
[junit4] Tests with failures:
[junit4] -
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5281) NPE: TestDirectoryTaxonomyReader.testGetChildren
[
https://issues.apache.org/jira/browse/LUCENE-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793695#comment-13793695
]
Shai Erera commented on LUCENE-5281:
Thanks for reporting, I'll check.
NPE: TestDirectoryTaxonomyReader.testGetChildren
Key: LUCENE-5281
URL: https://issues.apache.org/jira/browse/LUCENE-5281
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Affects Versions: 4.5, 5.0
Reporter: Steve Rowe
Assignee: Shai Erera
Reproduces 100% for me on trunk and on branch_4x - below is from branch_4x:
{noformat}
[junit4] Suite:
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestDirectoryTaxonomyReader -Dtests.method=testGetChildren
-Dtests.seed=B94C5192B4851C12 -Dtests.slow=true -Dtests.locale=es_UY
-Dtests.timezone=America/Santa_Isabel -Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.48s | TestDirectoryTaxonomyReader.testGetChildren
[junit4] Throwable #1: java.lang.NullPointerException
[junit4] at
__randomizedtesting.SeedInfo.seed([B94C5192B4851C12:D5BAEB4F58AE9D94]:0)
[junit4] at
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren(TestDirectoryTaxonomyReader.java:508)
[junit4] at java.lang.Thread.run(Thread.java:724)
[junit4] 2 NOTE: test params are: codec=Lucene40,
sim=RandomSimilarityProvider(queryNorm=false,coord=crazy): {}, locale=es_UY,
timezone=America/Santa_Isabel
[junit4] 2 NOTE: Mac OS X 10.8.5 x86_64/Oracle Corporation 1.7.0_25
(64-bit)/cpus=8,threads=1,free=83697144,total=119537664
[junit4] 2 NOTE: All tests run in this JVM:
[TestDirectoryTaxonomyReader]
[junit4] Completed in 1.06s, 1 test, 1 error FAILURES!
[junit4]
[junit4]
[junit4] Tests with failures:
[junit4] -
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions
[ https://issues.apache.org/jira/browse/LUCENE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793703#comment-13793703 ] ASF subversion and git services commented on LUCENE-5273: - Commit 1531711 from [~steve_rowe] in branch 'dev/trunk' [ https://svn.apache.org/r1531711 ] LUCENE-5273: Only unpack Lucene/Solr jars from binary distributions - other stuff not needed Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions - Key: LUCENE-5273 URL: https://issues.apache.org/jira/browse/LUCENE-5273 Project: Lucene - Core Issue Type: Bug Components: general/build Reporter: Steve Rowe Assignee: Steve Rowe Fix For: 4.6, 5.0 Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we release multiple versions of the same artifact: binary Maven artifacts are not identical to the ones in the Lucene and Solr binary distributions, and the Lucene jars in the Solr binary distribution, including within the war, are not identical to the ones in the Lucene binary distribution. This is bad. It's (probably always?) not horribly bad, since the differences all appear to be caused by the build re-creating manifests and re-building jars and the Solr war from their constituents at various points in the release build process; as a result, manifest timestamp attributes, as well as archive metadata (at least constituent timestamps, maybe other things?), differ each time a jar is rebuilt. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Build failed in Jenkins: 4.5.1-solr-test-core-loop #13
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/13/changes Changes: [sarowe] Modernize Solr package creation includes/excludes: client/** are gone; and README.committers.txt has moved from lib/ to licenses/. (merged trunk r1531705) -- [...truncated 11799 lines...] [junit4] Completed on J1 in 0.69s, 2 tests [junit4] [junit4] Suite: org.apache.solr.handler.DocumentAnalysisRequestHandlerTest [junit4] Completed on J3 in 0.68s, 4 tests [junit4] [junit4] Suite: org.apache.solr.search.QueryParsingTest [junit4] Completed on J2 in 0.73s, 4 tests [junit4] [junit4] Suite: org.apache.solr.handler.CSVRequestHandlerTest [junit4] Completed on J1 in 0.69s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.IndexSchemaTest [junit4] Completed on J0 in 0.77s, 3 tests [junit4] [junit4] Suite: org.apache.solr.schema.IndexSchemaRuntimeFieldTest [junit4] Completed on J3 in 0.70s, 1 test [junit4] [junit4] Suite: org.apache.solr.core.AlternateDirectoryTest [junit4] Completed on J2 in 0.55s, 2 tests [junit4] [junit4] Suite: org.apache.solr.schema.TestOmitPositions [junit4] Completed on J0 in 0.68s, 2 tests [junit4] [junit4] Suite: org.apache.solr.servlet.CacheHeaderTest [junit4] Completed on J1 in 0.87s, 5 tests [junit4] [junit4] Suite: org.apache.solr.handler.admin.InfoHandlerTest [junit4] Completed on J3 in 0.64s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSchemaVersionResource [junit4] Completed on J0 in 0.46s, 1 test [junit4] [junit4] Suite: org.apache.solr.handler.component.SearchHandlerTest [junit4] Completed on J2 in 0.67s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestFieldCollectionResource [junit4] Completed on J1 in 0.66s, 7 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestFieldTypeCollectionResource [junit4] Completed on J3 in 0.52s, 2 tests [junit4] [junit4] Suite: org.apache.solr.schema.RequiredFieldsTest [junit4] Completed on J0 in 0.70s, 3 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestDynamicFieldResource [junit4] Completed on J2 in 0.53s, 3 tests [junit4] [junit4] Suite: org.apache.solr.core.TestInfoStreamLogging [junit4] Completed on J1 in 0.57s, 1 test [junit4] [junit4] Suite: org.apache.solr.servlet.NoCacheHeaderTest [junit4] Completed on J3 in 0.58s, 3 tests [junit4] [junit4] Suite: org.apache.solr.search.TestComponentsName [junit4] Completed on J0 in 0.59s, 1 test [junit4] [junit4] Suite: org.apache.solr.core.TestQuerySenderListener [junit4] Completed on J2 in 0.57s, 3 tests [junit4] [junit4] Suite: org.apache.solr.handler.component.ResponseLogComponentTest [junit4] Completed on J1 in 0.54s, 3 tests [junit4] [junit4] Suite: org.apache.solr.core.TestConfig [junit4] Completed on J2 in 0.49s, 7 tests [junit4] [junit4] Suite: org.apache.solr.search.TestLFUCache [junit4] Completed on J3 in 0.61s, 5 tests [junit4] [junit4] Suite: org.apache.solr.core.TestQuerySenderNoQuery [junit4] Completed on J0 in 0.57s, 3 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSolrQueryParserResource [junit4] Completed on J1 in 0.46s, 1 test [junit4] [junit4] Suite: org.apache.solr.highlight.TestPostingsSolrHighlighter [junit4] Completed on J3 in 0.44s, 12 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestUniqueKeyFieldResource [junit4] Completed on J0 in 0.43s, 1 test [junit4] [junit4] Suite: org.apache.solr.handler.component.BadComponentTest [junit4] Completed on J2 in 0.51s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSchemaSimilarityResource [junit4] Completed on J1 in 0.49s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.PrimitiveFieldTypeTest [junit4] Completed on J3 in 0.48s, 1 test [junit4] [junit4] Suite: org.apache.solr.search.TestElisionMultitermQuery [junit4] Completed on J0 in 0.35s, 1 test [junit4] [junit4] Suite: org.apache.solr.search.TestSearchPerf [junit4] Completed on J2 in 0.43s, 1 test [junit4] [junit4] Suite: org.apache.solr.search.TestDocSet [junit4] Completed on J1 in 0.37s, 2 tests [junit4] [junit4] Suite: org.apache.solr.schema.TestBinaryField [junit4] Completed on J0 in 0.24s, 1 test [junit4] [junit4] Suite: org.apache.solr.spelling.suggest.TestFuzzyAnalyzedSuggestions [junit4] Completed on J2 in 0.21s, 4 tests [junit4] [junit4] Suite: org.apache.solr.schema.NumericFieldsTest [junit4] Completed on J3 in 0.30s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestClassNameShortening [junit4] Completed on J2 in 0.24s, 3 tests [junit4] [junit4] Suite: org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest [junit4] Completed on J1 in 0.27s, 3
Jenkins build is back to normal : 4.5.1-solr-test-core-loop #14
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/14/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5281) NPE: TestDirectoryTaxonomyReader.testGetChildren
[
https://issues.apache.org/jira/browse/LUCENE-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793709#comment-13793709
]
Shai Erera commented on LUCENE-5281:
It was a test bug. I'll commit a fix shortly.
NPE: TestDirectoryTaxonomyReader.testGetChildren
Key: LUCENE-5281
URL: https://issues.apache.org/jira/browse/LUCENE-5281
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Affects Versions: 4.5, 5.0
Reporter: Steve Rowe
Assignee: Shai Erera
Reproduces 100% for me on trunk and on branch_4x - below is from branch_4x:
{noformat}
[junit4] Suite:
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestDirectoryTaxonomyReader -Dtests.method=testGetChildren
-Dtests.seed=B94C5192B4851C12 -Dtests.slow=true -Dtests.locale=es_UY
-Dtests.timezone=America/Santa_Isabel -Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.48s | TestDirectoryTaxonomyReader.testGetChildren
[junit4] Throwable #1: java.lang.NullPointerException
[junit4] at
__randomizedtesting.SeedInfo.seed([B94C5192B4851C12:D5BAEB4F58AE9D94]:0)
[junit4] at
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren(TestDirectoryTaxonomyReader.java:508)
[junit4] at java.lang.Thread.run(Thread.java:724)
[junit4] 2 NOTE: test params are: codec=Lucene40,
sim=RandomSimilarityProvider(queryNorm=false,coord=crazy): {}, locale=es_UY,
timezone=America/Santa_Isabel
[junit4] 2 NOTE: Mac OS X 10.8.5 x86_64/Oracle Corporation 1.7.0_25
(64-bit)/cpus=8,threads=1,free=83697144,total=119537664
[junit4] 2 NOTE: All tests run in this JVM:
[TestDirectoryTaxonomyReader]
[junit4] Completed in 1.06s, 1 test, 1 error FAILURES!
[junit4]
[junit4]
[junit4] Tests with failures:
[junit4] -
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5342) In some places, when a caught exception is re-thrown, the original exception is not included
[ https://issues.apache.org/jira/browse/SOLR-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-5342: --- Attachment: SOLR-5342.patch New patch. I went a little nuts and did lucene as well, so this issue (and the CHANGES mod) might need to move to lucene. Questionable changes, due to verbosity of output: org.apache.lucene.benchmark.byTask.feedsTrecContentSource#openNextFile org.apache.lucene.demo.IndexFiles#main various places in org.apache.solr.util.SimplePostTool Places where I wasn't sure what change to make or whether any change was needed: org.apache.lucene.index.TestDirectoryReaderReopen, line 322 org.apache.solr.cloud.OverSeerCollectionProcessor, line 1141 org.apache.solr.handler.TestReplicationHandler, lines 1330, 1370 org.apache.solr.servlet.ResponseUtils, line 47 Other stuff noticed along the way: Dead code: org.apache.lucene.index.TestTransactions, line 197 In some places, when a caught exception is re-thrown, the original exception is not included Key: SOLR-5342 URL: https://issues.apache.org/jira/browse/SOLR-5342 Project: Solr Issue Type: Improvement Affects Versions: 4.5 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.5.1, 4.6, 5.0 Attachments: SOLR-5342.patch, SOLR-5342.patch ShardHandlerFactory#newInstance catches exceptions and rethrows them. It was including the message from the caught exception, but not including the actual exception. This made it difficult to figure out the root cause for an SSL initialization error. While fixing this, I discovered other places that are missing this as well. Some of them I elected not to fix, either because it's catching IOException (which normally provides good messages), or because it was in a location that might get called frequently, which would greatly increase logging output. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5281) NPE: TestDirectoryTaxonomyReader.testGetChildren
[
https://issues.apache.org/jira/browse/LUCENE-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera resolved LUCENE-5281.
Resolution: Fixed
Fix Version/s: 5.0
4.6
Committed to trunk and 4x (but forgot to reference the issue in the commit
message).
NPE: TestDirectoryTaxonomyReader.testGetChildren
Key: LUCENE-5281
URL: https://issues.apache.org/jira/browse/LUCENE-5281
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Affects Versions: 4.5, 5.0
Reporter: Steve Rowe
Assignee: Shai Erera
Fix For: 4.6, 5.0
Reproduces 100% for me on trunk and on branch_4x - below is from branch_4x:
{noformat}
[junit4] Suite:
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestDirectoryTaxonomyReader -Dtests.method=testGetChildren
-Dtests.seed=B94C5192B4851C12 -Dtests.slow=true -Dtests.locale=es_UY
-Dtests.timezone=America/Santa_Isabel -Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.48s | TestDirectoryTaxonomyReader.testGetChildren
[junit4] Throwable #1: java.lang.NullPointerException
[junit4] at
__randomizedtesting.SeedInfo.seed([B94C5192B4851C12:D5BAEB4F58AE9D94]:0)
[junit4] at
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren(TestDirectoryTaxonomyReader.java:508)
[junit4] at java.lang.Thread.run(Thread.java:724)
[junit4] 2 NOTE: test params are: codec=Lucene40,
sim=RandomSimilarityProvider(queryNorm=false,coord=crazy): {}, locale=es_UY,
timezone=America/Santa_Isabel
[junit4] 2 NOTE: Mac OS X 10.8.5 x86_64/Oracle Corporation 1.7.0_25
(64-bit)/cpus=8,threads=1,free=83697144,total=119537664
[junit4] 2 NOTE: All tests run in this JVM:
[TestDirectoryTaxonomyReader]
[junit4] Completed in 1.06s, 1 test, 1 error FAILURES!
[junit4]
[junit4]
[junit4] Tests with failures:
[junit4] -
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5341) Output version number in logs
[ https://issues.apache.org/jira/browse/SOLR-5341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793715#comment-13793715 ] Shawn Heisey commented on SOLR-5341: There might also be other locations where catastrophic or unusual things happen which could benefit from having the version printed, for instances where a partial log is submitted for review. I wouldn't want to have the version printed extremely often during normal operation, though. If anyone can think of places that meet this criteria, please let me know. Output version number in logs - Key: SOLR-5341 URL: https://issues.apache.org/jira/browse/SOLR-5341 Project: Solr Issue Type: Improvement Affects Versions: 4.5 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 4.6, 5.0 It would be exceptionally useful from a tech support perspective if the version number were placed in the log during startup. I'm inclined to make this a WARN log, but if the consensus is to have it at INFO, then I can go that direction. It might also be useful to have any shutdown hooks in Solr log the version as well. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5281) NPE: TestDirectoryTaxonomyReader.testGetChildren
[
https://issues.apache.org/jira/browse/LUCENE-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793716#comment-13793716
]
ASF subversion and git services commented on LUCENE-5281:
-
Commit 1531716 from [~shaie] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1531716 ]
LUCENE-5281: commit prop changes
NPE: TestDirectoryTaxonomyReader.testGetChildren
Key: LUCENE-5281
URL: https://issues.apache.org/jira/browse/LUCENE-5281
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Affects Versions: 4.5, 5.0
Reporter: Steve Rowe
Assignee: Shai Erera
Fix For: 4.6, 5.0
Reproduces 100% for me on trunk and on branch_4x - below is from branch_4x:
{noformat}
[junit4] Suite:
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestDirectoryTaxonomyReader -Dtests.method=testGetChildren
-Dtests.seed=B94C5192B4851C12 -Dtests.slow=true -Dtests.locale=es_UY
-Dtests.timezone=America/Santa_Isabel -Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.48s | TestDirectoryTaxonomyReader.testGetChildren
[junit4] Throwable #1: java.lang.NullPointerException
[junit4] at
__randomizedtesting.SeedInfo.seed([B94C5192B4851C12:D5BAEB4F58AE9D94]:0)
[junit4] at
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren(TestDirectoryTaxonomyReader.java:508)
[junit4] at java.lang.Thread.run(Thread.java:724)
[junit4] 2 NOTE: test params are: codec=Lucene40,
sim=RandomSimilarityProvider(queryNorm=false,coord=crazy): {}, locale=es_UY,
timezone=America/Santa_Isabel
[junit4] 2 NOTE: Mac OS X 10.8.5 x86_64/Oracle Corporation 1.7.0_25
(64-bit)/cpus=8,threads=1,free=83697144,total=119537664
[junit4] 2 NOTE: All tests run in this JVM:
[TestDirectoryTaxonomyReader]
[junit4] Completed in 1.06s, 1 test, 1 error FAILURES!
[junit4]
[junit4]
[junit4] Tests with failures:
[junit4] -
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyReader.testGetChildren
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5277) Stamp core names on log entries for certain classes
[
https://issues.apache.org/jira/browse/SOLR-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey updated SOLR-5277:
---
Attachment: SOLR-5277.patch
Initial exploratory foray into using MDC. This doesn't include changes to
log4j.properties. I sitll need to put this on my dev server and try it out.
Stamp core names on log entries for certain classes
---
Key: SOLR-5277
URL: https://issues.apache.org/jira/browse/SOLR-5277
Project: Solr
Issue Type: Bug
Components: search, update
Affects Versions: 4.3.1, 4.4, 4.5
Reporter: Dmitry Kan
Attachments: SOLR-5277.patch, SOLR-5277.patch
It is handy that certain Java classes stamp a [coreName] on a log entry. It
would be useful for multicore setup if more classes would stamp this
information.
In particular we came accross a situaion with commits coming in a quick
succession to the same multicore shard and found it to be hard time figuring
out was it the same core or different cores.
The classes in question with log sample output:
o.a.s.c.SolrCore
06:57:53.577 [qtp1640764503-13617] INFO org.apache.solr.core.SolrCore -
SolrDeletionPolicy.onCommit: commits:num=2
11:53:19.056 [coreLoadExecutor-3-thread-1] INFO
org.apache.solr.core.SolrCore - Soft AutoCommit: if uncommited for 1000ms;
o.a.s.u.UpdateHandler
14:45:24.447 [commitScheduler-9-thread-1] INFO
org.apache.solr.update.UpdateHandler - start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
06:57:53.591 [qtp1640764503-13617] INFO org.apache.solr.update.UpdateHandler
- end_commit_flush
o.a.s.s.SolrIndexSearcher
14:45:24.553 [commitScheduler-7-thread-1] INFO
org.apache.solr.search.SolrIndexSearcher - Opening Searcher@1067e5a9 main
The original question was posted on #solr and on SO:
http://stackoverflow.com/questions/19026577/how-to-output-solr-core-name-with-log4j
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4327) SolrJ code review indicates potential for leaked HttpClient connections
[
https://issues.apache.org/jira/browse/SOLR-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793721#comment-13793721
]
Oleg Kalnichevski commented on SOLR-4327:
-
This is none of my business, but I think and catching and ignoring Throwables
is an _exceptionally_ bad idea
{code}
try {
respBody.close();
} catch (Throwable t) {} // ignore
{code}
At the very least it should be
{code}
try {
respBody.close();
} catch (Exception ignore) {}
{code}
SolrJ code review indicates potential for leaked HttpClient connections
---
Key: SOLR-4327
URL: https://issues.apache.org/jira/browse/SOLR-4327
Project: Solr
Issue Type: Bug
Affects Versions: 4.0
Reporter: Karl Wright
Assignee: Mark Miller
Fix For: 4.5.1, 4.6, 5.0
Attachments: SOLR-4327.patch, SOLR-4327.patch
The SolrJ HttpSolrServer implementation does not seem to handle errors
properly and seems capable of leaking HttpClient connections. See the
request() method in org.apache.solr.client.solrj.impl.HttpSolrServer. The
issue is that exceptions thrown from within this method do not necessarily
consume the stream when an exception is thrown. There is a try/finally block
which reads (in part):
{code}
} finally {
if (respBody != null processor!=null) {
try {
respBody.close();
} catch (Throwable t) {} // ignore
}
}
{code}
But, in order to always guarantee consumption of the stream, it should
include:
{code}
method.abort();
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Build failed in Jenkins: 4.5.1-solr-test-core-loop #18
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/18/ -- [...truncated 12030 lines...] [junit4] Completed on J0 in 0.69s, 1 test [junit4] [junit4] Suite: org.apache.solr.handler.BinaryUpdateRequestHandlerTest [junit4] Completed on J2 in 0.66s, 1 test [junit4] [junit4] Suite: org.apache.solr.highlight.FastVectorHighlighterTest [junit4] Completed on J1 in 0.74s, 2 tests [junit4] [junit4] Suite: org.apache.solr.search.TestQueryTypes [junit4] Completed on J3 in 0.72s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.CopyFieldTest [junit4] Completed on J2 in 0.65s, 9 tests [junit4] [junit4] Suite: org.apache.solr.handler.CSVRequestHandlerTest [junit4] Completed on J0 in 0.75s, 1 test [junit4] [junit4] Suite: org.apache.solr.update.UpdateParamsTest [junit4] Completed on J1 in 0.68s, 1 test [junit4] [junit4] Suite: org.apache.solr.search.ReturnFieldsTest [junit4] Completed on J3 in 0.75s, 12 tests [junit4] [junit4] Suite: org.apache.solr.core.AlternateDirectoryTest [junit4] Completed on J2 in 0.56s, 2 tests [junit4] [junit4] Suite: org.apache.solr.response.TestCSVResponseWriter [junit4] Completed on J0 in 0.64s, 2 tests [junit4] [junit4] Suite: org.apache.solr.update.processor.UniqFieldsUpdateProcessorFactoryTest [junit4] Completed on J1 in 0.61s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.IndexSchemaTest [junit4] Completed on J3 in 0.67s, 3 tests [junit4] [junit4] Suite: org.apache.solr.request.TestBinaryResponseWriter [junit4] Completed on J2 in 0.61s, 2 tests [junit4] [junit4] Suite: org.apache.solr.update.processor.DefaultValueUpdateProcessorTest [junit4] Completed on J1 in 0.50s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.TestOmitPositions [junit4] Completed on J0 in 0.68s, 2 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestCopyFieldCollectionResource [junit4] Completed on J3 in 0.53s, 5 tests [junit4] [junit4] Suite: org.apache.solr.update.processor.UpdateRequestProcessorFactoryTest [junit4] Completed on J2 in 0.67s, 2 tests [junit4] [junit4] Suite: org.apache.solr.highlight.HighlighterConfigTest [junit4] Completed on J1 in 0.65s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestDynamicFieldCollectionResource [junit4] Completed on J3 in 0.49s, 5 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestDynamicFieldResource [junit4] Completed on J1 in 0.48s, 3 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSolrQueryParserDefaultOperatorResource [junit4] Completed on J2 in 0.55s, 1 test [junit4] [junit4] Suite: org.apache.solr.search.TestComponentsName [junit4] Completed on J3 in 0.56s, 1 test [junit4] [junit4] Suite: org.apache.solr.servlet.NoCacheHeaderTest [junit4] Completed on J0 in 1.52s, 3 tests [junit4] [junit4] Suite: org.apache.solr.core.TestQuerySenderListener [junit4] Completed on J1 in 0.54s, 3 tests [junit4] [junit4] Suite: org.apache.solr.search.TestLFUCache [junit4] Completed on J2 in 0.79s, 5 tests [junit4] [junit4] Suite: org.apache.solr.core.TestConfig [junit4] Completed on J1 in 0.48s, 7 tests [junit4] [junit4] Suite: org.apache.solr.core.TestQuerySenderNoQuery [junit4] Completed on J3 in 0.61s, 3 tests [junit4] [junit4] Suite: org.apache.solr.core.SOLR749Test [junit4] Completed on J0 in 0.55s, 1 test [junit4] [junit4] Suite: org.apache.solr.search.TestElisionMultitermQuery [junit4] Completed on J0 in 0.33s, 1 test [junit4] [junit4] Suite: org.apache.solr.highlight.TestPostingsSolrHighlighter [junit4] Completed on J2 in 0.55s, 12 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSchemaSimilarityResource [junit4] Completed on J1 in 0.71s, 1 test [junit4] [junit4] Suite: org.apache.solr.spelling.suggest.TestAnalyzedSuggestions [junit4] Completed on J3 in 0.52s, 2 tests [junit4] [junit4] Suite: org.apache.solr.MinimalSchemaTest [junit4] Completed on J0 in 0.42s, 3 tests [junit4] [junit4] Suite: org.apache.solr.schema.TestCollationField [junit4] Completed on J2 in 0.39s, 8 tests [junit4] [junit4] Suite: org.apache.solr.schema.TestBinaryField [junit4] Completed on J1 in 0.27s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.NumericFieldsTest [junit4] Completed on J3 in 0.33s, 1 test [junit4] [junit4] Suite: org.apache.solr.spelling.suggest.TestFuzzyAnalyzedSuggestions [junit4] Completed on J2 in 0.24s, 4 tests [junit4] [junit4] Suite: org.apache.solr.schema.BadCopyFieldTest [junit4] Completed on J3 in 0.25s, 5 tests [junit4] [junit4] Suite: org.apache.solr.SampleTest [junit4] Completed on J0 in 0.37s, 2 tests [junit4] [junit4] Suite:
Jenkins build is back to normal : 4.5.1-solr-test-core-loop #19
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/19/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions
[ https://issues.apache.org/jira/browse/LUCENE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793732#comment-13793732 ] ASF subversion and git services commented on LUCENE-5273: - Commit 1531724 from [~steve_rowe] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1531724 ] LUCENE-5273: Only unpack Lucene/Solr jars/war from binary distributions - other stuff not needed (merged trunk r1531711) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions - Key: LUCENE-5273 URL: https://issues.apache.org/jira/browse/LUCENE-5273 Project: Lucene - Core Issue Type: Bug Components: general/build Reporter: Steve Rowe Assignee: Steve Rowe Fix For: 4.6, 5.0 Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we release multiple versions of the same artifact: binary Maven artifacts are not identical to the ones in the Lucene and Solr binary distributions, and the Lucene jars in the Solr binary distribution, including within the war, are not identical to the ones in the Lucene binary distribution. This is bad. It's (probably always?) not horribly bad, since the differences all appear to be caused by the build re-creating manifests and re-building jars and the Solr war from their constituents at various points in the release build process; as a result, manifest timestamp attributes, as well as archive metadata (at least constituent timestamps, maybe other things?), differ each time a jar is rebuilt. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions
[
https://issues.apache.org/jira/browse/LUCENE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793734#comment-13793734
]
Steve Rowe commented on LUCENE-5273:
{quote}
I am not sure of the overhead, but as the binary artifact also contains
javadocs and those are many small files, this makes the task run slowly on
windows and some filesystems. How about only extracting JAR files on the untar
task? I would only add some patternset matching only **/*.jar to the untar task
(see last example on http://ant.apache.org/manual/Tasks/unzip.html).
[...]
Steve Rowe: I am out of office, you can commit this patch and also backport if
you like!
{quote}
Thanks Uwe, I committed (with one small change to the patternset name) to trunk
and branch_4x. I added the Solr war to the patternset-to-unpack on branch_4x.
{{ant nightly-smoke}} passed for me in both places.
Binary artifacts in Lucene and Solr convenience binary distributions
accompanying a release, including on Maven Central, should be identical
across all distributions
-
Key: LUCENE-5273
URL: https://issues.apache.org/jira/browse/LUCENE-5273
Project: Lucene - Core
Issue Type: Bug
Components: general/build
Reporter: Steve Rowe
Assignee: Steve Rowe
Fix For: 4.6, 5.0
Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch
As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we
release multiple versions of the same artifact: binary Maven artifacts are
not identical to the ones in the Lucene and Solr binary distributions, and
the Lucene jars in the Solr binary distribution, including within the war,
are not identical to the ones in the Lucene binary distribution. This is bad.
It's (probably always?) not horribly bad, since the differences all appear to
be caused by the build re-creating manifests and re-building jars and the
Solr war from their constituents at various points in the release build
process; as a result, manifest timestamp attributes, as well as archive
metadata (at least constituent timestamps, maybe other things?), differ each
time a jar is rebuilt.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Build failed in Jenkins: 4.5.1-solr-test-core-loop #20
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/20/ -- [...truncated 11734 lines...] [junit4] Completed on J2 in 0.69s, 1 test [junit4] [junit4] Suite: org.apache.solr.response.TestCSVResponseWriter [junit4] Completed on J1 in 0.65s, 2 tests [junit4] [junit4] Suite: org.apache.solr.schema.CopyFieldTest [junit4] Completed on J0 in 0.61s, 9 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestFieldCollectionResource [junit4] Completed on J3 in 0.57s, 7 tests [junit4] [junit4] Suite: org.apache.solr.request.TestBinaryResponseWriter [junit4] Completed on J2 in 0.66s, 2 tests [junit4] [junit4] Suite: org.apache.solr.schema.TestOmitPositions [junit4] Completed on J1 in 0.74s, 2 tests [junit4] [junit4] Suite: org.apache.solr.handler.component.SearchHandlerTest [junit4] Completed on J0 in 0.82s, 1 test [junit4] [junit4] Suite: org.apache.solr.search.TestSurroundQueryParser [junit4] Completed on J3 in 0.92s, 1 test [junit4] [junit4] Suite: org.apache.solr.update.processor.UniqFieldsUpdateProcessorFactoryTest [junit4] Completed on J1 in 0.75s, 1 test [junit4] [junit4] Suite: org.apache.solr.update.processor.PreAnalyzedUpdateProcessorTest [junit4] Completed on J2 in 0.99s, 2 tests [junit4] [junit4] Suite: org.apache.solr.core.TestCoreDiscovery [junit4] Completed on J0 in 0.87s, 4 tests [junit4] [junit4] Suite: org.apache.solr.update.processor.DefaultValueUpdateProcessorTest [junit4] Completed on J3 in 0.98s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestFieldResource [junit4] Completed on J1 in 0.82s, 7 tests [junit4] [junit4] Suite: org.apache.solr.schema.RequiredFieldsTest [junit4] Completed on J2 in 0.78s, 3 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestFieldTypeCollectionResource [junit4] Completed on J3 in 0.70s, 2 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSchemaVersionResource [junit4] Completed on J0 in 0.84s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSolrQueryParserDefaultOperatorResource [junit4] Completed on J2 in 0.68s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestDynamicFieldCollectionResource [junit4] Completed on J1 in 0.78s, 5 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestDynamicFieldResource [junit4] Completed on J3 in 0.81s, 3 tests [junit4] [junit4] Suite: org.apache.solr.handler.component.ResponseLogComponentTest [junit4] Completed on J2 in 0.70s, 3 tests [junit4] [junit4] Suite: org.apache.solr.search.TestLFUCache [junit4] Completed on J0 in 0.76s, 5 tests [junit4] [junit4] Suite: org.apache.solr.search.TestComponentsName [junit4] Completed on J1 in 0.73s, 1 test [junit4] [junit4] Suite: org.apache.solr.core.TestQuerySenderListener [junit4] Completed on J3 in 0.59s, 3 tests [junit4] [junit4] Suite: org.apache.solr.core.TestQuerySenderNoQuery [junit4] Completed on J2 in 0.59s, 3 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestUniqueKeyFieldResource [junit4] Completed on J0 in 0.58s, 1 test [junit4] [junit4] Suite: org.apache.solr.handler.component.BadComponentTest [junit4] Completed on J1 in 0.52s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSolrQueryParserResource [junit4] Completed on J2 in 0.44s, 1 test [junit4] [junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy2 [junit4] Completed on J3 in 0.52s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.PrimitiveFieldTypeTest [junit4] Completed on J1 in 0.46s, 1 test [junit4] [junit4] Suite: org.apache.solr.TestSolrCoreProperties [junit4] Completed on J2 in 0.19s, 1 test [junit4] [junit4] Suite: org.apache.solr.core.TestConfig [junit4] Completed on J0 in 0.52s, 7 tests [junit4] [junit4] Suite: org.apache.solr.MinimalSchemaTest [junit4] Completed on J3 in 0.34s, 3 tests [junit4] [junit4] Suite: org.apache.solr.search.TestElisionMultitermQuery [junit4] Completed on J1 in 0.34s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.MultiTermTest [junit4] Completed on J2 in 0.34s, 3 tests [junit4] [junit4] Suite: org.apache.solr.schema.NumericFieldsTest [junit4] Completed on J0 in 0.34s, 1 test [junit4] [junit4] Suite: org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest [junit4] Completed on J3 in 0.30s, 3 tests [junit4] [junit4] Suite: org.apache.solr.internal.csv.CSVPrinterTest [junit4] Completed on J2 in 0.38s, 6 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSerializedLuceneMatchVersion [junit4] Completed on J1 in 0.35s, 2 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestClassNameShortening [junit4]
Build failed in Jenkins: 4.5.1-solr-test-core-loop #21
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/21/ -- [...truncated 7447 lines...] [junit4] [junit4] Suite: org.apache.solr.schema.PreAnalyzedFieldTest [junit4] Completed on J0 in 0.70s, 3 tests [junit4] [junit4] Suite: org.apache.solr.search.QueryParsingTest [junit4] Completed on J3 in 0.93s, 4 tests [junit4] [junit4] Suite: org.apache.solr.handler.component.DebugComponentTest [junit4] Completed on J1 in 0.88s, 2 tests [junit4] [junit4] Suite: org.apache.solr.response.TestPHPSerializedResponseWriter [junit4] Completed on J0 in 0.72s, 2 tests [junit4] [junit4] Suite: org.apache.solr.update.TestIndexingPerformance [junit4] Completed on J2 in 0.79s, 1 test [junit4] [junit4] Suite: org.apache.solr.search.ReturnFieldsTest [junit4] Completed on J3 in 0.87s, 12 tests [junit4] [junit4] Suite: org.apache.solr.response.TestCSVResponseWriter [junit4] Completed on J1 in 0.71s, 2 tests [junit4] [junit4] Suite: org.apache.solr.schema.IndexSchemaTest [junit4] Completed on J0 in 0.73s, 3 tests [junit4] [junit4] Suite: org.apache.solr.update.processor.RegexBoostProcessorTest [junit4] Completed on J2 in 0.69s, 4 tests [junit4] [junit4] Suite: org.apache.solr.schema.TestOmitPositions [junit4] Completed on J0 in 0.97s, 2 tests [junit4] [junit4] Suite: org.apache.solr.update.UpdateParamsTest [junit4] Completed on J3 in 1.14s, 1 test [junit4] [junit4] Suite: org.apache.solr.handler.component.SearchHandlerTest [junit4] Completed on J2 in 0.85s, 1 test [junit4] [junit4] Suite: org.apache.solr.handler.BinaryUpdateRequestHandlerTest [junit4] Completed on J1 in 1.02s, 1 test [junit4] [junit4] Suite: org.apache.solr.request.TestBinaryResponseWriter [junit4] Completed on J0 in 0.64s, 2 tests [junit4] [junit4] Suite: org.apache.solr.handler.admin.CoreMergeIndexesAdminHandlerTest [junit4] Completed on J3 in 0.66s, 1 test [junit4] [junit4] Suite: org.apache.solr.core.AlternateDirectoryTest [junit4] Completed on J2 in 0.58s, 2 tests [junit4] [junit4] Suite: org.apache.solr.handler.admin.InfoHandlerTest [junit4] Completed on J1 in 0.62s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSolrQueryParserDefaultOperatorResource [junit4] Completed on J1 in 0.48s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSchemaVersionResource [junit4] Completed on J3 in 0.57s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestFieldTypeCollectionResource [junit4] Completed on J2 in 0.59s, 2 tests [junit4] [junit4] Suite: org.apache.solr.update.processor.UpdateRequestProcessorFactoryTest [junit4] Completed on J0 in 0.79s, 2 tests [junit4] [junit4] Suite: org.apache.solr.servlet.NoCacheHeaderTest [junit4] Completed on J1 in 0.57s, 3 tests [junit4] [junit4] Suite: org.apache.solr.handler.component.ResponseLogComponentTest [junit4] Completed on J0 in 0.49s, 3 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestDynamicFieldResource [junit4] Completed on J3 in 0.53s, 3 tests [junit4] [junit4] Suite: org.apache.solr.search.TestLFUCache [junit4] Completed on J2 in 0.55s, 5 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestUniqueKeyFieldResource [junit4] Completed on J0 in 0.49s, 1 test [junit4] [junit4] Suite: org.apache.solr.core.TestInfoStreamLogging [junit4] Completed on J1 in 0.55s, 1 test [junit4] [junit4] Suite: org.apache.solr.core.SOLR749Test [junit4] Completed on J3 in 0.60s, 1 test [junit4] [junit4] Suite: org.apache.solr.analysis.TestReversedWildcardFilterFactory [junit4] Completed on J2 in 0.59s, 4 tests [junit4] [junit4] Suite: org.apache.solr.highlight.TestPostingsSolrHighlighter [junit4] Completed on J1 in 0.49s, 12 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSolrQueryParserResource [junit4] Completed on J0 in 0.56s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSchemaSimilarityResource [junit4] Completed on J3 in 0.46s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.PrimitiveFieldTypeTest [junit4] Completed on J2 in 0.43s, 1 test [junit4] [junit4] Suite: org.apache.solr.spelling.suggest.TestAnalyzedSuggestions [junit4] Completed on J1 in 0.40s, 2 tests [junit4] [junit4] Suite: org.apache.solr.search.TestSearchPerf [junit4] Completed on J0 in 0.45s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.TestCollationField [junit4] Completed on J3 in 0.36s, 8 tests [junit4] [junit4] Suite: org.apache.solr.schema.MultiTermTest [junit4] Completed on J2 in 0.37s, 3 tests [junit4] [junit4] Suite: org.apache.solr.schema.NumericFieldsTest [junit4] Completed on J1 in 0.31s, 1 test [junit4] [junit4]
Jenkins build is back to normal : 4.5.1-solr-test-core-loop #22
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/22/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5343) TestReplicationHandler.doTestStressReplication fails ~ 33% of the time
Robert Muir created SOLR-5343: - Summary: TestReplicationHandler.doTestStressReplication fails ~ 33% of the time Key: SOLR-5343 URL: https://issues.apache.org/jira/browse/SOLR-5343 Project: Solr Issue Type: Bug Reporter: Robert Muir This test fails ~ 1/3 of the time in every jenkins, locally on my machine, etc. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5343) TestReplicationHandler.doTestStressReplication fails ~ 33% of the time
[ https://issues.apache.org/jira/browse/SOLR-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-5343: -- Fix Version/s: 4.5.1 TestReplicationHandler.doTestStressReplication fails ~ 33% of the time -- Key: SOLR-5343 URL: https://issues.apache.org/jira/browse/SOLR-5343 Project: Solr Issue Type: Bug Reporter: Robert Muir Fix For: 4.5.1 This test fails ~ 1/3 of the time in every jenkins, locally on my machine, etc. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5343) TestReplicationHandler.doTestStressReplication fails ~ 33% of the time
[ https://issues.apache.org/jira/browse/SOLR-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793757#comment-13793757 ] ASF subversion and git services commented on SOLR-5343: --- Commit 1531732 from [~rcmuir] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1531732 ] SOLR-5343: disable unreliable test method (fails more than 1/3 of the time) TestReplicationHandler.doTestStressReplication fails ~ 33% of the time -- Key: SOLR-5343 URL: https://issues.apache.org/jira/browse/SOLR-5343 Project: Solr Issue Type: Bug Reporter: Robert Muir Fix For: 4.5.1 This test fails ~ 1/3 of the time in every jenkins, locally on my machine, etc. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5343) TestReplicationHandler.doTestStressReplication fails ~ 33% of the time
[ https://issues.apache.org/jira/browse/SOLR-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793758#comment-13793758 ] ASF subversion and git services commented on SOLR-5343: --- Commit 1531733 from [~rcmuir] in branch 'dev/branches/lucene_solr_4_5' [ https://svn.apache.org/r1531733 ] SOLR-5343: disable unreliable test method (fails more than 1/3 of the time) TestReplicationHandler.doTestStressReplication fails ~ 33% of the time -- Key: SOLR-5343 URL: https://issues.apache.org/jira/browse/SOLR-5343 Project: Solr Issue Type: Bug Reporter: Robert Muir Fix For: 4.5.1 This test fails ~ 1/3 of the time in every jenkins, locally on my machine, etc. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5343) TestReplicationHandler.doTestStressReplication fails ~ 33% of the time
[ https://issues.apache.org/jira/browse/SOLR-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793756#comment-13793756 ] ASF subversion and git services commented on SOLR-5343: --- Commit 1531731 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1531731 ] SOLR-5343: disable unreliable test method (fails more than 1/3 of the time) TestReplicationHandler.doTestStressReplication fails ~ 33% of the time -- Key: SOLR-5343 URL: https://issues.apache.org/jira/browse/SOLR-5343 Project: Solr Issue Type: Bug Reporter: Robert Muir Fix For: 4.5.1 This test fails ~ 1/3 of the time in every jenkins, locally on my machine, etc. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5344) SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to time
Robert Muir created SOLR-5344: - Summary: SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to time Key: SOLR-5344 URL: https://issues.apache.org/jira/browse/SOLR-5344 Project: Solr Issue Type: Bug Reporter: Robert Muir Doesn't happen very often, but maybe one I can fix. I'll look into it. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b106) - Build # 7872 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/7872/ Java: 64bit/jdk1.8.0-ea-b106 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterDelete.testNoLostDeletesOrUpdatesOnIOException Error Message: _l.fnm in dir=org.apache.lucene.store.RAMDirectory@16706731 lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@4fe13ade Stack Trace: java.io.FileNotFoundException: _l.fnm in dir=org.apache.lucene.store.RAMDirectory@16706731 lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@4fe13ade at __randomizedtesting.SeedInfo.seed([4B1A4BEDD58638FB:2823537CA70B2F36]:0) at org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:530) at org.apache.lucene.codecs.lucene46.Lucene46FieldInfosReader.read(Lucene46FieldInfosReader.java:52) at org.apache.lucene.index.SegmentReader.readFieldInfos(SegmentReader.java:251) at org.apache.lucene.index.SegmentReader.init(SegmentReader.java:106) at org.apache.lucene.index.ReadersAndLiveDocs.writeLiveDocs(ReadersAndLiveDocs.java:367) at org.apache.lucene.index.IndexWriter$ReaderPool.dropAll(IndexWriter.java:497) at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1038) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:933) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:895) at org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.java:333) at org.apache.lucene.index.TestIndexWriterDelete.testNoLostDeletesOrUpdatesOnIOException(TestIndexWriterDelete.java:1363) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:491) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at
Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b106) - Build # 7872 - Failure!
I'll dig. Mike McCandless http://blog.mikemccandless.com On Sun, Oct 13, 2013 at 3:25 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/7872/ Java: 64bit/jdk1.8.0-ea-b106 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterDelete.testNoLostDeletesOrUpdatesOnIOException Error Message: _l.fnm in dir=org.apache.lucene.store.RAMDirectory@16706731 lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@4fe13ade Stack Trace: java.io.FileNotFoundException: _l.fnm in dir=org.apache.lucene.store.RAMDirectory@16706731 lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@4fe13ade at __randomizedtesting.SeedInfo.seed([4B1A4BEDD58638FB:2823537CA70B2F36]:0) at org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:530) at org.apache.lucene.codecs.lucene46.Lucene46FieldInfosReader.read(Lucene46FieldInfosReader.java:52) at org.apache.lucene.index.SegmentReader.readFieldInfos(SegmentReader.java:251) at org.apache.lucene.index.SegmentReader.init(SegmentReader.java:106) at org.apache.lucene.index.ReadersAndLiveDocs.writeLiveDocs(ReadersAndLiveDocs.java:367) at org.apache.lucene.index.IndexWriter$ReaderPool.dropAll(IndexWriter.java:497) at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1038) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:933) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:895) at org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.java:333) at org.apache.lucene.index.TestIndexWriterDelete.testNoLostDeletesOrUpdatesOnIOException(TestIndexWriterDelete.java:1363) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:491) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
Build failed in Jenkins: 4.5.1-solr-test-core-loop #29
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/29/ -- [...truncated 794989 lines...] [junit4] [junit4] Suite: org.apache.solr.search.TestValueSourceCache [junit4] Completed on J3 in 0.78s, 2 tests [junit4] [junit4] Suite: org.apache.solr.search.TestSurroundQueryParser [junit4] Completed on J2 in 0.67s, 1 test [junit4] [junit4] Suite: org.apache.solr.update.UpdateParamsTest [junit4] Completed on J0 in 0.64s, 1 test [junit4] [junit4] Suite: org.apache.solr.response.TestPHPSerializedResponseWriter [junit4] Completed on J1 in 0.62s, 2 tests [junit4] [junit4] Suite: org.apache.solr.core.TestArbitraryIndexDir [junit4] Completed on J2 in 0.68s, 1 test [junit4] [junit4] Suite: org.apache.solr.highlight.FastVectorHighlighterTest [junit4] Completed on J3 in 0.78s, 2 tests [junit4] [junit4] Suite: org.apache.solr.search.TestQueryTypes [junit4] Completed on J1 in 0.68s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.IndexSchemaRuntimeFieldTest [junit4] Completed on J0 in 0.76s, 1 test [junit4] [junit4] Suite: org.apache.solr.handler.admin.InfoHandlerTest [junit4] Completed on J2 in 0.79s, 1 test [junit4] [junit4] Suite: org.apache.solr.response.TestCSVResponseWriter [junit4] Completed on J3 in 0.76s, 2 tests [junit4] [junit4] Suite: org.apache.solr.update.processor.RegexBoostProcessorTest [junit4] Completed on J1 in 0.95s, 4 tests [junit4] [junit4] Suite: org.apache.solr.handler.component.SearchHandlerTest [junit4] Completed on J0 in 0.86s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestFieldTypeResource [junit4] Completed on J3 in 0.73s, 4 tests [junit4] [junit4] Suite: org.apache.solr.schema.RequiredFieldsTest [junit4] Completed on J2 in 0.80s, 3 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestDynamicFieldResource [junit4] Completed on J0 in 0.66s, 3 tests [junit4] [junit4] Suite: org.apache.solr.handler.BinaryUpdateRequestHandlerTest [junit4] Completed on J1 in 0.85s, 1 test [junit4] [junit4] Suite: org.apache.solr.update.processor.DefaultValueUpdateProcessorTest [junit4] Completed on J3 in 0.67s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestFieldResource [junit4] Completed on J2 in 0.68s, 7 tests [junit4] [junit4] Suite: org.apache.solr.core.TestSolrIndexConfig [junit4] Completed on J0 in 0.61s, 2 tests [junit4] [junit4] Suite: org.apache.solr.search.TestLFUCache [junit4] Completed on J2 in 0.55s, 5 tests [junit4] [junit4] Suite: org.apache.solr.analysis.TestReversedWildcardFilterFactory [junit4] Completed on J3 in 0.80s, 4 tests [junit4] [junit4] Suite: org.apache.solr.highlight.HighlighterConfigTest [junit4] Completed on J0 in 0.61s, 1 test [junit4] [junit4] Suite: org.apache.solr.servlet.NoCacheHeaderTest [junit4] Completed on J1 in 1.59s, 3 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSchemaVersionResource [junit4] Completed on J2 in 0.54s, 1 test [junit4] [junit4] Suite: org.apache.solr.core.SOLR749Test [junit4] Completed on J0 in 0.49s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestUniqueKeyFieldResource [junit4] Completed on J3 in 0.59s, 1 test [junit4] [junit4] Suite: org.apache.solr.update.SolrIndexConfigTest [junit4] Completed on J1 in 0.52s, 3 tests [junit4] [junit4] Suite: org.apache.solr.update.processor.TestPartialUpdateDeduplication [junit4] Completed on J0 in 0.49s, 1 test [junit4] [junit4] Suite: org.apache.solr.highlight.TestPostingsSolrHighlighter [junit4] Completed on J3 in 0.46s, 12 tests [junit4] [junit4] Suite: org.apache.solr.spelling.suggest.TestAnalyzedSuggestions [junit4] Completed on J0 in 0.49s, 2 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSchemaSimilarityResource [junit4] Completed on J2 in 1.41s, 1 test [junit4] [junit4] Suite: org.apache.solr.search.TestSearchPerf [junit4] Completed on J1 in 0.89s, 1 test [junit4] [junit4] Suite: org.apache.solr.MinimalSchemaTest [junit4] Completed on J3 in 0.72s, 3 tests [junit4] [junit4] Suite: org.apache.solr.search.TestElisionMultitermQuery [junit4] Completed on J0 in 0.30s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSerializedLuceneMatchVersion [junit4] Completed on J1 in 0.25s, 2 tests [junit4] [junit4] Suite: org.apache.solr.schema.NumericFieldsTest [junit4] Completed on J2 in 0.30s, 1 test [junit4] [junit4] Suite: org.apache.solr.TestSolrCoreProperties [junit4] Completed on J3 in 0.29s, 1 test [junit4] [junit4] Suite: org.apache.solr.internal.csv.CSVPrinterTest [junit4] Completed on J1 in 0.24s, 6 tests [junit4] [junit4] Suite:
Jenkins build is back to normal : 4.5.1-solr-test-core-loop #30
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/30/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5236) Use broadword bit selection in EliasFanoDecoder
[
https://issues.apache.org/jira/browse/LUCENE-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793772#comment-13793772
]
Adrien Grand commented on LUCENE-5236:
--
bq. /** @return See {@link EliasFanoEncoder#sufficientlySmallerThanBitSet(long,
long)} */
We try to put text rather than just javadoc tags in javadocs (ie. Return X
rather than @return X) so that the method summary doesn't appear empty on the
class-level javadocs.
bq. private static long numLongsForBits(long numBits) { // Note: int version in
FixedBitSet.bits2words()
I think you can directly use OpenBitSet.bits2words here? It already works with
longs.
There are some tabs mixed up with spaces and a broken javadoc link (see {{ant
precommit}}) but the patch otherwise looks really good!
{quote}
With index and broadword bit selection on my 32 bit machine, worst case
performance for load factor -1 (1/10) for any advance(), relative to
FixedBitSet, is -3.42 (2 log scale) for advance(3571).
The other advance() cases have better worst cases, so broadword bit selection
really helps there, too.
{quote}
Wow! This looks excellent! I will run the benchmark on my 64-bits machine
tomorrow to see if I get similar results.
Use broadword bit selection in EliasFanoDecoder
---
Key: LUCENE-5236
URL: https://issues.apache.org/jira/browse/LUCENE-5236
Project: Lucene - Core
Issue Type: Improvement
Reporter: Paul Elschot
Assignee: Adrien Grand
Priority: Minor
Attachments: LUCENE-5236.patch, LUCENE-5236.patch, LUCENE-5236.patch,
TestDocIdSetBenchmark.java
Try and speed up decoding
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5345) OpenCloseCoreStressTest opens too many files (causing it to fail often)
Robert Muir created SOLR-5345: - Summary: OpenCloseCoreStressTest opens too many files (causing it to fail often) Key: SOLR-5345 URL: https://issues.apache.org/jira/browse/SOLR-5345 Project: Solr Issue Type: Bug Reporter: Robert Muir Fix For: 4.5.1 Typically the symptom with jenkins is strange socket failures (because sockets are files too). On my machine though i got the nice too many open files from lucene because it just happened to fail that way. In addition to holding thousands of open files, this test creates 90 *megabytes* of logging output! Can we tone down the test? I havent looked at all: but it doesn't seem necessary to have huge numbers of cores/indexes to test the functionality, we should be able to do this with relatively small numbers. Additionally i dont think its good to use random merge/IW buffering parameters here, we should set ones that won't make tons of files, force the use of compound file format, etc. The massive amounts of logging should be addressed too. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5272) OpenBitSet.ensureCapacity does not modify numBits
[
https://issues.apache.org/jira/browse/LUCENE-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-5272:
---
Attachment: LUCENE-5272.patch
I didn't fix all the issues that I raised because I'm not sure what's the best
course of action here. Clearly, no one relies on these buggy methods so maybe
we should just fix ensureCapacity for now and worry about OBS's contract
another day.
If there are no objections, and the patch also seems correct, I will commit
those changes.
OpenBitSet.ensureCapacity does not modify numBits
-
Key: LUCENE-5272
URL: https://issues.apache.org/jira/browse/LUCENE-5272
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Reporter: Shai Erera
Attachments: LUCENE-5272.patch, LUCENE-5272.patch
It's a simple bug, reproduced by this simple test:
{code}
public void testEnsureCapacity() {
OpenBitSet bits = new OpenBitSet(1);
bits.fastSet(0);
bits.ensureCapacity(5); // make room for more bits
bits.fastSet(2);
}
{code}
The problem is that {{numBits}} which is used only for assrets isn't modified
by ensureCapacity and so the next fastSet trips the assert. I guess we should
also fix ensureCapacityWords and test it too.
I may not be able to fix this until Sunday though, so if anyone wants to fix
it before (maybe it can make it into 4.5.1), feel free.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5345) OpenCloseCoreStressTest opens too many files (causing it to fail often)
[ https://issues.apache.org/jira/browse/SOLR-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793776#comment-13793776 ] Uwe Schindler commented on SOLR-5345: - Yeah, thanks. On Jenkins it fails less often than on my machine, because the number of open files for the Jenkins process was raised to something like 16,000 or more file handles. Which is horrible alltogether. We should really tone down *all* those tests to use less than 1024 file handles, so anybody without tuned system settings can run tests! OpenCloseCoreStressTest opens too many files (causing it to fail often) --- Key: SOLR-5345 URL: https://issues.apache.org/jira/browse/SOLR-5345 Project: Solr Issue Type: Bug Reporter: Robert Muir Fix For: 4.5.1 Typically the symptom with jenkins is strange socket failures (because sockets are files too). On my machine though i got the nice too many open files from lucene because it just happened to fail that way. In addition to holding thousands of open files, this test creates 90 *megabytes* of logging output! Can we tone down the test? I havent looked at all: but it doesn't seem necessary to have huge numbers of cores/indexes to test the functionality, we should be able to do this with relatively small numbers. Additionally i dont think its good to use random merge/IW buffering parameters here, we should set ones that won't make tons of files, force the use of compound file format, etc. The massive amounts of logging should be addressed too. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!
But, it looks like this seed is in fact the one passed to each test ... so the seed in the reproduce with line is already the master seed. So I can try to reproduce with that (and exact same number of JVMS as flonkings). That's why I asked, actually, so that you can figure it out yourself :) Yes, the seed printed for a failing test (everywhere, in the augmented stack trace, etc.) is a concatenation of all the parent seeds, currently this would be: master:test for a test that failed in a given test, but: master only if a test fails in the beforeclass hook, for example. This is related to how JUnit manages scopes (or rather how I interpret them because JUnit doesn't have any notion of a scope). Anyway, in short -- if you see a [foo]:[bar] then [foo] is your master seed. Dawid So, nothing to do here :) I was just confused. Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Build failed in Jenkins: 4.5.1-solr-test-core-loop #33
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/33/ -- [...truncated 7023 lines...] [junit4] [junit4] Suite: org.apache.solr.update.TestIndexingPerformance [junit4] Completed on J3 in 0.64s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.TestOmitPositions [junit4] Completed on J2 in 0.84s, 2 tests [junit4] [junit4] Suite: org.apache.solr.search.TestMaxScoreQueryParser [junit4] Completed on J1 in 1.00s, 6 tests [junit4] [junit4] Suite: org.apache.solr.search.TestSurroundQueryParser [junit4] Completed on J0 in 0.92s, 1 test [junit4] [junit4] Suite: org.apache.solr.handler.StandardRequestHandlerTest [junit4] Completed on J3 in 0.99s, 1 test [junit4] [junit4] Suite: org.apache.solr.SolrInfoMBeanTest [junit4] Completed on J2 in 0.96s, 1 test [junit4] [junit4] Suite: org.apache.solr.handler.admin.LoggingHandlerTest [junit4] Completed on J1 in 0.93s, 1 test [junit4] [junit4] Suite: org.apache.solr.highlight.FastVectorHighlighterTest [junit4] Completed on J0 in 0.82s, 2 tests [junit4] [junit4] Suite: org.apache.solr.schema.IndexSchemaTest [junit4] Completed on J3 in 0.77s, 3 tests [junit4] [junit4] Suite: org.apache.solr.schema.PreAnalyzedFieldTest [junit4] Completed on J2 in 0.82s, 3 tests [junit4] [junit4] Suite: org.apache.solr.update.UpdateParamsTest [junit4] Completed on J1 in 0.90s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestFieldCollectionResource [junit4] Completed on J0 in 0.78s, 7 tests [junit4] [junit4] Suite: org.apache.solr.handler.CSVRequestHandlerTest [junit4] Completed on J3 in 0.88s, 1 test [junit4] [junit4] Suite: org.apache.solr.schema.CopyFieldTest [junit4] Completed on J2 in 0.85s, 9 tests [junit4] [junit4] Suite: org.apache.solr.handler.DocumentAnalysisRequestHandlerTest [junit4] Completed on J1 in 1.17s, 4 tests [junit4] [junit4] Suite: org.apache.solr.update.processor.RegexBoostProcessorTest [junit4] Completed on J0 in 1.09s, 4 tests [junit4] [junit4] Suite: org.apache.solr.core.TestCoreDiscovery [junit4] Completed on J3 in 0.64s, 4 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestFieldTypeResource [junit4] Completed on J2 in 0.66s, 4 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestDynamicFieldResource [junit4] Completed on J1 in 0.70s, 3 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSolrQueryParserResource [junit4] Completed on J0 in 0.72s, 1 test [junit4] [junit4] Suite: org.apache.solr.search.TestComponentsName [junit4] Completed on J3 in 0.65s, 1 test [junit4] [junit4] Suite: org.apache.solr.servlet.NoCacheHeaderTest [junit4] Completed on J2 in 0.57s, 3 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestUniqueKeyFieldResource [junit4] Completed on J3 in 0.75s, 1 test [junit4] [junit4] Suite: org.apache.solr.update.processor.UpdateRequestProcessorFactoryTest [junit4] Completed on J0 in 0.57s, 2 tests [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSchemaSimilarityResource [junit4] Completed on J1 in 0.77s, 1 test [junit4] [junit4] Suite: org.apache.solr.analysis.TestReversedWildcardFilterFactory [junit4] Completed on J2 in 0.72s, 4 tests [junit4] [junit4] Suite: org.apache.solr.search.TestLFUCache [junit4] Completed on J3 in 0.56s, 5 tests [junit4] [junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy2 [junit4] Completed on J1 in 0.55s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestSolrQueryParserDefaultOperatorResource [junit4] Completed on J0 in 0.99s, 1 test [junit4] [junit4] Suite: org.apache.solr.core.TestConfig [junit4] Completed on J2 in 0.48s, 7 tests [junit4] [junit4] Suite: org.apache.solr.update.SolrIndexConfigTest [junit4] Completed on J3 in 0.57s, 3 tests [junit4] [junit4] Suite: org.apache.solr.search.TestSearchPerf [junit4] Completed on J0 in 0.50s, 1 test [junit4] [junit4] Suite: org.apache.solr.highlight.TestPostingsSolrHighlighter [junit4] Completed on J1 in 0.53s, 12 tests [junit4] [junit4] Suite: org.apache.solr.schema.TestCollationField [junit4] Completed on J2 in 0.40s, 8 tests [junit4] [junit4] Suite: org.apache.solr.search.TestDocSet [junit4] Completed on J3 in 0.36s, 2 tests [junit4] [junit4] Suite: org.apache.solr.schema.TestBinaryField [junit4] Completed on J2 in 0.24s, 1 test [junit4] [junit4] Suite: org.apache.solr.search.TestElisionMultitermQuery [junit4] Completed on J1 in 0.41s, 1 test [junit4] [junit4] Suite: org.apache.solr.rest.schema.TestClassNameShortening [junit4] Completed on J3 in 0.33s, 3 tests [junit4] [junit4] Suite: org.apache.solr.analysis.TestLuceneMatchVersion [junit4] Completed
[jira] [Updated] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions
[
https://issues.apache.org/jira/browse/LUCENE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated LUCENE-5273:
---
Attachment: LUCENE-5273-slowdown-fixed.patch
Patch addressing slowdown: the old war-building behavior of pulling
{{lucene-*.jar}} from {{lucene/build/*/}} is restored, unless called from the
{{create-package}} target, in which case they are pulled from the
built/unpacked {{lucene-version.tgz}}. In this way, {{ant example}} doesn't
have to wait around for javadocs.
Here are timings from my Macbook Pro (OS X 10.8.5) with Oracle Java 1.7.0_25
64-bit - times are *minutes:seconds*:
||Top-level clean?||trunk before any LUCENE-5273 patches committed
(r1531353)||current trunk||trunk with this patch applied||
|Yes|1:11|4:26|1:15|
|No|0:37|0:38|0:37|
So with this patch, timings are back to where they were before I committed
anything for this issue.
This patch provides the additional benefit that Lucene module changes will get
picked up even if {{ant clean}} is not performed first.
Committing shortly.
Binary artifacts in Lucene and Solr convenience binary distributions
accompanying a release, including on Maven Central, should be identical
across all distributions
-
Key: LUCENE-5273
URL: https://issues.apache.org/jira/browse/LUCENE-5273
Project: Lucene - Core
Issue Type: Bug
Components: general/build
Reporter: Steve Rowe
Assignee: Steve Rowe
Fix For: 4.6, 5.0
Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch,
LUCENE-5273-slowdown-fixed.patch
As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we
release multiple versions of the same artifact: binary Maven artifacts are
not identical to the ones in the Lucene and Solr binary distributions, and
the Lucene jars in the Solr binary distribution, including within the war,
are not identical to the ones in the Lucene binary distribution. This is bad.
It's (probably always?) not horribly bad, since the differences all appear to
be caused by the build re-creating manifests and re-building jars and the
Solr war from their constituents at various points in the release build
process; as a result, manifest timestamp attributes, as well as archive
metadata (at least constituent timestamps, maybe other things?), differ each
time a jar is rebuilt.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributi
[
https://issues.apache.org/jira/browse/LUCENE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793779#comment-13793779
]
Steve Rowe edited comment on LUCENE-5273 at 10/13/13 8:58 PM:
--
Patch addressing the slowdown Shalin mentioned above: the old war-building
behavior of pulling {{lucene-\*.jar}} from {{lucene/build/\*/}} is restored,
unless called from the {{create-package}} target, in which case they are pulled
from the built/unpacked {{lucene-version.tgz}}. In this way, {{ant example}}
doesn't have to wait around for javadocs.
Here are timings from my Macbook Pro (OS X 10.8.5) with Oracle Java 1.7.0_25
64-bit - times are *minutes:seconds*:
||Top-level clean?||trunk before any LUCENE-5273 patches committed
(r1531353)||current trunk||trunk with this patch applied||
|Yes|1:11|4:26|1:15|
|No|0:37|0:38|0:37|
So with this patch, timings are back to where they were before I committed
anything for this issue.
This patch provides the additional benefit that Lucene module changes will get
picked up even if {{ant clean}} is not performed first.
Committing shortly.
was (Author: steve_rowe):
Patch addressing slowdown: the old war-building behavior of pulling
{{lucene-*.jar}} from {{lucene/build/*/}} is restored, unless called from the
{{create-package}} target, in which case they are pulled from the
built/unpacked {{lucene-version.tgz}}. In this way, {{ant example}} doesn't
have to wait around for javadocs.
Here are timings from my Macbook Pro (OS X 10.8.5) with Oracle Java 1.7.0_25
64-bit - times are *minutes:seconds*:
||Top-level clean?||trunk before any LUCENE-5273 patches committed
(r1531353)||current trunk||trunk with this patch applied||
|Yes|1:11|4:26|1:15|
|No|0:37|0:38|0:37|
So with this patch, timings are back to where they were before I committed
anything for this issue.
This patch provides the additional benefit that Lucene module changes will get
picked up even if {{ant clean}} is not performed first.
Committing shortly.
Binary artifacts in Lucene and Solr convenience binary distributions
accompanying a release, including on Maven Central, should be identical
across all distributions
-
Key: LUCENE-5273
URL: https://issues.apache.org/jira/browse/LUCENE-5273
Project: Lucene - Core
Issue Type: Bug
Components: general/build
Reporter: Steve Rowe
Assignee: Steve Rowe
Fix For: 4.6, 5.0
Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch,
LUCENE-5273-slowdown-fixed.patch
As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we
release multiple versions of the same artifact: binary Maven artifacts are
not identical to the ones in the Lucene and Solr binary distributions, and
the Lucene jars in the Solr binary distribution, including within the war,
are not identical to the ones in the Lucene binary distribution. This is bad.
It's (probably always?) not horribly bad, since the differences all appear to
be caused by the build re-creating manifests and re-building jars and the
Solr war from their constituents at various points in the release build
process; as a result, manifest timestamp attributes, as well as archive
metadata (at least constituent timestamps, maybe other things?), differ each
time a jar is rebuilt.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Jenkins build is back to normal : 4.5.1-solr-test-core-loop #34
See http://sierranevada.servebeer.com/job/4.5.1-solr-test-core-loop/34/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!
On Sun, Oct 13, 2013 at 4:46 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: Anyway, in short -- if you see a [foo]:[bar] then [foo] is your master seed. Thanks Dawid: I didn't know this was always the case. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions
[
https://issues.apache.org/jira/browse/LUCENE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793780#comment-13793780
]
Robert Muir commented on LUCENE-5273:
-
{quote}
BTW: I was hoping this patch also prevent rebuilding the same javadocs over and
over We should also fix this in the future, it's horrible. While building Solr
maven artifacts it rebuilds solr-core javadocs 5 or 6 times! (for each module),
{quote}
I think we should open a followup issue for this? There is definitely something
crazy going on here, it adds a considerable amount of time to tasks like
precommit, documentation-lint, release packaging, smoke testing, etc.
Binary artifacts in Lucene and Solr convenience binary distributions
accompanying a release, including on Maven Central, should be identical
across all distributions
-
Key: LUCENE-5273
URL: https://issues.apache.org/jira/browse/LUCENE-5273
Project: Lucene - Core
Issue Type: Bug
Components: general/build
Reporter: Steve Rowe
Assignee: Steve Rowe
Fix For: 4.6, 5.0
Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch,
LUCENE-5273-slowdown-fixed.patch
As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we
release multiple versions of the same artifact: binary Maven artifacts are
not identical to the ones in the Lucene and Solr binary distributions, and
the Lucene jars in the Solr binary distribution, including within the war,
are not identical to the ones in the Lucene binary distribution. This is bad.
It's (probably always?) not horribly bad, since the differences all appear to
be caused by the build re-creating manifests and re-building jars and the
Solr war from their constituents at various points in the release build
process; as a result, manifest timestamp attributes, as well as archive
metadata (at least constituent timestamps, maybe other things?), differ each
time a jar is rebuilt.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions
[ https://issues.apache.org/jira/browse/LUCENE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793781#comment-13793781 ] ASF subversion and git services commented on LUCENE-5273: - Commit 1531750 from [~steve_rowe] in branch 'dev/trunk' [ https://svn.apache.org/r1531750 ] LUCENE-5273: Fix slowdown when running 'ant example': unless called from the 'create-package' target, the 'lucene-jars-to-solr' and 'module-jars-to-solr' targets no longer depend on '-unpack-lucene-tgz', pulling lucene-*.jar from lucene/build/*/ instead. Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions - Key: LUCENE-5273 URL: https://issues.apache.org/jira/browse/LUCENE-5273 Project: Lucene - Core Issue Type: Bug Components: general/build Reporter: Steve Rowe Assignee: Steve Rowe Fix For: 4.6, 5.0 Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch, LUCENE-5273-slowdown-fixed.patch As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we release multiple versions of the same artifact: binary Maven artifacts are not identical to the ones in the Lucene and Solr binary distributions, and the Lucene jars in the Solr binary distribution, including within the war, are not identical to the ones in the Lucene binary distribution. This is bad. It's (probably always?) not horribly bad, since the differences all appear to be caused by the build re-creating manifests and re-building jars and the Solr war from their constituents at various points in the release build process; as a result, manifest timestamp attributes, as well as archive metadata (at least constituent timestamps, maybe other things?), differ each time a jar is rebuilt. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5282) speed up javadocs generation tasks
Robert Muir created LUCENE-5282: --- Summary: speed up javadocs generation tasks Key: LUCENE-5282 URL: https://issues.apache.org/jira/browse/LUCENE-5282 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir These generate the same things over and over. I think this is due to javadocs always rebuilding their dependencies. Can we not add a fake timestamp file (with 'touch') somewhere like javadocs.generated and then use 'uptodate' comparing that against the relevant source code to determine if javadocs need regeneration? This seems like it would be a very simple solution. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions
[ https://issues.apache.org/jira/browse/LUCENE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793782#comment-13793782 ] Mark Miller commented on LUCENE-5273: - bq. Mark Miller, do you want this on the 4.5 release branch? I'll defer to those of you deeper into the issue, but from a high level, to me it does not seem worth the gain vs the risk for 4.5.1. Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions - Key: LUCENE-5273 URL: https://issues.apache.org/jira/browse/LUCENE-5273 Project: Lucene - Core Issue Type: Bug Components: general/build Reporter: Steve Rowe Assignee: Steve Rowe Fix For: 4.6, 5.0 Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch, LUCENE-5273-slowdown-fixed.patch As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we release multiple versions of the same artifact: binary Maven artifacts are not identical to the ones in the Lucene and Solr binary distributions, and the Lucene jars in the Solr binary distribution, including within the war, are not identical to the ones in the Lucene binary distribution. This is bad. It's (probably always?) not horribly bad, since the differences all appear to be caused by the build re-creating manifests and re-building jars and the Solr war from their constituents at various points in the release build process; as a result, manifest timestamp attributes, as well as archive metadata (at least constituent timestamps, maybe other things?), differ each time a jar is rebuilt. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions
[ https://issues.apache.org/jira/browse/LUCENE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793784#comment-13793784 ] Robert Muir commented on LUCENE-5273: - I agree with Mark: as much as I like the change, and even though I consider it a bug, I think its best to be conservative and to just fix this for 4.6? Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions - Key: LUCENE-5273 URL: https://issues.apache.org/jira/browse/LUCENE-5273 Project: Lucene - Core Issue Type: Bug Components: general/build Reporter: Steve Rowe Assignee: Steve Rowe Fix For: 4.6, 5.0 Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch, LUCENE-5273-slowdown-fixed.patch As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we release multiple versions of the same artifact: binary Maven artifacts are not identical to the ones in the Lucene and Solr binary distributions, and the Lucene jars in the Solr binary distribution, including within the war, are not identical to the ones in the Lucene binary distribution. This is bad. It's (probably always?) not horribly bad, since the differences all appear to be caused by the build re-creating manifests and re-building jars and the Solr war from their constituents at various points in the release build process; as a result, manifest timestamp attributes, as well as archive metadata (at least constituent timestamps, maybe other things?), differ each time a jar is rebuilt. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5282) speed up javadocs generation tasks
[ https://issues.apache.org/jira/browse/LUCENE-5282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793787#comment-13793787 ] Robert Muir commented on LUCENE-5282: - I am looking into this, should just be a few lines of ant. I'm gathering benchmarks for 'ant documentation' so we get an idea... speed up javadocs generation tasks -- Key: LUCENE-5282 URL: https://issues.apache.org/jira/browse/LUCENE-5282 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir These generate the same things over and over. I think this is due to javadocs always rebuilding their dependencies. Can we not add a fake timestamp file (with 'touch') somewhere like javadocs.generated and then use 'uptodate' comparing that against the relevant source code to determine if javadocs need regeneration? This seems like it would be a very simple solution. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-5345) OpenCloseCoreStressTest opens too many files (causing it to fail often)
[ https://issues.apache.org/jira/browse/SOLR-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-5345: - Assignee: Mark Miller OpenCloseCoreStressTest opens too many files (causing it to fail often) --- Key: SOLR-5345 URL: https://issues.apache.org/jira/browse/SOLR-5345 Project: Solr Issue Type: Bug Reporter: Robert Muir Assignee: Mark Miller Fix For: 4.5.1 Typically the symptom with jenkins is strange socket failures (because sockets are files too). On my machine though i got the nice too many open files from lucene because it just happened to fail that way. In addition to holding thousands of open files, this test creates 90 *megabytes* of logging output! Can we tone down the test? I havent looked at all: but it doesn't seem necessary to have huge numbers of cores/indexes to test the functionality, we should be able to do this with relatively small numbers. Additionally i dont think its good to use random merge/IW buffering parameters here, we should set ones that won't make tons of files, force the use of compound file format, etc. The massive amounts of logging should be addressed too. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5236) Use broadword bit selection in EliasFanoDecoder
[ https://issues.apache.org/jira/browse/LUCENE-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-5236: - Attachment: LUCENE-5236.patch Use broadword bit selection in EliasFanoDecoder --- Key: LUCENE-5236 URL: https://issues.apache.org/jira/browse/LUCENE-5236 Project: Lucene - Core Issue Type: Improvement Reporter: Paul Elschot Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-5236.patch, LUCENE-5236.patch, LUCENE-5236.patch, LUCENE-5236.patch, TestDocIdSetBenchmark.java Try and speed up decoding -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions
[ https://issues.apache.org/jira/browse/LUCENE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793803#comment-13793803 ] ASF subversion and git services commented on LUCENE-5273: - Commit 1531759 from [~steve_rowe] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1531759 ] LUCENE-5273: Fix slowdown when running 'ant example': unless called from the 'create-package' target, the 'lucene-jars-to-solr' and 'module-jars-to-solr' targets no longer depend on '-unpack-lucene-tgz', pulling lucene-*.jar from lucene/build/*/ instead. (merged trunk r1531750) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions - Key: LUCENE-5273 URL: https://issues.apache.org/jira/browse/LUCENE-5273 Project: Lucene - Core Issue Type: Bug Components: general/build Reporter: Steve Rowe Assignee: Steve Rowe Fix For: 4.6, 5.0 Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch, LUCENE-5273-slowdown-fixed.patch As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we release multiple versions of the same artifact: binary Maven artifacts are not identical to the ones in the Lucene and Solr binary distributions, and the Lucene jars in the Solr binary distribution, including within the war, are not identical to the ones in the Lucene binary distribution. This is bad. It's (probably always?) not horribly bad, since the differences all appear to be caused by the build re-creating manifests and re-building jars and the Solr war from their constituents at various points in the release build process; as a result, manifest timestamp attributes, as well as archive metadata (at least constituent timestamps, maybe other things?), differ each time a jar is rebuilt. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions
[ https://issues.apache.org/jira/browse/LUCENE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe resolved LUCENE-5273. Resolution: Fixed Lucene Fields: New,Patch Available (was: New) Slowdown fix committed to trunk and branch_4x. I won't backport any of this to the lucene_solr_4_5 branch. Thanks guys! Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions - Key: LUCENE-5273 URL: https://issues.apache.org/jira/browse/LUCENE-5273 Project: Lucene - Core Issue Type: Bug Components: general/build Reporter: Steve Rowe Assignee: Steve Rowe Fix For: 4.6, 5.0 Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch, LUCENE-5273-slowdown-fixed.patch As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we release multiple versions of the same artifact: binary Maven artifacts are not identical to the ones in the Lucene and Solr binary distributions, and the Lucene jars in the Solr binary distribution, including within the war, are not identical to the ones in the Lucene binary distribution. This is bad. It's (probably always?) not horribly bad, since the differences all appear to be caused by the build re-creating manifests and re-building jars and the Solr war from their constituents at various points in the release build process; as a result, manifest timestamp attributes, as well as archive metadata (at least constituent timestamps, maybe other things?), differ each time a jar is rebuilt. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5282) speed up javadocs generation tasks
[ https://issues.apache.org/jira/browse/LUCENE-5282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793811#comment-13793811 ] Robert Muir commented on LUCENE-5282: - Its not so easy the way we are using a macro for this (e.g. to link in dependencies). There is not even a default task (its just defined to fail if you dont redefine it)... needs some thought. speed up javadocs generation tasks -- Key: LUCENE-5282 URL: https://issues.apache.org/jira/browse/LUCENE-5282 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir These generate the same things over and over. I think this is due to javadocs always rebuilding their dependencies. Can we not add a fake timestamp file (with 'touch') somewhere like javadocs.generated and then use 'uptodate' comparing that against the relevant source code to determine if javadocs need regeneration? This seems like it would be a very simple solution. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5236) Use broadword bit selection in EliasFanoDecoder
[ https://issues.apache.org/jira/browse/LUCENE-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793814#comment-13793814 ] Paul Elschot commented on LUCENE-5236: -- The second patch of 13 Oct 2013 improves the javadocs of EliasFanoDocIdSet, and adds the condition to sufficientlySmallerThanBitSet to always prefer a bit set when it uses no more than 4 longs. ant validate does not complain about tabs anymore here. I could not find a broken link in the javadocs, maybe because I'm using java 1.7: ant documentation-lint fails with the error message Linting documentation HTML is not supported on this Java version (1.7). There is an http:// reference to archiv.org in the javadoc as plain text (it is not marked up as a link), and just now it worked fine as a link. OpenBitSet.bits2words will fail when the number of bits gets just over the maximum int value, so I prefer not to use it for now. I am looking forward to the benchmark results on a 64 bits machine. In the decoder there is a test to use naive bit selection when the needed rank is less then or equal to 8, and otherwise use broadword bit selection. I expect this constant 8 to be close to the optimal value on a current 64 bit machine, but some tuning may be needed. See also my first comment of 11 July 2013 at LUCENE-5098. Use broadword bit selection in EliasFanoDecoder --- Key: LUCENE-5236 URL: https://issues.apache.org/jira/browse/LUCENE-5236 Project: Lucene - Core Issue Type: Improvement Reporter: Paul Elschot Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-5236.patch, LUCENE-5236.patch, LUCENE-5236.patch, LUCENE-5236.patch, TestDocIdSetBenchmark.java Try and speed up decoding -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5345) OpenCloseCoreStressTest opens too many files (causing it to fail often)
[ https://issues.apache.org/jira/browse/SOLR-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793824#comment-13793824 ] ASF subversion and git services commented on SOLR-5345: --- Commit 1531766 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1531766 ] SOLR-5345: A first pass toning down OpenCloseCoreStressTest OpenCloseCoreStressTest opens too many files (causing it to fail often) --- Key: SOLR-5345 URL: https://issues.apache.org/jira/browse/SOLR-5345 Project: Solr Issue Type: Bug Reporter: Robert Muir Assignee: Mark Miller Fix For: 4.5.1 Typically the symptom with jenkins is strange socket failures (because sockets are files too). On my machine though i got the nice too many open files from lucene because it just happened to fail that way. In addition to holding thousands of open files, this test creates 90 *megabytes* of logging output! Can we tone down the test? I havent looked at all: but it doesn't seem necessary to have huge numbers of cores/indexes to test the functionality, we should be able to do this with relatively small numbers. Additionally i dont think its good to use random merge/IW buffering parameters here, we should set ones that won't make tons of files, force the use of compound file format, etc. The massive amounts of logging should be addressed too. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Setup Atlassian FishEye over Lucene/Solr source repository
I made the request a couple of weeks ago, and it has finally come fully online: https://fisheye6.atlassian.com/browse/Lucene. It looks like there is an automatic connection from Apache JIRA to the Atlassian-hosted FishEye, so you'll see more detailed commit reports come up in JIRA issues now. Steve On Sep 11, 2013, at 2:23 PM, Steve Rowe sar...@gmail.com wrote: Atlassian offers free hosting for its FishEye service over Apache projects' source repositories. Looks like they currently host 60 or so projects: https://fisheye6.atlassian.com/browse FishEye can search file history - content as well as metadata - and I'd like to be able to do that against Lucene/Solr sources. If there are no objections, I'll request Atlassian set this up for us - instructions on how to do this are under Adding an Apache Repo on the Welcome Message section here https://fisheye6.atlassian.com. Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_40) - Build # 7779 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/7779/ Java: 32bit/jdk1.7.0_40 -client -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterDelete.testNoLostDeletesOnIOException Error Message: info=_1g(4.6):c2482/32:delGen=2 isn't live Stack Trace: java.lang.AssertionError: info=_1g(4.6):c2482/32:delGen=2 isn't live at __randomizedtesting.SeedInfo.seed([3F31CC1FCA9DA422:A79869D48EA5B4A0]:0) at org.apache.lucene.index.IndexWriter$ReaderPool.infoIsLive(IndexWriter.java:428) at org.apache.lucene.index.IndexWriter$ReaderPool.dropAll(IndexWriter.java:497) at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1050) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:945) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:907) at org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.java:332) at org.apache.lucene.index.TestIndexWriterDelete.testNoLostDeletesOnIOException(TestIndexWriterDelete.java:1354) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:724) Build Log: [...truncated 631 lines...]
[jira] [Commented] (SOLR-5345) OpenCloseCoreStressTest opens too many files (causing it to fail often)
[ https://issues.apache.org/jira/browse/SOLR-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793830#comment-13793830 ] ASF subversion and git services commented on SOLR-5345: --- Commit 1531767 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1531767 ] SOLR-5345: A first pass toning down OpenCloseCoreStressTest OpenCloseCoreStressTest opens too many files (causing it to fail often) --- Key: SOLR-5345 URL: https://issues.apache.org/jira/browse/SOLR-5345 Project: Solr Issue Type: Bug Reporter: Robert Muir Assignee: Mark Miller Fix For: 4.5.1 Typically the symptom with jenkins is strange socket failures (because sockets are files too). On my machine though i got the nice too many open files from lucene because it just happened to fail that way. In addition to holding thousands of open files, this test creates 90 *megabytes* of logging output! Can we tone down the test? I havent looked at all: but it doesn't seem necessary to have huge numbers of cores/indexes to test the functionality, we should be able to do this with relatively small numbers. Additionally i dont think its good to use random merge/IW buffering parameters here, we should set ones that won't make tons of files, force the use of compound file format, etc. The massive amounts of logging should be addressed too. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
